深入淺出AbstractQueuedSynchronizer
深入淺出AbstractQueuedSynchronizer
在Java多線程編程中，重入鎖(ReentrantLock) 和信號量(Semaphore)是兩個極其重要的并發(fā)控制工具。相信大部分讀者都應(yīng)該比較熟悉它們的使用(如果不清楚的小伙伴，趕快拿出書本翻閱一下)。
但是不知道大家是不是有了解過重入鎖和信號量的實(shí)現(xiàn)細(xì)節(jié)? 我就帶大家看一看它們的具體實(shí)現(xiàn)。
首先，先上一張重要的類圖，來說明一下三者之間的關(guān)系：
可以看到， 重入鎖和信號量都在自己內(nèi)部，實(shí)現(xiàn)了一個AbstractQueuedSynchronizer的子類，子類的名字都是Sync。而這個Sync類，也正是重入鎖和信號量的核心實(shí)現(xiàn)。子類Sync中的代碼也比較少，其核心算法都由AbstractQueuedSynchronizer提供。因此，可以說，只要大家了解了AbstractQueuedSynchronizer，就清楚得知道重入鎖和信號量的實(shí)現(xiàn)原理了。
了解AbstractQueuedSynchronizer你必須知道的
在正是進(jìn)入AbstractQueuedSynchronizer之前，還有一些基礎(chǔ)知識需要大家了解，這樣才能更好的理解AbstractQueuedSynchronizer的實(shí)現(xiàn)。
基于許可的多線程控制
為了控制多個線程訪問共享資源 ，我們需要為每個訪問共享區(qū)間的線程派發(fā)一個許可。拿到一個許可的線程才能進(jìn)入共享區(qū)間活動。當(dāng)線程完成工作后，離開共享區(qū)間時，必須要?dú)w還許可，以確保后續(xù)的線程可以正常取得許可。如果許可用完了，那么線程進(jìn)入共享區(qū)間時，就必須等待，這就是控制多線程并行的基本思想。
打個比方，一大群孩子去游樂場玩摩天輪，摩天輪上只能坐20個孩子。但是卻來了100個小孩。那么許可以的個數(shù)就是20。也就說一次只有20個小孩可以上摩天輪玩，其他的孩子必須排隊等待。只有等摩天輪上的孩子離開控制一個位置時，才能有其他小孩上去玩。
因此，使用許可控制線程行為和排隊玩摩天輪差不多就是一個意思了。
排他鎖和共享鎖
第二個重要的概念就是排他鎖(exclusive)和共享鎖(shared)。顧名思義，在排他模式上，只有一個線程可以訪問共享變量，而共享模式則允許多個線程同時訪問。簡單地說，重入鎖是排他的;信號量是共享的。
用摩天輪的話來說，排他鎖就是雖然我這里有20個位置，但是小朋友也只能一個一個上哦，多出來的位置怎么辦呢，可以空著，也可以讓摩天輪上唯一的小孩換著做，他想坐哪兒就坐哪兒，1分鐘換個位置，都沒有關(guān)系。而共享鎖，就是玩耍摩天輪正常的打開方式了。
LockSupport
LockSupport可以理解為一個工具類。它的作用很簡單，就是掛起和繼續(xù)執(zhí)行線程。它的常用的API如下：
- public static void park() : 如果沒有可用許可，則掛起當(dāng)前線程
- public static void unpark(Thread thread)：給thread一個可用的許可，讓它得以繼續(xù)執(zhí)行
因?yàn)閱卧~park的意思就是停車，因此這里park()函數(shù)就表示讓線程暫停。反之，unpark()則表示讓線程繼續(xù)執(zhí)行。
需要注意的是，LockSupport本身也是基于許可的實(shí)現(xiàn)，如何理解這句話呢，請看下面的代碼：
- LockSupport.unpark(Thread.currentThread());
- LockSupport.park();
大家可以猜一下，park()之后，當(dāng)前線程是停止，還是 可以繼續(xù)執(zhí)行呢?
答案是：可以繼續(xù)執(zhí)行。那是因?yàn)樵趐ark()之前，先執(zhí)行了unpark()，進(jìn)而釋放了一個許可，也就是說當(dāng)前線程有一個可用的許可。而park()在有可用許可的情況下，是不會阻塞線程的。
綜上所述，park()和unpark()的執(zhí)行效果和它調(diào)用的先后順序沒有關(guān)系。這一點(diǎn)相當(dāng)重要，因?yàn)樵谝粋€多線程的環(huán)境中，我們往往很難保證函數(shù)調(diào)用的先后順序(都在不同的線程中并發(fā)執(zhí)行)，因此，這種基于許可的做法能夠最大限度保證程序不出錯。
與park()和unpark()相比， 一個典型的反面教材就是Thread.resume()和Thread.suspend()。
看下面的代碼：
- Thread.currentThread().resume();
- Thread.currentThread().suspend();
首先讓線程繼續(xù)執(zhí)行，接著在掛起線程。這個寫法和上面的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)部，有一個隊列，我們把它叫做同步等待隊列。它的作用是保存等待在這個鎖上的線程(由于lock()操作引起的等待)。此外，為了維護(hù)等待在條件變量上的等待線程，AbstractQueuedSynchronizer又需要再維護(hù)一個條件變量等待隊列，也就是那些由Condition.await()引起阻塞的線程。
由于一個重入鎖可以生成多個條件變量對象，因此，一個重入鎖就可能有多個條件變量等待隊列。實(shí)際上，每個條件變量對象內(nèi)部都維護(hù)了一個等待列表。其邏輯結(jié)構(gòu)如下所示：
下面的類圖展示了代碼層面的具體實(shí)現(xiàn)：
可以看到，無論是同步等待隊列，還是條件變量等待隊列，都使用同一個Node類作為鏈表的節(jié)點(diǎn)。對于同步等待隊列，Node中包括鏈表的上一個元素prev，下一個元素next和線程對象thread。對于條件變量等待隊列，還使用nextWaiter表示下一個等待在條件變量隊列中的節(jié)點(diǎn)。
Node節(jié)點(diǎn)另外一個重要的成員是waitStatus，它表示節(jié)點(diǎn)等待在隊列中的狀態(tài)：
- CANCELLED：表示線程取消了等待。如果取得鎖的過程中發(fā)生了一些異常，則可能出現(xiàn)取消的情況，比如等待過程中出現(xiàn)了中斷異常或者出現(xiàn)了timeout。
- SIGNAL：表示后續(xù)節(jié)點(diǎn)需要被喚醒。
- CONDITION：線程等待在條件變量隊列中。
- PROPAGATE：在共享模式下，無條件傳播releaseShared狀態(tài)。早期的JDK并沒有這個狀態(tài)，咋看之下，這個狀態(tài)是多余的。引入這個狀態(tài)是為了解決共享鎖并發(fā)釋放引起線程掛起的bug 6801020。(隨著JDK的不斷完善，它的代碼也越來越難懂了 :(，就和我們自己的工程代碼一樣，bug修多了，細(xì)節(jié)就顯得越來越晦澀)
- 0：初始狀態(tài)
其中CANCELLED=1，SIGNAL=-1，CONDITION=-2，PROPAGATE=-3 。在具體的實(shí)現(xiàn)中，就可以簡單的通過waitStatus釋放小于等于0，來判斷是否是CANCELLED狀態(tài)。
排他鎖
了解了AbstractQueuedSynchronizer的基本實(shí)現(xiàn)思路和數(shù)據(jù)結(jié)構(gòu)，接下來一起看一下它的實(shí)現(xiàn)細(xì)節(jié)吧。首先，來看一下排他鎖的實(shí)現(xiàn)。重入鎖是一種 典型的排他鎖。
請求鎖
下面是排他鎖獲得請求許可的代碼：
- public final void acquire(int arg) {
- //嘗試獲得許可， arg為許可的個數(shù)。對于重入鎖來說，每次請求1個。
- if (!tryAcquire(arg) &&
- // 如果tryAcquire 失敗，則先使用addWaiter()將當(dāng)前線程加入同步等待隊列
- // 然后繼續(xù)嘗試獲得鎖
- acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
- selfInterrupt();
- }
進(jìn)入一步看一下tryAcquire()函數(shù)。該函數(shù)的作用是嘗試獲得一個許可。對于AbstractQueuedSynchronizer來說，這是一個未實(shí)現(xiàn)的抽象函數(shù)。
具體實(shí)現(xiàn)在子類中。在重入鎖，讀寫鎖，信號量等實(shí)現(xiàn)中， 都有各自的實(shí)現(xiàn)。
如果tryAcquire()成功，則acquire()直接返回成功。如果失敗，就用addWaiter()將當(dāng)前線程加入同步等待隊列。
接著， 對已經(jīng)在隊列中的線程請求鎖，使用acquireQueued()函數(shù)，從函數(shù)名字上可以看到，其參數(shù)node，必須是一個已經(jīng)在隊列中等待的節(jié)點(diǎn)。它的功能就是為已經(jīng)在隊列中的Node請求一個許可。
這個函數(shù)大家要好好看看，因?yàn)闊o論是普通的lock()方法，還是條件變量的await()都會使用這個方法。
條件變量等待
如果調(diào)用Condition.await()，那么線程也會進(jìn)入等待，下面來看實(shí)現(xiàn)：
Condition對象的signal()通知
signal()通知的時候，是在條件等待隊列中，按照FIFO進(jìn)行，首先從第一個節(jié)點(diǎn)下手：
release()釋放鎖
釋放排他鎖很簡單
- public final boolean release(int arg) {
- //tryRelease()是一個抽象方法，在子類中有具體實(shí)現(xiàn)和tryAcquire()一樣
- if (tryRelease(arg)) {
- Node h = head;
- if (h != null && h.waitStatus != 0)
- // 從隊列中喚醒一個等待中的線程（遇到CANCEL的直接跳過）
- unparkSuccessor(h);
- return true;
- }
- return false;
- }
共享鎖
與排他鎖相比，共享鎖的實(shí)現(xiàn)略微復(fù)雜一點(diǎn)。這也很好理解。因?yàn)榕潘i的場景很簡單，單進(jìn)單出，而共享鎖就不一樣了。可能是N進(jìn)M出，處理起來要麻煩一些。但是，他們的核心思想還是一致的。共享鎖的幾個典型應(yīng)用有：信號量，讀寫鎖中的寫鎖。
獲得共享鎖
為了實(shí)現(xiàn)共享鎖，在AbstractQueuedSynchronizer中，專門有一套針對共享鎖的方法。
獲得共享鎖使用acquireShared()方法：
釋放共享鎖
釋放共享鎖的代碼如下：
- public final boolean releaseShared(int arg) {
- //tryReleaseShared()嘗試釋放許可，這是一個抽象方法，需要在子類中實(shí)現(xiàn)
- if (tryReleaseShared(arg)) {
- //上述代碼中已經(jīng)出現(xiàn)這個函數(shù)了，就是喚醒線程，設(shè)置傳播狀態(tài)
- doReleaseShared();
- return true;
- }
- return false;
- }
寫在最后的話
AbstractQueuedSynchronizer 是一個比較復(fù)雜的實(shí)現(xiàn)，要完全理解其中的細(xì)節(jié)還需要慢慢琢磨。
這篇文章也只能起到一個拋磚引玉的作用，將AbstractQueuedSynchronizer的設(shè)計思想，核心數(shù)據(jù)結(jié)構(gòu)已經(jīng)核心實(shí)現(xiàn)代碼展示給大家。希望對大家理解AbstractQueuedSynchronizer的實(shí)現(xiàn)，以及理解重入鎖，信號量，讀寫鎖有一定幫助。
多線程系列還在在路上會繼續(xù)安排，我是敖丙，你知道的越多，你不知道的越多，我們下期再見。
