專注于Java領域優(yōu)質(zhì)技術(shù)，歡迎關(guān)注

作者：Float_Luuu

提到 JAVA 加鎖，我們通常會想到 synchronized 關(guān)鍵字或者是 Java Concurrent Util(后面簡稱JCU)包下面的 Lock，今天就來扒一扒 Lock 是如何實現(xiàn)的，比如我們可以先提出一些問題：當我們通實例化一個 ReentrantLock 并且調(diào)用它的 lock 或 unlock 的時候，這其中發(fā)生了什么？如果多個線程同時對同一個鎖實例進行 lock 或 unlcok 操作，這其中又發(fā)生了什么？

什么是可重入鎖？

ReentrantLock 是可重入鎖，什么是可重入鎖呢？可重入鎖就是當前持有該鎖的線程能夠多次獲取該鎖，無需等待。可重入鎖是如何實現(xiàn)的呢？這要從 ReentrantLock 的一個內(nèi)部類 Sync 的父類說起，Sync 的父類是 AbstractQueuedSynchronizer(后面簡稱AQS)。

什么是AQS？

AQS 是 JDK1.5 提供的一個基于 FIFO 等待隊列實現(xiàn)的一個用于實現(xiàn)同步器的基礎框架，這個基礎框架的重要性可以這么說，JCU 包里面幾乎所有的有關(guān)鎖、多線程并發(fā)以及線程同步器等重要組件的實現(xiàn)都是基于 AQS 這個框架。AQS 的核心思想是基于 volatile int state 這樣的一個屬性同時配合 Unsafe 工具對其原子性的操作來實現(xiàn)對當前鎖的狀態(tài)進行修改。當 state 的值為 0 的時候，標識改 Lock 不被任何線程所占有。

ReentrantLock 鎖的架構(gòu)

ReentrantLock 的架構(gòu)相對簡單，主要包括一個 Sync 的內(nèi)部抽象類以及 Sync 抽象類的兩個實現(xiàn)類。上面已經(jīng)說過了 Sync 繼承自 AQS，他們的結(jié)構(gòu)示意圖如下：

上圖除了 AQS 之外，我把 AQS 的父類 AbstractOwnableSynchronizer(后面簡稱AOS)也畫了進來，可以稍微提一下，AOS 主要提供一個 exclusiveOwnerThread 屬性，用于關(guān)聯(lián)當前持有該所的線程。另外、Sync 的兩個實現(xiàn)類分別是 NonfairSync 和 FairSync，由名字大概可以猜到，一個是用于實現(xiàn)公平鎖、一個是用于實現(xiàn)非公平鎖。那么 Sync 為什么要被設計成內(nèi)部類呢？我們可以看看 AQS 主要提供了哪些 protect 的方法用于修改 state 的狀態(tài)，我們發(fā)現(xiàn) Sync 被設計成為安全的外部不可訪問的內(nèi)部類。ReentrantLock 中所有涉及對 AQS 的訪問都要經(jīng)過 Sync，其實，Sync 被設計成為內(nèi)部類主要是為了安全性考慮，這也是作者在 AQS 的 comments 上強調(diào)的一點。

AQS 的等待隊列

作為 AQS 的核心實現(xiàn)的一部分，舉個例子來描述一下這個隊列長什么樣子，我們假設目前有三個線程 Thread1、Thread2、Thread3 同時去競爭鎖，如果結(jié)果是 Thread1 獲取了鎖，Thread2 和 Thread3 進入了等待隊列，那么他們的樣子如下：

AQS 的等待隊列基于一個雙向鏈表實現(xiàn)的，HEAD 節(jié)點不關(guān)聯(lián)線程，后面兩個節(jié)點分別關(guān)聯(lián) Thread2 和 Thread3，他們將會按照先后順序被串聯(lián)在這個隊列上。這個時候如果后面再有線程進來的話將會被當做隊列的 TAIL。

1)入隊列

我們來看看，當這三個線程同時去競爭鎖的時候發(fā)生了什么？代碼：

解讀：三個線程同時進來，他們會首先會通過 CAS 去修改 state 的狀態(tài)，如果修改成功，那么競爭成功，因此這個時候三個線程只有一個 CAS 成功，其他兩個線程失敗，也就是 tryAcquire 返回 false。接下來，addWaiter 會把將當前線程關(guān)聯(lián)的 EXCLUSIVE 類型的節(jié)點入隊列：

解讀：如果隊尾節(jié)點不為 null，則說明隊列中已經(jīng)有線程在等待了，那么直接入隊尾。對于我們舉的例子，這邊的邏輯應該是走 enq，也就是開始隊尾是 null，其實這個時候整個隊列都是 null 的。代碼：

解讀：如果 Thread2 和 Thread3 同時進入了 enq，同時 t==null，則進行 CAS 操作對隊列進行初始化，這個時候只有一個線程能夠成功，然后他們繼續(xù)進入循環(huán)，第二次都進入了 else 代碼塊，這個時候又要進行 CAS 操作，將自己放在隊尾，因此這個時候又是只有一個線程成功，我們假設是 Thread2 成功，哈哈，Thread2 開心的返回了，Thread3 失落的再進行下一次的循環(huán)，最終入隊列成功，返回自己。

2)并發(fā)問題

基于上面兩段代碼，他們是如何實現(xiàn)不進行加鎖，當有多個線程，或者說很多很多的線程同時執(zhí)行的時候，怎么能保證最終他們都能夠乖乖的入隊列而不會出現(xiàn)并發(fā)問題的呢？這也是這部分代碼的經(jīng)典之處，多線程競爭，熱點、單點在隊列尾部，多個線程都通過【CAS+死循環(huán)】這個free-lock黃金搭檔來對隊列進行修改，每次能夠保證只有一個成功，如果失敗下次重試，如果是N個線程，那么每個線程最多 loop N 次，最終都能夠成功。

3)掛起等待線程

上面只是 addWaiter 的實現(xiàn)部分，那么節(jié)點入隊列之后會繼續(xù)發(fā)生什么呢？那就要看看 acquireQueued 是怎么實現(xiàn)的了，為保證文章整潔，代碼我就不貼了，同志們自行查閱，我們還是以上面的例子來看看，Thread2 和 Thread3 已經(jīng)被放入隊列了，進入 acquireQueued 之后：

對于 Thread2 來說，它的 prev 指向 HEAD，因此會首先再嘗試獲取鎖一次，如果失敗，則會將 HEAD 的 waitStatus 值為 SIGNAL，下次循環(huán)的時候再去嘗試獲取鎖，如果還是失敗，且這個時候 prev 節(jié)點的 waitStatus 已經(jīng)是 SIGNAL，則這個時候線程會被通過 LockSupport 掛起。

對于 Thread3 來說，它的 prev 指向 Thread2，因此直接看看 Thread2 對應的節(jié)點的 waitStatus 是否為 SIGNAL，如果不是則將它設置為 SIGNAL，再給自己一次去看看自己有沒有資格獲取鎖，如果 Thread2 還是擋在前面，且它的 waitStatus 是 SIGNAL，則將自己掛起。

如果 Thread1 死死的握住鎖不放，那么 Thread2 和 Thread3 現(xiàn)在的狀態(tài)就是掛起狀態(tài)啦，而且 HEAD，以及 Thread 的 waitStatus 都是 SIGNAL，盡管他們在整個過程中曾經(jīng)數(shù)次去嘗試獲取鎖，但是都失敗了，失敗了不能死循環(huán)呀，所以就被掛起了。當前狀態(tài)如下：

鎖釋放-等待線程喚起

我們來看看當 Thread1 這個時候終于做完了事情，調(diào)用了 unlock 準備釋放鎖，這個時候發(fā)生了什么。代碼：

解讀：首先，Thread1 會修改AQS的state狀態(tài)，加入之前是 1，則變?yōu)?0，注意這個時候?qū)τ诜枪芥i來說是個很好的插入機會，舉個例子，如果鎖是公平鎖，這個時候來了 Thread4，那么這個鎖將會被 Thread4 搶去。。。

我們繼續(xù)走常規(guī)路線來分析，當 Thread1 修改完狀態(tài)了，判斷隊列是否為 null，以及隊頭的 waitStatus 是否為 0，如果 waitStatus 為 0，說明隊列無等待線程，按照我們的例子來說，隊頭的 waitStatus 為 SIGNAL=-1，因此這個時候要通知隊列的等待線程，可以來拿鎖啦，這也是 unparkSuccessor 做的事情，unparkSuccessor 主要做三件事情：

將隊頭的 waitStatus 設置為 0。

通過從隊列尾部向隊列頭部移動，找到最后一個 waitStatus<=0 的那個節(jié)點，也就是離隊頭最近的沒有被cancelled的那個節(jié)點，隊頭這個時候指向這個節(jié)點。

將這個節(jié)點喚醒，其實這個時候 Thread1 已經(jīng)出隊列了。

還記得線程在哪里掛起的么，上面說過了，在 acquireQueued 里面，我沒有貼代碼，自己去看哦。這里我們也大概能理解 AQS 的這個隊列為什么叫 FIFO 隊列了，因此每次喚醒僅僅喚醒隊頭等待線程，讓隊頭等待線程先出。

羊群效應

這里說一下羊群效應，當有多個線程去競爭同一個鎖的時候，假設鎖被某個線程占用，那么如果有成千上萬個線程在等待鎖，有一種做法是同時喚醒這成千上萬個線程去去競爭鎖，這個時候就發(fā)生了羊群效應，海量的競爭必然造成資源的劇增和浪費，因此終究只能有一個線程競爭成功，其他線程還是要老老實實的回去等待。AQS 的 FIFO 的等待隊列給解決在鎖競爭方面的羊群效應問題提供了一個思路：保持一個 FIFO 隊列，隊列每個節(jié)點只關(guān)心其前一個節(jié)點的狀態(tài)，線程喚醒也只喚醒隊頭等待線程。其實這個思路已經(jīng)被應用到了分布式鎖的實踐中，見：Zookeeper 分布式鎖的改進實現(xiàn)方案。

總結(jié)

這篇文章粗略的介紹一下 ReentrantLock 以及鎖實現(xiàn)基礎框架 AQS 的實現(xiàn)原理，大致上通過舉了個三個線程競爭鎖的例子，從 lock、unlock 過程發(fā)生了什么這個問題，深入了解 AQS 基于狀態(tài)的標識以及 FIFO 等待隊列方面的工作原理，最后擴展介紹了一下羊群效應問題，博主才疏學淺，還請多多指教。

總結(jié)

以上是生活随笔為你收集整理的reentrantlock非公平锁不会随机挂起线程?_程序员必须要知道的ReentrantLock 及 AQS 实现原理...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。