在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加鎖的示例代碼。
public void doSomething() { //默認是獲取一個非公平鎖ReentrantLock lock = new ReentrantLock(); try{ //執行前先加鎖lock.lock(); //執行操作... }finally{ //最後釋放鎖lock.unlock(); }}以下是獲取鎖和釋放鎖這兩個操作的API。
//獲取鎖的操作public void lock() { sync.lock();}//釋放鎖的操作public void unlock() { sync.release(1);}可以看到獲取鎖和釋放鎖的操作分別委託給Sync對象的lock方法和release方法。
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的兩個構造方法都做了些什麼？
//默認無參構造器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()方法，我們再來回顧一下。
//釋放鎖的操作(獨占模式)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裡面。
//嘗試釋放鎖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實例則表明為公平鎖。如果是公平鎖，線程將按照它們發出請求的順序來獲得鎖，但在非公平鎖上，則允許插隊行為：當一個線程請求非公平的鎖時，如果在發出請求的同時該鎖的狀態變為可用，那麼這個線程將跳過隊列中所有等待的線程直接獲得這個鎖。下面我們先看看非公平鎖的獲取方式。
//非公平同步器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方法去嘗試獲取鎖。我們看看這個方法具體做了些什麼。
//非公平的獲取鎖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方法將線程添加到同步隊列。綜上來看，在非公平鎖的模式下一個線程在進入同步隊列之前會嘗試獲取兩遍鎖，如果獲取成功則不進入同步隊列排隊，否則才進入同步隊列排隊。接下來我們看看公平鎖的獲取方式。
//實現公平鎖的同步器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的示例。
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方法的實現代碼。
//創建條件隊列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起到一定的幫助作用。
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持武林網。