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