[[387823]]

深入淺出AbstractQueuedSynchronizer

在Java多線程編程中，重入鎖(ReentrantLock) 和信號(hào)量(Semaphore)是兩個(gè)極其重要的并發(fā)控制工具。相信大部分讀者都應(yīng)該比較熟悉它們的使用(如果不清楚的小伙伴，趕快拿出書本翻閱一下)。

但是不知道大家是不是有了解過重入鎖和信號(hào)量的實(shí)現(xiàn)細(xì)節(jié)? 我就帶大家看一看它們的具體實(shí)現(xiàn)。

首先，先上一張重要的類圖，來說明一下三者之間的關(guān)系：

可以看到， 重入鎖和信號(hào)量都在自己內(nèi)部，實(shí)現(xiàn)了一個(gè)AbstractQueuedSynchronizer的子類，子類的名字都是Sync。而這個(gè)Sync類，也正是重入鎖和信號(hào)量的核心實(shí)現(xiàn)。子類Sync中的代碼也比較少，其核心算法都由AbstractQueuedSynchronizer提供。因此，可以說，只要大家了解了AbstractQueuedSynchronizer，就清楚得知道重入鎖和信號(hào)量的實(shí)現(xiàn)原理了。

了解AbstractQueuedSynchronizer你必須知道的

在正是進(jìn)入AbstractQueuedSynchronizer之前，還有一些基礎(chǔ)知識(shí)需要大家了解，這樣才能更好的理解AbstractQueuedSynchronizer的實(shí)現(xiàn)。

基于許可的多線程控制

為了控制多個(gè)線程訪問共享資源 ，我們需要為每個(gè)訪問共享區(qū)間的線程派發(fā)一個(gè)許可。拿到一個(gè)許可的線程才能進(jìn)入共享區(qū)間活動(dòng)。當(dāng)線程完成工作后，離開共享區(qū)間時(shí)，必須要?dú)w還許可，以確保后續(xù)的線程可以正常取得許可。如果許可用完了，那么線程進(jìn)入共享區(qū)間時(shí)，就必須等待，這就是控制多線程并行的基本思想。

打個(gè)比方，一大群孩子去游樂場(chǎng)玩摩天輪，摩天輪上只能坐20個(gè)孩子。但是卻來了100個(gè)小孩。那么許可以的個(gè)數(shù)就是20。也就說一次只有20個(gè)小孩可以上摩天輪玩，其他的孩子必須排隊(duì)等待。只有等摩天輪上的孩子離開控制一個(gè)位置時(shí)，才能有其他小孩上去玩。

因此，使用許可控制線程行為和排隊(duì)玩摩天輪差不多就是一個(gè)意思了。

排他鎖和共享鎖

第二個(gè)重要的概念就是排他鎖(exclusive)和共享鎖(shared)。顧名思義，在排他模式上，只有一個(gè)線程可以訪問共享變量，而共享模式則允許多個(gè)線程同時(shí)訪問。簡(jiǎn)單地說，重入鎖是排他的;信號(hào)量是共享的。

用摩天輪的話來說，排他鎖就是雖然我這里有20個(gè)位置，但是小朋友也只能一個(gè)一個(gè)上哦，多出來的位置怎么辦呢，可以空著，也可以讓摩天輪上唯一的小孩換著做，他想坐哪兒就坐哪兒，1分鐘換個(gè)位置，都沒有關(guān)系。而共享鎖，就是玩耍摩天輪正常的打開方式了。

LockSupport

LockSupport可以理解為一個(gè)工具類。它的作用很簡(jiǎn)單，就是掛起和繼續(xù)執(zhí)行線程。它的常用的API如下：

• public static void park() : 如果沒有可用許可，則掛起當(dāng)前線程
• public static void unpark(Thread thread)：給thread一個(gè)可用的許可，讓它得以繼續(xù)執(zhí)行

因?yàn)閱卧~park的意思就是停車，因此這里park()函數(shù)就表示讓線程暫停。反之，unpark()則表示讓線程繼續(xù)執(zhí)行。

需要注意的是，LockSupport本身也是基于許可的實(shí)現(xiàn)，如何理解這句話呢，請(qǐng)看下面的代碼：

LockSupport.unpark(Thread.currentThread()); 
LockSupport.park(); 

大家可以猜一下，park()之后，當(dāng)前線程是停止，還是 可以繼續(xù)執(zhí)行呢?

答案是：可以繼續(xù)執(zhí)行。那是因?yàn)樵趐ark()之前，先執(zhí)行了unpark()，進(jìn)而釋放了一個(gè)許可，也就是說當(dāng)前線程有一個(gè)可用的許可。而park()在有可用許可的情況下，是不會(huì)阻塞線程的。

綜上所述，park()和unpark()的執(zhí)行效果和它調(diào)用的先后順序沒有關(guān)系。這一點(diǎn)相當(dāng)重要，因?yàn)樵谝粋€(gè)多線程的環(huán)境中，我們往往很難保證函數(shù)調(diào)用的先后順序(都在不同的線程中并發(fā)執(zhí)行)，因此，這種基于許可的做法能夠最大限度保證程序不出錯(cuò)。

與park()和unpark()相比， 一個(gè)典型的反面教材就是Thread.resume()和Thread.suspend()。

看下面的代碼：

Thread.currentThread().resume(); 
Thread.currentThread().suspend(); 

首先讓線程繼續(xù)執(zhí)行，接著在掛起線程。這個(gè)寫法和上面的park()的示例非常接近，但是運(yùn)行結(jié)果卻是截然不同的。在這里，當(dāng)前線程就是卡死。

因此，使用park()和unpark()才是我們的首選。而在AbstractQueuedSynchronizer中，也正是使用了LockSupport的park()和unpark()操作來控制線程的運(yùn)行狀態(tài)的。

AbstractQueuedSynchronizer內(nèi)部數(shù)據(jù)結(jié)構(gòu)

好了，基礎(chǔ)的部分就介紹到這里。下面，讓我們切入正題：首先來看一下AbstractQueuedSynchronizer的內(nèi)部數(shù)據(jù)結(jié)構(gòu)。

在AbstractQueuedSynchronizer內(nèi)部，有一個(gè)隊(duì)列，我們把它叫做同步等待隊(duì)列。它的作用是保存等待在這個(gè)鎖上的線程(由于lock()操作引起的等待)。此外，為了維護(hù)等待在條件變量上的等待線程，AbstractQueuedSynchronizer又需要再維護(hù)一個(gè)條件變量等待隊(duì)列，也就是那些由Condition.await()引起阻塞的線程。

由于一個(gè)重入鎖可以生成多個(gè)條件變量對(duì)象，因此，一個(gè)重入鎖就可能有多個(gè)條件變量等待隊(duì)列。實(shí)際上，每個(gè)條件變量對(duì)象內(nèi)部都維護(hù)了一個(gè)等待列表。其邏輯結(jié)構(gòu)如下所示：

下面的類圖展示了代碼層面的具體實(shí)現(xiàn)：

可以看到，無論是同步等待隊(duì)列，還是條件變量等待隊(duì)列，都使用同一個(gè)Node類作為鏈表的節(jié)點(diǎn)。對(duì)于同步等待隊(duì)列，Node中包括鏈表的上一個(gè)元素prev，下一個(gè)元素next和線程對(duì)象thread。對(duì)于條件變量等待隊(duì)列，還使用nextWaiter表示下一個(gè)等待在條件變量隊(duì)列中的節(jié)點(diǎn)。

Node節(jié)點(diǎn)另外一個(gè)重要的成員是waitStatus，它表示節(jié)點(diǎn)等待在隊(duì)列中的狀態(tài)：

• CANCELLED：表示線程取消了等待。如果取得鎖的過程中發(fā)生了一些異常，則可能出現(xiàn)取消的情況，比如等待過程中出現(xiàn)了中斷異?；蛘叱霈F(xiàn)了timeout。
• SIGNAL：表示后續(xù)節(jié)點(diǎn)需要被喚醒。
• CONDITION：線程等待在條件變量隊(duì)列中。
• PROPAGATE：在共享模式下，無條件傳播releaseShared狀態(tài)。早期的JDK并沒有這個(gè)狀態(tài)，咋看之下，這個(gè)狀態(tài)是多余的。引入這個(gè)狀態(tài)是為了解決共享鎖并發(fā)釋放引起線程掛起的bug 6801020。(隨著JDK的不斷完善，它的代碼也越來越難懂了 :(，就和我們自己的工程代碼一樣，bug修多了，細(xì)節(jié)就顯得越來越晦澀)
• 0：初始狀態(tài)

其中CANCELLED=1，SIGNAL=-1，CONDITION=-2，PROPAGATE=-3 。在具體的實(shí)現(xiàn)中，就可以簡(jiǎn)單的通過waitStatus釋放小于等于0，來判斷是否是CANCELLED狀態(tài)。

排他鎖

了解了AbstractQueuedSynchronizer的基本實(shí)現(xiàn)思路和數(shù)據(jù)結(jié)構(gòu)，接下來一起看一下它的實(shí)現(xiàn)細(xì)節(jié)吧。首先，來看一下排他鎖的實(shí)現(xiàn)。重入鎖是一種 典型的排他鎖。

請(qǐng)求鎖

下面是排他鎖獲得請(qǐng)求許可的代碼：

public final void acquire(int arg) { 
    //嘗試獲得許可， arg為許可的個(gè)數(shù)。對(duì)于重入鎖來說，每次請(qǐng)求1個(gè)。 
    if (!tryAcquire(arg) && 
    // 如果tryAcquire 失敗，則先使用addWaiter()將當(dāng)前線程加入同步等待隊(duì)列 
    // 然后繼續(xù)嘗試獲得鎖 
    acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) 
    selfInterrupt(); 
} 

進(jìn)入一步看一下tryAcquire()函數(shù)。該函數(shù)的作用是嘗試獲得一個(gè)許可。對(duì)于AbstractQueuedSynchronizer來說，這是一個(gè)未實(shí)現(xiàn)的抽象函數(shù)。

具體實(shí)現(xiàn)在子類中。在重入鎖，讀寫鎖，信號(hào)量等實(shí)現(xiàn)中， 都有各自的實(shí)現(xiàn)。

如果tryAcquire()成功，則acquire()直接返回成功。如果失敗，就用addWaiter()將當(dāng)前線程加入同步等待隊(duì)列。

接著， 對(duì)已經(jīng)在隊(duì)列中的線程請(qǐng)求鎖，使用acquireQueued()函數(shù)，從函數(shù)名字上可以看到，其參數(shù)node，必須是一個(gè)已經(jīng)在隊(duì)列中等待的節(jié)點(diǎn)。它的功能就是為已經(jīng)在隊(duì)列中的Node請(qǐng)求一個(gè)許可。

這個(gè)函數(shù)大家要好好看看，因?yàn)闊o論是普通的lock()方法，還是條件變量的await()都會(huì)使用這個(gè)方法。

條件變量等待

如果調(diào)用Condition.await()，那么線程也會(huì)進(jìn)入等待，下面來看實(shí)現(xiàn)：

Condition對(duì)象的signal()通知

signal()通知的時(shí)候，是在條件等待隊(duì)列中，按照FIFO進(jìn)行，首先從第一個(gè)節(jié)點(diǎn)下手：

release()釋放鎖

釋放排他鎖很簡(jiǎn)單

public final boolean release(int arg) { 
    //tryRelease()是一個(gè)抽象方法，在子類中有具體實(shí)現(xiàn)和tryAcquire()一樣 
    if (tryRelease(arg)) { 
        Node h = head; 
        if (h != null && h.waitStatus != 0) 
            // 從隊(duì)列中喚醒一個(gè)等待中的線程（遇到CANCEL的直接跳過） 
            unparkSuccessor(h); 
            return true; 
    } 
    return false; 
} 

共享鎖

與排他鎖相比，共享鎖的實(shí)現(xiàn)略微復(fù)雜一點(diǎn)。這也很好理解。因?yàn)榕潘i的場(chǎng)景很簡(jiǎn)單，單進(jìn)單出，而共享鎖就不一樣了?？赡苁荖進(jìn)M出，處理起來要麻煩一些。但是，他們的核心思想還是一致的。共享鎖的幾個(gè)典型應(yīng)用有：信號(hào)量，讀寫鎖中的寫鎖。

獲得共享鎖

為了實(shí)現(xiàn)共享鎖，在AbstractQueuedSynchronizer中，專門有一套針對(duì)共享鎖的方法。

獲得共享鎖使用acquireShared()方法：

釋放共享鎖

釋放共享鎖的代碼如下：

public final boolean releaseShared(int arg) { 
    //tryReleaseShared()嘗試釋放許可，這是一個(gè)抽象方法，需要在子類中實(shí)現(xiàn) 
    if (tryReleaseShared(arg)) { 
        //上述代碼中已經(jīng)出現(xiàn)這個(gè)函數(shù)了，就是喚醒線程，設(shè)置傳播狀態(tài) 
        doReleaseShared(); 
        return true; 
    } 
    return false; 
} 

寫在最后的話

AbstractQueuedSynchronizer 是一個(gè)比較復(fù)雜的實(shí)現(xiàn)，要完全理解其中的細(xì)節(jié)還需要慢慢琢磨。

這篇文章也只能起到一個(gè)拋磚引玉的作用，將AbstractQueuedSynchronizer的設(shè)計(jì)思想，核心數(shù)據(jù)結(jié)構(gòu)已經(jīng)核心實(shí)現(xiàn)代碼展示給大家。希望對(duì)大家理解AbstractQueuedSynchronizer的實(shí)現(xiàn)，以及理解重入鎖，信號(hào)量，讀寫鎖有一定幫助。

多線程系列還在在路上會(huì)繼續(xù)安排，我是敖丙，你知道的越多，你不知道的越多，我們下期再見。