在Java5.0之前，協(xié)調(diào)對共享對象的訪問可以使用的機制只有synchronized和volatile。我們知道synchronized關(guān)鍵字實現(xiàn)了內(nèi)置鎖，而volatile關(guān)鍵字保證了多線程的內(nèi)存可見性。在大多數(shù)情況下，這些機制都能很好地完成工作，但卻無法實現(xiàn)一些更高級的功能，例如，無法中斷一個正在等待獲取鎖的線程，無法實現(xiàn)限定時間的獲取鎖機制，無法實現(xiàn)非阻塞結(jié)構(gòu)的加鎖規(guī)則等。而這些更靈活的加鎖機制通常都能夠提供更好的活躍性或性能。因此，在Java5.0中增加了一種新的機制：ReentrantLock。ReentrantLock類實現(xiàn)了Lock接口，并提供了與synchronized相同的互斥性和內(nèi)存可見性，它的底層是通過AQS來實現(xiàn)多線程同步的。與內(nèi)置鎖相比ReentrantLock不僅提供了更豐富的加鎖機制，而且在性能上也不遜色于內(nèi)置鎖(在以前的版本中甚至優(yōu)于內(nèi)置鎖)。說了ReentrantLock這么多的優(yōu)點，那么下面我們就來揭開它的源碼看看它的具體實現(xiàn)。
1.synchronized關(guān)鍵字的介紹
Java提供了內(nèi)置鎖來支持多線程的同步，JVM根據(jù)synchronized關(guān)鍵字來標識同步代碼塊，當線程進入同步代碼塊時會自動獲取鎖，退出同步代碼塊時會自動釋放鎖，一個線程獲得鎖后其他線程將會被阻塞。每個Java對象都可以用做一個實現(xiàn)同步的鎖，synchronized關(guān)鍵字可以用來修飾對象方法，靜態(tài)方法和代碼塊，當修飾對象方法和靜態(tài)方法時鎖分別是方法所在的對象和Class對象，當修飾代碼塊時需提供額外的對象作為鎖。每個Java對象之所以可以作為鎖，是因為在對象頭中關(guān)聯(lián)了一個monitor對象(管程)，線程進入同步代碼塊時會自動持有monitor對象，退出時會自動釋放monitor對象，當monitor對象被持有時其他線程將會被阻塞。當然這些同步操作都由JVM底層幫你實現(xiàn)了，但以synchronized關(guān)鍵字修飾的方法和代碼塊在底層實現(xiàn)上還是有些區(qū)別的。synchronized關(guān)鍵字修飾的方法是隱式同步的，即無需通過字節(jié)碼指令來控制的，JVM可以根據(jù)方法表中的ACC_SYNCHRONIZED訪問標志來區(qū)分一個方法是否是同步方法；而synchronized關(guān)鍵字修飾的代碼塊是顯式同步的，它是通過monitorenter和monitorexit字節(jié)碼指令來控制線程對管程的持有和釋放。monitor對象內(nèi)部持有_count字段，_count等于0表示管程未被持有，_count大于0表示管程已被持有，每次持有線程重入時_count都會加1，每次持有線程退出時_count都會減1，這就是內(nèi)置鎖重入性的實現(xiàn)原理。另外，monitor對象內(nèi)部還有兩條隊列_EntryList和_WaitSet，對應(yīng)著AQS的同步隊列和條件隊列，當線程獲取鎖失敗時會到_EntryList中阻塞，當調(diào)用鎖對象的wait方法時線程將會進入_WaitSet中等待，這是內(nèi)置鎖的線程同步和條件等待的實現(xiàn)原理。
2.ReentrantLock和Synchronized的比較
synchronized關(guān)鍵字是Java提供的內(nèi)置鎖機制，其同步操作由底層JVM實現(xiàn)，而ReentrantLock是java.util.concurrent包提供的顯式鎖，其同步操作由AQS同步器提供支持。ReentrantLock在加鎖和內(nèi)存上提供的語義與內(nèi)置鎖相同，此外它還提供了一些其他功能，包括定時的鎖等待，可中斷的鎖等待，公平鎖，以及實現(xiàn)非塊結(jié)構(gòu)的加鎖。另外，在早期的JDK版本中ReentrantLock在性能上還占有一定的優(yōu)勢，既然ReentrantLock擁有這么多優(yōu)勢，為什么還要使用synchronized關(guān)鍵字呢？事實上確實有許多人使用ReentrantLock來替代synchronized關(guān)鍵字的加鎖操作。但是內(nèi)置鎖仍然有它特有的優(yōu)勢，內(nèi)置鎖為許多開發(fā)人員所熟悉，使用方式也更加的簡潔緊湊，因為顯式鎖必須手動在finally塊中調(diào)用unlock，所以使用內(nèi)置鎖相對來說會更加安全些。同時未來更加可能會去提升synchronized而不是ReentrantLock的性能。因為synchronized是JVM的內(nèi)置屬性，它能執(zhí)行一些優(yōu)化，例如對線程封閉的鎖對象的鎖消除優(yōu)化，通過增加鎖的粒度來消除內(nèi)置鎖的同步，而如果通過基于類庫的鎖來實現(xiàn)這些功能，則可能性不大。所以當需要一些高級功能時才應(yīng)該使用ReentrantLock，這些功能包括：可定時的，可輪詢的與可中斷的鎖獲取操作，公平隊列，以及非塊結(jié)構(gòu)的鎖。否則，還是應(yīng)該優(yōu)先使用synchronized。
3.獲取鎖和釋放鎖的操作
我們首先來看一下使用ReentrantLock加鎖的示例代碼。
|
1
2
3
4
5
6
7
8
9
10
11
12
|
public void doSomething() { //默認是獲取一個非公平鎖 ReentrantLock lock = new ReentrantLock(); try{ //執(zhí)行前先加鎖 lock.lock(); //執(zhí)行操作... }finally{ //最后釋放鎖 lock.unlock(); }} |
以下是獲取鎖和釋放鎖這兩個操作的API。
|
1
2
3
4
5
6
7
8
|
//獲取鎖的操作public void lock() { sync.lock();}//釋放鎖的操作public void unlock() { sync.release(1);} |
可以看到獲取鎖和釋放鎖的操作分別委托給Sync對象的lock方法和release方法。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
public class ReentrantLock implements Lock, java.io.Serializable { private final Sync sync; abstract static class Sync extends AbstractQueuedSynchronizer { abstract void lock(); } //實現(xiàn)非公平鎖的同步器 static final class NonfairSync extends Sync { final void lock() { ... } } //實現(xiàn)公平鎖的同步器 static final class FairSync extends Sync { final void lock() { ... } }} |
每個ReentrantLock對象都持有一個Sync類型的引用，這個Sync類是一個抽象內(nèi)部類它繼承自AbstractQueuedSynchronizer，它里面的lock方法是一個抽象方法。ReentrantLock的成員變量sync是在構(gòu)造時賦值的，下面我們看看ReentrantLock的兩個構(gòu)造方法都做了些什么？
|
1
2
3
4
5
6
7
8
9
|
//默認無參構(gòu)造器public ReentrantLock() { sync = new NonfairSync();}//有參構(gòu)造器public ReentrantLock(boolean fair) { sync = fair ? new FairSync() : new NonfairSync();} |
調(diào)用默認無參構(gòu)造器會將NonfairSync實例賦值給sync，此時鎖是非公平鎖。有參構(gòu)造器允許通過參數(shù)來指定是將FairSync實例還是NonfairSync實例賦值給sync。NonfairSync和FairSync都是繼承自Sync類并重寫了lock()方法，所以公平鎖和非公平鎖在獲取鎖的方式上有些區(qū)別，這個我們下面會講到。再來看看釋放鎖的操作，每次調(diào)用unlock()方法都只是去執(zhí)行sync.release(1)操作，這步操作會調(diào)用AbstractQueuedSynchronizer類的release()方法，我們再來回顧一下。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
//釋放鎖的操作(獨占模式)public final boolean release(int arg) { //撥動密碼鎖, 看看是否能夠開鎖 if (tryRelease(arg)) { //獲取head結(jié)點 Node h = head; //如果head結(jié)點不為空并且等待狀態(tài)不等于0就去喚醒后繼結(jié)點 if (h != null && h.waitStatus != 0) { //喚醒后繼結(jié)點 unparkSuccessor(h); } return true; } return false;} |
這個release方法是AQS提供的釋放鎖操作的API，它首先會去調(diào)用tryRelease方法去嘗試獲取鎖，tryRelease方法是抽象方法，它的實現(xiàn)邏輯在子類Sync里面。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
//嘗試釋放鎖protected final boolean tryRelease(int releases) { int c = getState() - releases; //如果持有鎖的線程不是當前線程就拋出異常 if (Thread.currentThread() != getExclusiveOwnerThread()) { throw new IllegalMonitorStateException(); } boolean free = false; //如果同步狀態(tài)為0則表明鎖被釋放 if (c == 0) { //設(shè)置鎖被釋放的標志為真 free = true; //設(shè)置占用線程為空 setExclusiveOwnerThread(null); } setState(c); return free;} |
這個tryRelease方法首先會獲取當前同步狀態(tài)，并將當前同步狀態(tài)減去傳入的參數(shù)值得到新的同步狀態(tài)，然后判斷新的同步狀態(tài)是否等于0，如果等于0則表明當前鎖被釋放，然后先將鎖的釋放狀態(tài)置為真，再將當前占有鎖的線程清空，最后調(diào)用setState方法設(shè)置新的同步狀態(tài)并返回鎖的釋放狀態(tài)。
4.公平鎖和非公平鎖
我們知道ReentrantLock是公平鎖還是非公平鎖是基于sync指向的是哪個具體實例。在構(gòu)造時會為成員變量sync賦值，如果賦值為NonfairSync實例則表明是非公平鎖，如果賦值為FairSync實例則表明為公平鎖。如果是公平鎖，線程將按照它們發(fā)出請求的順序來獲得鎖，但在非公平鎖上，則允許插隊行為：當一個線程請求非公平的鎖時，如果在發(fā)出請求的同時該鎖的狀態(tài)變?yōu)榭捎茫敲催@個線程將跳過隊列中所有等待的線程直接獲得這個鎖。下面我們先看看非公平鎖的獲取方式。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
//非公平同步器static final class NonfairSync extends Sync { //實現(xiàn)父類的抽象獲取鎖的方法 final void lock() { //使用CAS方式設(shè)置同步狀態(tài) if (compareAndSetState(0, 1)) { //如果設(shè)置成功則表明鎖沒被占用 setExclusiveOwnerThread(Thread.currentThread()); } else { //否則表明鎖已經(jīng)被占用, 調(diào)用acquire讓線程去同步隊列排隊獲取 acquire(1); } } //嘗試獲取鎖的方法 protected final boolean tryAcquire(int acquires) { return nonfairTryAcquire(acquires); }}//以不可中斷模式獲取鎖(獨占模式)public final void acquire(int arg) { if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) { selfInterrupt(); }} |
可以看到在非公平鎖的lock方法中，線程第一步就會以CAS方式將同步狀態(tài)的值從0改為1。其實這步操作就等于去嘗試獲取鎖，如果更改成功則表明線程剛來就獲取了鎖，而不必再去同步隊列里面排隊了。如果更改失敗則表明線程剛來時鎖還未被釋放，所以接下來就調(diào)用acquire方法。我們知道這個acquire方法是繼承自AbstractQueuedSynchronizer的方法，現(xiàn)在再來回顧一下該方法，線程進入acquire方法后首先去調(diào)用tryAcquire方法嘗試去獲取鎖，由于NonfairSync覆蓋了tryAcquire方法，并在方法中調(diào)用了父類Sync的nonfairTryAcquire方法，所以這里會調(diào)用到nonfairTryAcquire方法去嘗試獲取鎖。我們看看這個方法具體做了些什么。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
//非公平的獲取鎖final boolean nonfairTryAcquire(int acquires) { //獲取當前線程 final Thread current = Thread.currentThread(); //獲取當前同步狀態(tài) int c = getState(); //如果同步狀態(tài)為0則表明鎖沒有被占用 if (c == 0) { //使用CAS更新同步狀態(tài) if (compareAndSetState(0, acquires)) { //設(shè)置目前占用鎖的線程 setExclusiveOwnerThread(current); return true; } //否則的話就判斷持有鎖的是否是當前線程 }else if (current == getExclusiveOwnerThread()) { //如果鎖是被當前線程持有的, 就直接修改當前同步狀態(tài) int nextc = c + acquires; if (nextc < 0) { throw new Error("Maximum lock count exceeded"); } setState(nextc); return true; } //如果持有鎖的不是當前線程則返回失敗標志 return false;} |
nonfairTryAcquire方法是Sync的方法，我們可以看到線程進入此方法后首先去獲取同步狀態(tài)，如果同步狀態(tài)為0就使用CAS操作更改同步狀態(tài)，其實這又是獲取了一遍鎖。如果同步狀態(tài)不為0表明鎖被占用，此時會先去判斷持有鎖的線程是否是當前線程，如果是的話就將同步狀態(tài)加1，否則的話這次嘗試獲取鎖的操作宣告失敗。于是會調(diào)用addWaiter方法將線程添加到同步隊列。綜上來看，在非公平鎖的模式下一個線程在進入同步隊列之前會嘗試獲取兩遍鎖，如果獲取成功則不進入同步隊列排隊，否則才進入同步隊列排隊。接下來我們看看公平鎖的獲取方式。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
//實現(xiàn)公平鎖的同步器static final class FairSync extends Sync { //實現(xiàn)父類的抽象獲取鎖的方法 final void lock() { //調(diào)用acquire讓線程去同步隊列排隊獲取 acquire(1); } //嘗試獲取鎖的方法 protected final boolean tryAcquire(int acquires) { //獲取當前線程 final Thread current = Thread.currentThread(); //獲取當前同步狀態(tài) int c = getState(); //如果同步狀態(tài)0則表示鎖沒被占用 if (c == 0) { //判斷同步隊列是否有前繼結(jié)點 if (!hasQueuedPredecessors() && compareAndSetState(0, acquires)) { //如果沒有前繼結(jié)點且設(shè)置同步狀態(tài)成功就表示獲取鎖成功 setExclusiveOwnerThread(current); return true; } //否則判斷是否是當前線程持有鎖 }else if (current == getExclusiveOwnerThread()) { //如果是當前線程持有鎖就直接修改同步狀態(tài) int nextc = c + acquires; if (nextc < 0) { throw new Error("Maximum lock count exceeded"); } setState(nextc); return true; } //如果不是當前線程持有鎖則獲取失敗 return false; }} |
調(diào)用公平鎖的lock方法時會直接調(diào)用acquire方法。同樣的，acquire方法首先會調(diào)用FairSync重寫的tryAcquire方法來嘗試獲取鎖。在該方法中也是首先獲取同步狀態(tài)的值，如果同步狀態(tài)為0則表明此時鎖剛好被釋放，這時和非公平鎖不同的是它會先去調(diào)用hasQueuedPredecessors方法查詢同步隊列中是否有人在排隊，如果沒人在排隊才會去修改同步狀態(tài)的值，可以看到公平鎖在這里采取禮讓的方式而不是自己馬上去獲取鎖。除了這一步和非公平鎖不一樣之外，其他的操作都是一樣的。綜上所述，可以看到公平鎖在進入同步隊列之前只檢查了一遍鎖的狀態(tài)，即使是發(fā)現(xiàn)了鎖是開的也不會自己馬上去獲取，而是先讓同步隊列中的線程先獲取，所以可以保證在公平鎖下所有線程獲取鎖的順序都是先來后到的，這也保證了獲取鎖的公平性。
那么我們?yōu)槭裁床幌Ｍ墟i都是公平的呢？畢竟公平是一種好的行為，而不公平是一種不好的行為。由于線程的掛起和喚醒操作存在較大的開銷而影響系統(tǒng)性能，特別是在競爭激烈的情況下公平鎖將導致線程頻繁的掛起和喚醒操作，而非公平鎖可以減少這樣的操作，所以在性能上將會優(yōu)于公平鎖。另外，由于大部分線程使用鎖的時間都是非常短暫的，而線程的喚醒操作會存在延時情況，有可能在A線程被喚醒期間B線程馬上獲取了鎖并使用完釋放了鎖，這就導致了雙贏的局面，A線程獲取鎖的時刻并沒有推遲，但B線程提前使用了鎖，并且吞吐量也獲得了提高。
5.條件隊列的實現(xiàn)機制
內(nèi)置條件隊列存在一些缺陷，每個內(nèi)置鎖都只能有一個相關(guān)聯(lián)的條件隊列，這導致多個線程可能在同一個條件隊列上等待不同的條件謂詞，那么每次調(diào)用notifyAll時都會將所有等待的線程喚醒，當線程醒來后發(fā)現(xiàn)并不是自己等待的條件謂詞，轉(zhuǎn)而又會被掛起。這導致做了很多無用的線程喚醒和掛起操作，而這些操作將會大量浪費系統(tǒng)資源，降低系統(tǒng)的性能。如果想編寫一個帶有多個條件謂詞的并發(fā)對象，或者想獲得除了條件隊列可見性之外的更多控制權(quán)，就需要使用顯式的Lock和Condition而不是內(nèi)置鎖和條件隊列。一個Condition和一個Lock關(guān)聯(lián)在一起，就像一個條件隊列和一個內(nèi)置鎖相關(guān)聯(lián)一樣。要創(chuàng)建一個Condition，可以在相關(guān)聯(lián)的Lock上調(diào)用Lock.newCondition方法。我們先來看一個使用Condition的示例。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
|
public class BoundedBuffer { final Lock lock = new ReentrantLock(); final Condition notFull = lock.newCondition(); //條件謂詞：notFull final Condition notEmpty = lock.newCondition(); //條件謂詞：notEmpty final Object[] items = new Object[100]; int putptr, takeptr, count; //生產(chǎn)方法 public void put(Object x) throws InterruptedException { lock.lock(); try { while (count == items.length) notFull.await(); //隊列已滿, 線程在notFull隊列上等待 items[putptr] = x; if (++putptr == items.length) putptr = 0; ++count; notEmpty.signal(); //生產(chǎn)成功, 喚醒notEmpty隊列的結(jié)點 } finally { lock.unlock(); } } //消費方法 public Object take() throws InterruptedException { lock.lock(); try { while (count == 0) notEmpty.await(); //隊列為空, 線程在notEmpty隊列上等待 Object x = items[takeptr]; if (++takeptr == items.length) takeptr = 0; --count; notFull.signal(); //消費成功, 喚醒notFull隊列的結(jié)點 return x; } finally { lock.unlock(); } } } |
一個lock對象可以產(chǎn)生多個條件隊列，這里產(chǎn)生了兩個條件隊列notFull和notEmpty。當容器已滿時再調(diào)用put方法的線程需要進行阻塞，等待條件謂詞為真(容器不滿)才醒來繼續(xù)執(zhí)行；當容器為空時再調(diào)用take方法的線程也需要阻塞，等待條件謂詞為真(容器不空)才醒來繼續(xù)執(zhí)行。這兩類線程是根據(jù)不同的條件謂詞進行等待的，所以它們會進入兩個不同的條件隊列中阻塞，等到合適時機再通過調(diào)用Condition對象上的API進行喚醒。下面是newCondition方法的實現(xiàn)代碼。
|
1
2
3
4
5
6
7
8
9
10
11
|
//創(chuàng)建條件隊列public Condition newCondition() { return sync.newCondition();}abstract static class Sync extends AbstractQueuedSynchronizer { //新建Condition對象 final ConditionObject newCondition() { return new ConditionObject(); }} |
ReentrantLock上的條件隊列的實現(xiàn)都是基于AbstractQueuedSynchronizer的，我們在調(diào)用newCondition方法時所獲得的Condition對象就是AQS的內(nèi)部類ConditionObject的實例。所有對條件隊列的操作都是通過調(diào)用ConditionObject對外提供的API來完成的。有關(guān)于ConditionObject的具體實現(xiàn)大家可以查閱我的這篇文章《Java并發(fā)系列[4]----AbstractQueuedSynchronizer源碼分析之條件隊列》 ，這里就不重復贅述了。至此，我們對ReentrantLock源碼的剖析也告一段落，希望閱讀本篇文章能夠?qū)ψx者們理解并掌握ReentrantLock起到一定的幫助作用。
以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持服務(wù)器之家。
原文鏈接：http://www.cnblogs.com/liuyun1995/p/8462088.html
