再談AbstractQueuedSynchronizer2：共享模式與基於Condition的等待/通知機制實現

共享模式acquire實現流程

上文咱們講解了AbstractQueuedSynchronizer獨佔模式的acquire實現流程，本文趁熱打鐵繼續看一下AbstractQueuedSynchronizer共享模式acquire的實現流程。連續兩篇文章的學習，也能夠對比獨佔模式acquire和共享模式acquire的區別，加深對於AbstractQueuedSynchronizer的理解。

先看一下共享模式acquire的實現，方法爲acquireShared和acquireSharedInterruptibly，二者差異不大，區別就在於後者有中斷處理，以acquireShared爲例：

 1 public final void acquireShared(int arg) {
 2     if (tryAcquireShared(arg) < 0)
 3         doAcquireShared(arg);
 4 }

這裏就能看出第一個差異來了：獨佔模式acquire的時候子類重寫的方法tryAcquire返回的是boolean，便是否tryAcquire成功；共享模式acquire的時候，返回的是一個int型變量，判斷是否<0。doAcquireShared方法的實現爲：

 1 private void doAcquireShared(int arg) {
 2     final Node node = addWaiter(Node.SHARED);
 3     boolean failed = true;
 4     try {
 5         boolean interrupted = false;
 6         for (;;) {
 7             final Node p = node.predecessor();
 8             if (p == head) {
 9                 int r = tryAcquireShared(arg);
10                 if (r >= 0) {
11                     setHeadAndPropagate(node, r);
12                     p.next = null; // help GC
13                     if (interrupted)
14                         selfInterrupt();
15                     failed = false;
16                     return;
17                 }
18             }
19             if (shouldParkAfterFailedAcquire(p, node) &&
20                 parkAndCheckInterrupt())
21                 interrupted = true;
22         }
23     } finally {
24         if (failed)
25             cancelAcquire(node);
26     }
27 }

咱們來分析一下這段代碼作了什麼：

1. addWaiter，把全部tryAcquireShared<0的線程實例化出一個Node，構建爲一個FIFO隊列，這和獨佔鎖是同樣的
2. 拿當前節點的前驅節點，只有前驅節點是head的節點才能tryAcquireShared，這和獨佔鎖也是同樣的
3. 前驅節點不是head的，執行"shouldParkAfterFailedAcquire() && parkAndCheckInterrupt()"，for(;;)循環，"shouldParkAfterFailedAcquire()"方法執行2次，當前線程阻塞，這和獨佔鎖也是同樣的

確實，共享模式下的acquire和獨佔模式下的acquire大部分邏輯差很少，最大的差異在於tryAcquireShared成功以後，獨佔模式的acquire是直接將當前節點設置爲head節點便可，共享模式會執行setHeadAndPropagate方法，顧名思義，即在設置head以後多執行了一步propagate操做。setHeadAndPropagate方法源碼爲：

 1 private void setHeadAndPropagate(Node node, int propagate) {
 2     Node h = head; // Record old head for check below
 3     setHead(node);
 4     /*
 5      * Try to signal next queued node if:
 6      *   Propagation was indicated by caller,
 7      *     or was recorded (as h.waitStatus) by a previous operation
 8      *     (note: this uses sign-check of waitStatus because
 9      *      PROPAGATE status may transition to SIGNAL.)
10      * and
11      *   The next node is waiting in shared mode,
12      *     or we don't know, because it appears null
13      *
14      * The conservatism in both of these checks may cause
15      * unnecessary wake-ups, but only when there are multiple
16      * racing acquires/releases, so most need signals now or soon
17      * anyway.
18      */
19     if (propagate > 0 || h == null || h.waitStatus < 0) {
20         Node s = node.next;
21         if (s == null || s.isShared())
22             doReleaseShared();
23     }
24 }

第3行的代碼設置重設head，第2行的代碼因爲第3行的代碼要重設head，所以先定義一個Node型變量h得到原head的地址，這兩行代碼很簡單。

第19行~第23行的代碼是獨佔鎖和共享鎖最不同的一個地方，咱們再看獨佔鎖acquireQueued的代碼：

 1 final boolean acquireQueued(final Node node, int arg) {
 2     boolean failed = true;
 3     try {
 4         boolean interrupted = false;
 5         for (;;) {
 6             final Node p = node.predecessor();
 7             if (p == head && tryAcquire(arg)) {
 8                 setHead(node);
 9                 p.next = null; // help GC
10                 failed = false;
11                 return interrupted;
12             }
13             if (shouldParkAfterFailedAcquire(p, node) &&
14                 parkAndCheckInterrupt())
15                 interrupted = true;
16         }
17     } finally {
18         if (failed)
19             cancelAcquire(node);
20     }
21 }

這意味着獨佔鎖某個節點被喚醒以後，它只須要將這個節點設置成head就完事了，而共享鎖不同，某個節點被設置爲head以後，若是它的後繼節點是SHARED狀態的，那麼將繼續經過doReleaseShared方法嘗試日後喚醒節點，實現了共享狀態的向後傳播。

 

共享模式release實現流程

上面講了共享模式下acquire是如何實現的，下面再看一下release的實現流程，方法爲releaseShared：

1 public final boolean releaseShared(int arg) {
2     if (tryReleaseShared(arg)) {
3         doReleaseShared();
4         return true;
5     }
6     return false;
7 }

tryReleaseShared方法是子類實現的，若是tryReleaseShared成功，那麼執行doReleaseShared()方法：

 1 private void doReleaseShared() {
 2     /*
 3      * Ensure that a release propagates, even if there are other
 4      * in-progress acquires/releases.  This proceeds in the usual
 5      * way of trying to unparkSuccessor of head if it needs
 6      * signal. But if it does not, status is set to PROPAGATE to
 7      * ensure that upon release, propagation continues.
 8      * Additionally, we must loop in case a new node is added
 9      * while we are doing this. Also, unlike other uses of
10      * unparkSuccessor, we need to know if CAS to reset status
11      * fails, if so rechecking.
12      */
13     for (;;) {
14         Node h = head;
15         if (h != null && h != tail) {
16             int ws = h.waitStatus;
17             if (ws == Node.SIGNAL) {
18                 if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
19                     continue;            // loop to recheck cases
20                 unparkSuccessor(h);
21             }
22             else if (ws == 0 &&
23                      !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
24                 continue;                // loop on failed CAS
25         }
26         if (h == head)                   // loop if head changed
27             break;
28     }
29 }

主要是兩層邏輯：

1. 頭結點自己的waitStatus是SIGNAL且能經過CAS算法將頭結點的waitStatus從SIGNAL設置爲0，喚醒頭結點的後繼節點
2. 頭結點自己的waitStatus是0的話，嘗試將其設置爲PROPAGATE狀態的，意味着共享狀態能夠向後傳播

 

Condition的await()方法實現原理----構建等待隊列

咱們知道，Condition是用於實現通知/等待機制的，和Object的wait()/notify()同樣，因爲本文以前描述AbstractQueuedSynchronizer的共享模式的篇幅不是很長，加之Condition也是AbstractQueuedSynchronizer的一部分，所以將Condition也放在這裏寫了。

Condition分爲await()和signal()兩部分，前者用於等待、後者用於喚醒，首先看一下await()是如何實現的。Condition自己是一個接口，其在AbstractQueuedSynchronizer中的實現爲ConditionObject：

1 public class ConditionObject implements Condition, java.io.Serializable {
2         private static final long serialVersionUID = 1173984872572414699L;
3         /** First node of condition queue. */
4         private transient Node firstWaiter;
5         /** Last node of condition queue. */
6         private transient Node lastWaiter;
7         
8         ...
9 }

這裏貼了一些字段定義，後面都是方法就不貼了，會對重點方法進行分析的。從字段定義咱們能夠看到，ConditionObject全局性地記錄了第一個等待的節點與最後一個等待的節點。

像ReentrantLock每次要使用ConditionObject，直接new一個ConditionObject出來便可。咱們關注一下await()方法的實現：

 1 public final void await() throws InterruptedException {
 2     if (Thread.interrupted())
 3         throw new InterruptedException();
 4     Node node = addConditionWaiter();
 5     int savedState = fullyRelease(node);
 6     int interruptMode = 0;
 7     while (!isOnSyncQueue(node)) {
 8         LockSupport.park(this);
 9         if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
10             break;
11     }
12     if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
13         interruptMode = REINTERRUPT;
14     if (node.nextWaiter != null) // clean up if cancelled
15         unlinkCancelledWaiters();
16     if (interruptMode != 0)
17         reportInterruptAfterWait(interruptMode);
18 }

第2行~第3行的代碼用於處理中斷，第4行代碼比較關鍵，添加Condition的等待者，看一下實現：

 1 private Node addConditionWaiter() {
 2     Node t = lastWaiter;
 3     // If lastWaiter is cancelled, clean out.
 4     if (t != null && t.waitStatus != Node.CONDITION) {
 5         unlinkCancelledWaiters();
 6         t = lastWaiter;
 7     }
 8     Node node = new Node(Thread.currentThread(), Node.CONDITION);
 9     if (t == null)
10         firstWaiter = node;
11     else
12         t.nextWaiter = node;
13     lastWaiter = node;
14     return node;
15 }

首先拿到隊列（注意數據結構，Condition構建出來的也是一個隊列）中最後一個等待者，緊接着第4行的的判斷，判斷最後一個等待者的waitStatus不是CONDITION的話，執行第5行的代碼，解綁取消的等待者，由於經過第8行的代碼，咱們看到，new出來的Node的狀態都是CONDITION的。

那麼unlinkCancelledWaiters作了什麼？裏面的流程就不看了，就是一些指針遍歷並判斷狀態的操做，總結一下就是：從頭至尾遍歷每個Node，遇到Node的waitStatus不是CONDITION的就從隊列中踢掉，該節點的先後節點相連。

接着第8行的代碼前面說過了，new出來了一個Node，存儲了當前線程，waitStatus是CONDITION，接着第9行~第13行的操做很好理解：

1. 若是lastWaiter是null，說明FIFO隊列中沒有任何Node，firstWaiter=Node
2. 若是lastWaiter不是null，說明FIFO隊列中有Node，原lastWaiter的next指向Node
3. 不管如何，新加入的Node編程lastWaiter，即新加入的Node必定是在最後面

用一張圖表示一下構建的數據結構就是：

對比學習，咱們總結一下Condition構建出來的隊列和AbstractQueuedSynchronizer構建出來的隊列的差異，主要體如今2點上：

1. AbstractQueuedSynchronizer構建出來的隊列，頭節點是一個沒有Thread的空節點，其標識做用，而Condition構建出來的隊列，頭節點就是真正等待的節點
2. AbstractQueuedSynchronizer構建出來的隊列，節點之間有next與pred相互標識該節點的前一個節點與後一個節點的地址，而Condition構建出來的隊列，只使用了nextWaiter標識下一個等待節點的地址

整個過程當中，咱們看到沒有使用任何CAS操做，firstWaiter和lastWaiter也沒有用volatile修飾，其實緣由很簡單：要await()必然要先lock()，既然lock()了就表示沒有競爭，沒有競爭天然也不必使用volatile+CAS的機制去保證什麼。

 

Condition的await()方法實現原理----線程等待

前面咱們看了Condition構建等待隊列的過程，接下來咱們看一下等待的過程，await()方法的代碼比較短，再貼一下：

 1 public final void await() throws InterruptedException {
 2     if (Thread.interrupted())
 3         throw new InterruptedException();
 4     Node node = addConditionWaiter();
 5     int savedState = fullyRelease(node);
 6     int interruptMode = 0;
 7     while (!isOnSyncQueue(node)) {
 8         LockSupport.park(this);
 9         if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
10             break;
11     }
12     if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
13         interruptMode = REINTERRUPT;
14     if (node.nextWaiter != null) // clean up if cancelled
15         unlinkCancelledWaiters();
16     if (interruptMode != 0)
17         reportInterruptAfterWait(interruptMode);
18 }

構建完畢隊列以後，執行第5行的fullyRelease方法，顧名思義：fullyRelease方法的做用是徹底釋放Node的狀態。方法實現爲：

 1 final int fullyRelease(Node node) {
 2     boolean failed = true;
 3     try {
 4         int savedState = getState();
 5         if (release(savedState)) {
 6             failed = false;
 7             return savedState;
 8         } else {
 9             throw new IllegalMonitorStateException();
10         }
11     } finally {
12         if (failed)
13             node.waitStatus = Node.CANCELLED;
14     }
15 }

這裏第4行獲取state，第5行release的時候將整個state傳過去，理由是某線程可能屢次調用了lock()方法，好比調用了10次lock，那麼此線程就將state加到了10，因此這裏要將10傳過去，將狀態所有釋放，這樣後面的線程才能從新從state=0開始競爭鎖，這也是方法被命名爲fullyRelease的緣由，由於要徹底釋放鎖，釋放鎖以後，若是有競爭鎖的線程，那麼就喚醒第一個，這都是release方法的邏輯了，前面的文章詳細講解過。

接着看await()方法的第7行判斷"while(!isOnSyncQueue(node))"：

 1 final boolean isOnSyncQueue(Node node) {
 2     if (node.waitStatus == Node.CONDITION || node.prev == null)
 3         return false;
 4     if (node.next != null) // If has successor, it must be on queue
 5         return true;
 6     /*
 7      * node.prev can be non-null, but not yet on queue because
 8      * the CAS to place it on queue can fail. So we have to
 9      * traverse from tail to make sure it actually made it.  It
10      * will always be near the tail in calls to this method, and
11      * unless the CAS failed (which is unlikely), it will be
12      * there, so we hardly ever traverse much.
13      */
14     return findNodeFromTail(node);
15 }

注意這裏的判斷是Node是否在AbstractQueuedSynchronizer構建的隊列中而不是Node是否在Condition構建的隊列中，若是Node不在AbstractQueuedSynchronizer構建的隊列中，那麼調用LockSupport的park方法阻塞。

至此調用await()方法的線程構建Condition等待隊列--釋放鎖--等待的過程已經所有分析完畢。

 

Condition的signal()實現原理

上面的代碼分析了構建Condition等待隊列--釋放鎖--等待的過程，接着看一下signal()方法通知是如何實現的：

1 public final void signal() {
2     if (!isHeldExclusively())
3         throw new IllegalMonitorStateException();
4     Node first = firstWaiter;
5     if (first != null)
6         doSignal(first);
7 }

首先從第2行的代碼咱們看到，要能signal()，當前線程必須持有獨佔鎖，不然拋出異常IllegalMonitorStateException。

那麼真正操做的時候，獲取第一個waiter，若是有waiter，調用doSignal方法：

1 private void doSignal(Node first) {
2     do {
3         if ( (firstWaiter = first.nextWaiter) == null)
4             lastWaiter = null;
5         first.nextWaiter = null;
6     } while (!transferForSignal(first) &&
7              (first = firstWaiter) != null);
8 }

第3行~第5行的代碼很好理解：

1. 從新設置firstWaiter，指向第一個waiter的nextWaiter
2. 若是第一個waiter的nextWaiter爲null，說明當前隊列中只有一個waiter，lastWaiter置空
3. 由於firstWaiter是要被signal的，所以它沒什麼用了，nextWaiter置空

接着執行第6行和第7行的代碼，這裏重點就是第6行的transferForSignal方法：

 1 final boolean transferForSignal(Node node) {
 2     /*
 3      * If cannot change waitStatus, the node has been cancelled.
 4      */
 5     if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
 6         return false;
 7 
 8     /*
 9      * Splice onto queue and try to set waitStatus of predecessor to
10      * indicate that thread is (probably) waiting. If cancelled or
11      * attempt to set waitStatus fails, wake up to resync (in which
12      * case the waitStatus can be transiently and harmlessly wrong).
13      */
14     Node p = enq(node);
15     int ws = p.waitStatus;
16     if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
17         LockSupport.unpark(node.thread);
18     return true;
19 }

方法本意是將一個節點從Condition隊列轉換爲AbstractQueuedSynchronizer隊列，總結一下方法的實現：

1. 嘗試將Node的waitStatus從CONDITION置爲0，這一步失敗直接返回false
2. 當前節點進入調用enq方法進入AbstractQueuedSynchronizer隊列
3. 當前節點經過CAS機制將waitStatus置爲SIGNAL

最後上面的步驟所有成功，返回true，返回true喚醒等待節點成功。從喚醒的代碼咱們能夠得出一個重要結論：某個await()的節點被喚醒以後並不意味着它後面的代碼會當即執行，它會被加入到AbstractQueuedSynchronizer隊列的尾部，只有前面等待的節點獲取鎖所有完畢才能輪到它。

代碼分析到這裏，我想相似的signalAll方法也沒有必要再分析了，顯然signalAll方法的做用就是將全部Condition隊列中等待的節點逐一隊列中從移除，由CONDITION狀態變爲SIGNAL狀態並加入AbstractQueuedSynchronizer隊列的尾部。

 

代碼示例

可能你們看了我分析半天代碼會有點迷糊，這裏最後我貼一段我用於驗證上面Condition結論的示例代碼，首先創建一個Thread，我將之命名爲ConditionThread：

 1 /**
 2  * @author 五月的倉頡http://www.cnblogs.com/xrq730/p/7067904.html
 3  */
 4 public class ConditionThread implements Runnable {
 5 
 6     private Lock lock;
 7     
 8     private Condition condition;
 9     
10     public ConditionThread(Lock lock, Condition condition) {
11         this.lock = lock;
12         this.condition = condition;
13     }
14     
15     @Override
16     public void run() {
17         
18         if ("線程0".equals(JdkUtil.getThreadName())) {
19             thread0Process();
20         } else if ("線程1".equals(JdkUtil.getThreadName())) {
21             thread1Process();
22         } else if ("線程2".equals(JdkUtil.getThreadName())) {
23             thread2Process();
24         }
25         
26     }
27     
28     private void thread0Process() {
29         try {
30             lock.lock();
31             System.out.println("線程0休息5秒");
32             JdkUtil.sleep(5000);
33             condition.signal();
34             System.out.println("線程0喚醒等待線程");
35         } finally {
36             lock.unlock();
37         }
38     }
39     
40     private void thread1Process() {
41         try {
42             lock.lock();
43             System.out.println("線程1阻塞");
44             condition.await();
45             System.out.println("線程1被喚醒");
46         } catch (InterruptedException e) {
47             
48         } finally {
49             lock.unlock();
50         }
51     }
52     
53     private void thread2Process() {
54         try {
55             System.out.println("線程2想要獲取鎖");
56             lock.lock();
57             System.out.println("線程2獲取鎖成功");
58         } finally {
59             lock.unlock();
60         }
61     }
62     
63 }

這個類裏面的方法就不解釋了，反正就三個方法片斷，根據線程名判斷，每一個線層執行的是其中的一個代碼片斷。寫一段測試代碼：

 1 /**
 2  * @author 五月的倉頡http://www.cnblogs.com/xrq730/p/7067904.html
 3  */
 4 @Test
 5 public void testCondition() throws Exception {
 6     Lock lock = new ReentrantLock();
 7     Condition condition = lock.newCondition();
 8         
 9     // 線程0的做用是signal
10     Runnable runnable0 = new ConditionThread(lock, condition);
11     Thread thread0 = new Thread(runnable0);
12     thread0.setName("線程0");
13     // 線程1的做用是await
14     Runnable runnable1 = new ConditionThread(lock, condition);
15     Thread thread1 = new Thread(runnable1);
16     thread1.setName("線程1");
17     // 線程2的做用是lock
18     Runnable runnable2 = new ConditionThread(lock, condition);
19     Thread thread2 = new Thread(runnable2);
20     thread2.setName("線程2");
21         
22     thread1.start();
23     Thread.sleep(1000);
24     thread0.start();
25     Thread.sleep(1000);
26     thread2.start();
27         
28     thread1.join();
29 }

測試代碼的意思是：

1. 線程1先啓動，獲取鎖，調用await()方法等待
2. 線程0後啓動，獲取鎖，休眠5秒準備signal()
3. 線程2最後啓動，獲取鎖，因爲線程0未使用完畢鎖，所以線程2排隊，能夠此時因爲線程0還未signal()，所以線程1在線程0執行signal()後，在AbstractQueuedSynchronizer隊列中的順序是在線程2後面的

代碼執行結果爲：

 1 線程1阻塞
 2 線程0休息5秒
 3 線程2想要獲取鎖
 4 線程0喚醒等待線程
 5 線程2獲取鎖成功
 6 線程1被喚醒

符合咱們的結論：signal()並不意味着被喚醒的線程當即執行。因爲線程2先於線程0排隊，所以看到第5行打印的內容，線程2先獲取鎖。