本文首發在infoQ? ? 作者：劉錕洋
前言 經過本系列的上半部分JDK1.8 AbstractQueuedSynchronizer的實現分析（上）的解讀，相信很多讀者已經對AbstractQueuedSynchronizer(下文簡稱AQS)的獨占功能了然于胸，那么，這次我們再借助另一個工具類：CoutDownLatch，換個角度看看AQS的另外一個重要功能——共享功能的實現。
?
?AQS共享功能的實現 ? ? ?在開始解讀AQS的共享功能前，我們再重溫一下CountDownLatch，CountDownLatch為 java.util.concurrent包下的計數器工具類，常被用在多線程環境下，它在初始時需要指定一個計數器的大小，然后可被多個線程并發的實現 減1操作，并在計數器為0后調用await方法的線程被喚醒，從而實現多線程間的協作。它在多線程環境下的基本使用方式為：
//main thread
? ? ?注意，線程thread 1,2,3各自調用?countDown后，countDownLatch?的計數為0，await方法返回，控制臺輸入“over”,在此之前main thread 會一直沉睡。 ? ? ? 可以看到CountDownLatch的作用類似于一個“欄柵”，在CountDownLatch的計數為0前，調用await方法的線程將一直阻塞，直到CountDownLatch計數為0，await方法才會返回， ? ? ?而CountDownLatch的countDown()方法則一般由各個線程調用，實現CountDownLatch計數的減1。 ? ? ? 知道了CountDownLatch的基本使用方式，我們就從上述DEMO的第一行new?CountDownLatch（3）開始，看看CountDownLatch是怎么實現的。 ? ?? ? ? ?首先，看下CountDownLatch的構造方法： ? ? ?和ReentrantLock類似，CountDownLatch內部也有一個叫做Sync的內部類，同樣也是用它繼承了AQS。 ? ? ?再看下Sync： ? ? ? ? ? ?如果你看過本系列的上半部分，你對setState方法一定不會陌生，它是AQS的一個“狀態位”，在不同的場景下，代表不同的含義，比如在ReentrantLock中，表示加鎖的次數，在CountDownLatch中， ? ? 則表示CountDownLatch的計數器的初始大小。 ? ? 設置完計數器大小后CountDownLatch的構造方法返回，下面我們再看下CountDownLatch的await()方法： ? ?? ? ? 調用了Sync的acquireSharedInterruptibly方法，因為Sync是AQS子類的原因，這里其實是直接調用了AQS的acquireSharedInterruptibly方法： ? ? ? ? ? ? ? ? 從方法名上看，這個方法的調用是響應線程的打斷的，所以在前兩行會檢查下線程是否被打斷。接著，嘗試著獲取共享鎖，小于0，表示獲取失敗，通過本系列的上半部分的解讀， ? ?我們知道AQS在獲取鎖的思路是，先嘗試直接獲取鎖，如果失敗會將當前線程放在隊列中，按照FIFO的原則等待鎖。 ? ? 而對于共享鎖也是這個思路，如果和獨占鎖一致，這里的tryAcquireShared應該是個空方法，留給子類去判斷: ? ? ? ? ? 再看看CountDownLatch： ? ? ? ? ? ?如果state變成0了，則返回1，表示獲取成功，否則返回-1則表示獲取失敗。 ? ? ?看到這里，讀者可能會發現，?await方法的獲取方式更像是在獲取一個獨占鎖，那為什么這里還會用tryAcquireShared呢？ ? ? ?回想下CountDownLatch的await方法是不是只能在主線程中調用？答案是否定的，CountDownLatch的await方法可以在多個線程中調用，當CountDownLatch的計數器為0后，調用await的方法都會依次返回。 ? ? ?也就是說可以多個線程同時在等待await方法返回，所以它被設計成了實現tryAcquireShared方法，獲取的是一個共享鎖，鎖在所有調用await方法的線程間共享，所以叫共享鎖。 ? ? ? 回到acquireSharedInterruptibly方法： ? ?? ? ?如果獲取共享鎖失敗（返回了-1，說明state不為0，也就是CountDownLatch的計數器還不為0），進入調用doAcquireSharedInterruptibly方法中，按照我們上述的猜想，應該是要將當前線程放入到隊列中去。 ? 在這之前，我們再回顧一下AQS隊列的數據結構：AQS是一個雙向鏈表，通過節點中的next，pre變量分別指向當前節點后一個節點和前一個節點。其 中，每個節點中都包含了一個線程和一個類型變量：表示當前節點是獨占節點還是共享節點，頭節點中的線程為正在占有鎖的線程，而后的所有節點的線程表示為正 在等待獲取鎖的線程。如下圖所示： ? ? 黃色節點，表示正在獲取鎖的節點，剩下的藍色節點（Node1、Node2、Node3）為正在等待鎖的節點，他們通過各自的next,pre變量分別指向前后節點，形成了AQS中的雙向鏈表。? ? ? 再看看doAcquireSharedInterruptibly方法： 01 private void doAcquireSharedInterruptibly(int arg)
02 ?????throws InterruptedException {
03 ?????final Node node = addWaiter(Node.SHARED); //將當前線程包裝為類型為Node.SHARED的節點，標示這是一個共享節點。
04 ?????boolean failed = true;
07 ?????????????final Node p = node.predecessor();
08 ?????????????if (p == head) {//如果新建節點的前一個節點，就是Head，說明當前節點是AQS隊列中等待獲取鎖的第一個節點，按照FIFO的原則，可以直接嘗試獲取鎖。
09 ?????????????????int r = tryAcquireShared(arg);
10 ?????????????????if (r >= 0) {
11 ?????????????????????setHeadAndPropagate(node, r); //獲取成功，需要將當前節點設置為AQS隊列中的第一個節點，這是AQS的規則，隊列的頭節點表示正在獲取鎖的節點
12 ?????????????????????p.next = null; // help GC
13 ?????????????????????failed = false;
14 ?????????????????????return;
17 ?????????????if (shouldParkAfterFailedAcquire(p, node) && //檢查下是否需要將當前節點掛起
18 ?????????????????parkAndCheckInterrupt())
19 ?????????????????throw new InterruptedException();
23 ?????????????cancelAcquire(node);
這里有幾點需要說明的： ?1.?setHeadAndPropagate方法： ? ? ? ? 首先，使用了CAS更換了頭節點，然后，將當前節點的下一個節點取出來，如果同樣是“shared”類型的，再做一個”releaseShared”操作。看下doReleaseShared方法：
03 ?????if (h != null && h != tail) {
04 ?????????int ws = h.waitStatus;
05 ?????????if (ws == Node.SIGNAL) {
06 ?????????????if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0)) //如果當前節點是SIGNAL意味著，它正在等待一個信號，
07 ???????????????????????????????????????????????????????????????????????????????????????//或者說，它在等待被喚醒，因此做兩件事，
08 ???????????????????????????????????????????????????????????????????????????????????????//1是重置waitStatus標志位，2是重置成功后,喚醒下一個節點。
09 ?????????????????continue;??????????? // loop to recheck cases
10 ?????????????unparkSuccessor(h);
12 ?????????else if (ws == 0 &&
13 ??????????????????!compareAndSetWaitStatus(h, 0, Node.PROPAGATE))? //如果本身頭結點的waitStatus是出于重置狀態（waitStatus==0）的，將其設置為“傳播”狀態。意味著需要將狀態向后一個節點傳播。
14 ?????????????continue;??????????????? // loop on failed CAS
16 ?????if (h == head)?????????????????? // loop if head changed
? ? 為什么要這么做呢？這就是共享功能和獨占功能最不一樣的地方，對于獨占功能來說，有且只有一個線程（通常只對應一個節點，拿ReentantLock舉例，如果當前持有鎖的線程重復調用lock()方法， 那根據本系列上半部分我們的介紹，我們知道，會被包裝成多個節點在AQS的隊列中，所以用一個線程來描述更準確），能夠獲取鎖，但是對于共享功能來說。 共享的狀態是可以被共享的，也就是意味著其他AQS隊列中的其他節點也應能第一時間知道狀態的變化。因此，一個節點獲取到共享狀態流程圖是這樣的： ? ? ?比如現在有如下隊列： ? ? ?當Node1調用tryAcquireShared成功后，更換了頭節點： ? ? ? ? ?Node1變成了頭節點然后調用unparkSuccessor()方法喚醒了Node2,Node2中持有的線程A出于上面流程圖的park node的位置，
? ? ?線程A被喚醒后，重復黃色線條的流程，重新檢查調用tryAcquireShared方法，看能否成功，如果成功，則又更改頭結點，重復以上步驟，以實現節點自身獲取共享鎖成功后，喚醒下一個共享類型結點的操作，實現共享狀態的向后傳遞。
?2.其實對于doAcquireShared方法，AQS還提供了集中類似的實現：
? ? ?分別對應了：
?1. 帶參數請求共享鎖。 （忽略中斷）
?2.?帶參數請求共享鎖，且響應中斷。（每次循環時，會檢查當前線程的中斷狀態，以實現對線程中斷的響應）
?3.?帶參數請求共享鎖但是限制等待時間。（第二個參數設置超時時間，超出時間后，方法返回。）
比較特別的為最后一個doAcquireSharedNanos方法，我們一起看下它怎么實現超時時間的控制的。
因為該方法和其余獲取共享鎖的方法邏輯是類似的，我用紅色框圈出了它所不一樣的地方，也就是實現超時時間控制的地方。
可以看到，其實就是在進入方法時，計算出了一個“deadline”，每次循環的時候用當前時間和“deadline”比較，大于“dealine”說明超時時間已到，直接返回方法。
注意，最后一個紅框中的這行代碼：
? ? nanosTimeout > spinForTimeoutThreshold
從變量的字面意思可知，這是拿超時時間和超時自旋的最小閥值作比較，在這里Doug Lea把超時自旋的閥值設置成了1000ns,即只有超時時間大于1000ns才會去掛起線程，否則，再次循環，以實現“自旋”操作。這是“自旋”在AQS中的應用之處。
?
看完await方法，我們再來看下countDown()方法：
調用了AQS的releaseShared方法,并傳入了參數1: 同樣先嘗試去釋放鎖，tryReleaseShared同樣為空方法，留給子類自己去實現，以下是CountDownLatch的內部類Sync的實現： 死循環更新state的值，實現state的減1操作，之所以用死循環是為了確保state值的更新成功。
從上文的分析中可知，如果state的值為0，在CountDownLatch中意味：所有的子線程已經執行完畢，這個時候可以喚醒調用await()方法的線程了，而這些線程正在AQS的隊列中，并被掛起的，
所以下一步應該去喚醒AQS隊列中的頭結點了（AQS的隊列為FIFO隊列），然后由頭節點去依次喚醒AQS隊列中的其他共享節點。如果tryReleaseShared返回true,進入doReleaseShared()方法：
??? private void doReleaseShared() {
? 當線程被喚醒后，會重新嘗試獲取共享鎖，而對于CountDownLatch線程獲取共享鎖判斷依據是state是否為0，而這個時候顯然state已經變成了0，因此可以順利獲取共享鎖并且依次喚醒AQS隊里中后面的節點及對應的線程。 ? 總結 ? ? ?本文從CountDownLatch入手，深入分析了AQS關于共享鎖方面的實現方式： ? ? ?如果獲取共享鎖失敗后，將請求共享鎖的線程封裝成Node對象放入AQS的隊列中，并掛起Node對象對應的線程，實現請求鎖線程的等待操作。待共享鎖 可以被獲取后，從頭節點開始，依次喚醒頭節點及其以后的所有共享類型的節點。實現共享狀態的傳播。這里有幾點值得注意：
以上的分析都是從AQS子類的角度去看待AQS的部分功能的，而如果直接看待AQS，或許可以這么去解讀：
轉載于:https://www.cnblogs.com/voodgen/p/5655593.html
總結
以上是生活随笔 為你收集整理的深度解析Java8 – AbstractQueuedSynchronizer的实现分析（下） 的全部內容，希望文章能夠幫你解決所遇到的問題。
如果覺得生活随笔 網站內容還不錯，歡迎將生活随笔 推薦給好友。
