摘要：開始獲取鎖終于輪到出場了，的調(diào)用過程和完全一樣，同樣拿不到鎖，然后加入到等待隊列隊尾然后，在阻塞前需要把前驅(qū)結(jié)點的狀態(tài)置為，以確保將來可以被喚醒至此，的執(zhí)行也暫告一段落了安心得在等待隊列中睡覺。

本文首發(fā)于一世流云的專欄：https://segmentfault.com/blog...

本章以ReentrantLock的調(diào)用為例，說明AbstractQueuedSynchronizer提供的獨占功能。
本章結(jié)構(gòu)如下：

以ReentrantLock的公平策略為例，分析AbstractQueuedSynchronizer的獨占功能

以ReentrantLock的非公平策略為例，分析AbstractQueuedSynchronizer的獨占功能

分析AbstractQueuedSynchronizer的鎖中斷、限時等待等功能

本節(jié)對ReentrantLock公平策略的分析基于以下示例：

假設(shè)現(xiàn)在有3個線程：ThreadA、ThreadB、ThreadC，一個公平的獨占鎖，3個線程會依次嘗試去獲取鎖：ReentrantLock lock=new ReentrantLock(true);

線程的操作時序如下：

//ThreadA    lock

//ThreadB    lock

//ThreadC    lock

//ThreadA    release

//ThreadB    release

//ThreadC    release

ThreadA首先調(diào)用ReentrantLock的lock方法，我們看下該方法的內(nèi)部：

最終其實調(diào)用了FairSync的lock方法：

acquire方法來自AQS：

其中tryAcquire方法需要AQS的子類自己去實現(xiàn)，我們來看下ReentrantLock中的實現(xiàn)：

可以看到，在ReentrantLock中，同步狀態(tài)State的含義如下：

ThreadA是首個獲取鎖的線程，所以上述方法會返回true，第一階段結(jié)束。（ThreadA一直保持占有鎖的狀態(tài)）
此時，AQS中的等待隊列還是空：

終于，ThreadB要登場了，一樣，ThreadB先去調(diào)用lock方法，最終調(diào)用AQS的acquire方法：

tryAcquire方法肯定是返回false（因為此時ThreadA占有著鎖）。
接下來看下addWaiter方法，這個方法其實就是將當(dāng)前調(diào)用線程包裝成一個【獨占結(jié)點】，添加到等待隊列尾部。

這里關(guān)鍵是enq方法，因為并發(fā)插入的情況存在，所以該方法設(shè)計成了自旋操作，保證結(jié)點能成功插入，具體步驟如下：
①當(dāng)隊列為空的時候，先創(chuàng)建一個dummy頭結(jié)點；

②進(jìn)入下一次循環(huán)，插入隊尾結(jié)點。

好了，ThreadB已經(jīng)被包裝成結(jié)點插入隊尾了，接下來會調(diào)用acquireQueued方法，這也是AQS中最重要的方法之一：

在AQS中，等待隊列中的線程都是阻塞的，當(dāng)某個線程被喚醒時，只有該線程是首結(jié)點（線程）時，才有權(quán)去嘗試獲取鎖。

上述方法中，將ThreadB包裝成結(jié)點插入隊尾后，先判斷ThreadB是否是首結(jié)點（注意不是頭結(jié)點，頭結(jié)點是個dummy結(jié)點），發(fā)現(xiàn)確實是首結(jié)點（node.predecessor==head），于是調(diào)用tryAcquire嘗試獲取鎖，但是獲取失敗了（此時ThreadA占有著鎖），就要判斷是否需要阻塞當(dāng)前線程。

判斷是否需要阻塞線程：

注意，對于獨占功能，只使用了3種結(jié)點狀態(tài)：

對于在等待隊列中的線程，如果要阻塞它，需要確保將來有線程可以喚醒它，AQS中通過將前驅(qū)結(jié)點的狀態(tài)置為SIGNAL:-1來表示將來會喚醒當(dāng)前線程，當(dāng)前線程可以安心的阻塞。

看下圖或許比較好理解：
①插入完ThreadB后，隊列的初始狀態(tài)如下：

②雖然ThreadB是隊首結(jié)點，但是它拿不到鎖（被ThreadA占有著），所以ThreadB會阻塞，但在阻塞前需要設(shè)置下前驅(qū)的狀態(tài)，以便將來可以喚醒我：

至此，ThreadB的執(zhí)行也暫告一段落了（安心得在等待隊列中睡覺）。

注意：補充一點，如果ThreadB在阻塞過程中被中斷，其實是不會拋出異常的，只會在acquireQueued方法返回時，告訴調(diào)用者在阻塞器件有沒被中斷過，具體如果處理，要不要拋出異常，取決于調(diào)用者，這其實是一種延時中斷機制。

終于輪到ThreadC出場了，ThreadC的調(diào)用過程和ThreadB完全一樣，同樣拿不到鎖，然后加入到等待隊列隊尾：

然后，ThreadC在阻塞前需要把前驅(qū)結(jié)點的狀態(tài)置為SIGNAL：-1，以確保將來可以被喚醒：

至此，ThreadC的執(zhí)行也暫告一段落了（安心得在等待隊列中睡覺）。

ThreadA終于使用完了臨界資源，要釋放鎖了，來看下ReentrantLock的unlock方法：

unlock內(nèi)部調(diào)用了AQS的release方法，傳參1：

嘗試釋放鎖的操作tryRelease：

釋放成功后，調(diào)用unparkSuccessor方法，喚醒隊列中的首結(jié)點：

此時，隊列狀態(tài)為：

好了，隊首結(jié)點（ThreadB）被喚醒了。
ThreadB會繼續(xù)從以下位置開始執(zhí)行，先返回一個中斷標(biāo)識，用于表示ThreadB在阻塞期間有沒被中斷過：

然后ThreadB又開始了自旋操作，被喚醒的是隊首結(jié)點，所以可以嘗試tryAcquire獲取鎖，此時獲取成功（ThreadA已經(jīng)釋放了鎖）。
獲取成功后會調(diào)用setHead方法，將頭結(jié)點置為當(dāng)前結(jié)點，并清除線程信息：

最終的隊列狀態(tài)如下：

ThreadB也終于使用完了臨界資源，要釋放鎖了，過程和ThreadA釋放時一樣，釋放成功后，會調(diào)用unparkSuccessor方法，喚醒隊列中的首結(jié)點：

隊首結(jié)點（ThreadC）被喚醒后，繼續(xù)從原來的阻塞處向下執(zhí)行，并嘗試獲取鎖，獲取成功，最終隊列狀態(tài)如下：

ThreadC也終于使用完了臨界資源，要釋放鎖了。釋放成功后，調(diào)用unparkSuccessor方法，喚醒隊列中的首結(jié)點：
此時隊列中只剩下一個頭結(jié)點（dummy），所以這個方法其實什么都不做。最終隊列的狀態(tài)就是只有一個dummy頭結(jié)點。

至此，AQS的獨占功能已經(jīng)差不多分析完了，剩下還有幾個內(nèi)容沒分析：

鎖中斷功能

限時等待功能

Conditon等待功能

這些功能將在后續(xù)章節(jié)陸續(xù)分析。

ReenrantLock非公平策略的內(nèi)部實現(xiàn)和公平策略沒啥太大區(qū)別：
非公平策略和公平策略的最主要區(qū)別在于：

公平鎖獲取鎖時，會判斷等待隊列中是否有線程排在當(dāng)前線程前面。只有沒有情況下，才去獲取鎖，這是公平的含義。

非公平鎖獲取鎖時，會立即嘗試修改同步狀態(tài)，失敗后再調(diào)用AQS的acquire方法。

acquire方法會轉(zhuǎn)調(diào)非公平鎖自身的tryAcquire方法，其實最終是調(diào)了nofairTryAcquire方法，而該方法相對于公平鎖，只是少了“隊列中是否有其它線程排在當(dāng)前線程前”這一判斷：

還是以ReentrantLock為例，來看下AQS是如何實現(xiàn)鎖中斷和超時的。
我們知道ReentrantLock的lockInterruptibly方法是會響應(yīng)中斷的。（線程如果在阻塞過程中被中斷，會拋出InterruptedException異常）

該方法調(diào)用了AQS的acquireInterruptibly方法：

上述代碼會先去嘗試獲取鎖，如果失敗，則調(diào)用doAcquireInterruptibly方法，如下：

很眼熟有木有？看下和acquireQueued方法的對比，唯一的區(qū)別就是：
當(dāng)調(diào)用線程獲取鎖失敗，進(jìn)入阻塞后，如果中途被中斷，acquireQueued只是用一個標(biāo)識記錄線程被中斷過，而doAcquireInterruptibly則是直接拋出異常。

Lock接口中有一個方法：tryLock，用于在指定的時間內(nèi)嘗試獲取鎖，獲取不到就返回。
ReentrantLock實現(xiàn)了該方法，可以看到，該方法內(nèi)部調(diào)用了AQS的tryAcquireNanos方法：

tryAcquireNanos方法是響應(yīng)中斷的，先嘗試獲取一次鎖，失敗則調(diào)用doAcquireNanos方法進(jìn)行超時等待：

關(guān)鍵是doAcquireNano方法，和acquireQuqued方法類似，又是一個自旋操作，在超時前不斷嘗試獲取鎖，獲取不到則阻塞（加上了等待時間的判斷）。該方法內(nèi)部，調(diào)用了LockSupport.parkNanos來超時阻塞線程：

LockSupport.parkNanos內(nèi)部其實通過Unsafe這個類來操作線程的阻塞，底層是一個native方法：

如果當(dāng)前線程在指定時間內(nèi)獲取不到鎖，除了返回false外，最終還會執(zhí)行cancelAcquire方法：

為了便于理解還是以3個線程為例：

假設(shè)現(xiàn)在有3個線程：ThreadA、ThreadB、ThreadC，一個公平的獨占鎖，3個線程會依次嘗試去獲取鎖，不過此時加上了限時等待：ThreadB等待10s，ThreadA等待20s。

ReentrantLock lock=new ReentrantLock(true);

//ThreadA    tryLock

//ThreadB    tryLock, 10s

//ThreadC    tryLock, 20s

//ThreadA    release

//ThreadB    release

//ThreadC    release

1. ThreadA首先獲取到鎖，ThreadB和ThreadC依次嘗試去獲取鎖
ThreadB和ThreadC經(jīng)過兩輪自旋操作后，等待隊列的情況如下：

2. ThreadB先到超時時間
調(diào)用了cancelAcquire方法取消操作，隊列狀態(tài)變成：

3. ThreadC到達(dá)超時時間
調(diào)用了cancelAcquire方法取消操作，隊列狀態(tài)變成：

在退出cancelAcquire后，原來ThreadB和ThreadC對應(yīng)的結(jié)點會被JVM垃圾回收器回收。

本章從ReentrantLock入手，分析AQS的獨占功能的內(nèi)部實現(xiàn)細(xì)節(jié)。下一章，從CountDownLatch入手，看下AQS的共享功能如何實現(xiàn)。