引言
這個系列文章打算用圖解的方式記錄了自己閱讀concurrent包的中一些類的大概流程，加深印象。
JDK版本
我這里依據的JDK版本如下：
java version "1.8.0_73"
Java(TM) SE Runtime Environment (build 1.8.0_73-b02)
Java HotSpot(TM) 64-Bit Server VM (build 25.73-b02, mixed mode)
如果你的版本和我不同，看到的源碼可能有細微的不同。
什么是AbstractQueuedSynchronizer
concurrent包下的很多類都有一個叫做Sync的內部類（比如ReentrantLock，ThreadPoolExecutor等），并且很多功能會委托給這個內部類，而這個內部類實現了AbstractQueuedSynchronizer（下面簡稱AQS）。
AQS的功能
按照官方文檔的說法，通過AQS可以很方便的實現一個自定義的同步器，子類只需要通過重寫以下方法來控制AQS內部的一個叫做state的同步變量：
//獨占模式獲取鎖與釋放鎖
//返回值表示獲取鎖是否成功
protected boolean tryAcquire(int arg)
//返回值表示釋放鎖是否成功
protected boolean tryRelease(int arg)
//共享模式獲取鎖與釋放鎖
//返回值表示獲得鎖后還剩余的許可數量
protected int tryAcquireShared(int arg)
//返回值表示釋放鎖是否成功
protected boolean tryReleaseShared(int arg)
獨占模式與共享模式的含義是：
- 獨占模式：資源是互斥的，一次只能一個線程獲取鎖
- 共享模式：資源一次可以由n個線程同時使用（n有限）
在重寫這些方法時，如果想要使用state同步變量，必須使用AQS內部提供的以下方法來控制：
protected final int getState()
protected final void setState(int newState)
protected final boolean compareAndSetState(int expect, int update)
一個AQS的使用示例如下（這里用AQS實現一個簡單的不可重入鎖）：
public class SimpleLock extends AbstractQueuedSynchronizer {
@Override
protected boolean tryAcquire(int unused) {
//使用compareAndSetState控制AQS中的同步變量
if (compareAndSetState(0, 1)) {
setExclusiveOwnerThread(Thread.currentThread());
return true;
}
return false;
}
@Override
protected boolean tryRelease(int unused) {
setExclusiveOwnerThread(null);
//使用setState控制AQS中的同步變量
setState(0);
return true;
}
public void lock() { acquire(1); }
public boolean tryLock() { return tryAcquire(1); }
public void unlock() { release(1); }
public boolean isLocked() { return isHeldExclusively(); }
/**
*發現線程是順序獲得鎖的
* 因為AQS是基于CLH鎖的一個變種實現的FIFO調度
*/
public static void main(String[] args) throws InterruptedException {
final SimpleLock lock = new SimpleLock();
lock.lock();
for (int i = 0; i < 10; i++) {
new Thread(new Runnable() {
@Override
public void run() {
lock.lock();
System.out.println(Thread.currentThread().getId() + " acquired the lock!");
lock.unlock();
}
}).start();
// 簡單的讓線程按照for循環的順序阻塞在lock上
//目的是讓線程順序啟動
Thread.sleep(100);
}
System.out.println("main thread unlock!");
lock.unlock();
}
其實這個基本上就是ThreadPoolExecutor的內部類Worker對AQS的實現，后面的文章我再說。
CLH鎖
AQS的原理是CLH鎖的一個變種，具體怎么變種的后文再說，這里先說一下什么是CLH鎖。
講之前先推薦一本書--《The Art of Multiprocessor Programming
》，這本書對并發的概念和各種鎖的設計思想介紹得特別清楚，目前沒發現中文版，文末的參考文獻我附了一個英文版的下載鏈接。書的7.5.2節介紹了CLH鎖的設計思想，我這里就從書中摘抄一下只言片語簡要介紹。
CLH鎖其實是自旋鎖的一種改良，與一般的自旋鎖不同，一般的自旋鎖會將并發所有的競爭集中在一個標志位里，而CLH鎖將競爭資源的線程排成一個隊列，每個線程只在前一個線程的標志位上進行自旋，當頭節點釋放鎖時，將自己的標志位置為false，這樣后繼線程在自旋時發現標志位變為false后，便能獲得鎖進入臨界區。
CLH隊列大概看起來像下面這樣：
CLH鎖的這種設計思想叫做Local Spin，它能夠最大化地減少CPU緩存的失效次數。現在的多核CPU一般每一個物理核都會有自己的緩存，假如是普通的自旋鎖，所有CPU核都自旋在一個標志位上，因為這個標志位競爭非常激烈，所以標志位經常會變化，每當標志位變化時，所有CPU的緩存就會失效，這樣顯然無法最大程度上利用CPU的緩存，而在CLH鎖的設計中，每個線程只需要在自己的前繼的標志位上自旋即可，而前繼的標志位僅僅在前繼釋放鎖的時候會發生變化，這樣每個CPU核就可以一直在自己的本地緩存上自旋（所以稱之為Local Spin）而不會出現頻繁的緩存失效，減少了緩存失效，鎖算法效率自然就提高了。
一個最標準的CLH鎖的實現如下：
public class CLHLock implements Lock {
AtomicReference<QNode> tail = new AtomicReference<QNode>(new QNode());
ThreadLocal<QNode> myPred;//代表前繼的節點
ThreadLocal<QNode> myNode;//代表當前線程的節點
public CLHLock() {
tail = new AtomicReference<QNode>(new QNode());
myNode = new ThreadLocal<QNode>() {
protected QNode initialValue() {
return new QNode();
}
};
myPred = new ThreadLocal<QNode>() {
protected QNode initialValue() {
return null;
}
};
}
public void lock() {
QNode qnode = myNode.get();
qnode.locked = true;
QNode pred = tail.getAndSet(qnode);
myPred.set(pred);
//在前繼節點的標志位上自旋
while (pred.locked) {}
}
public void unlock() {
QNode qnode = myNode.get();
//將當前線程節點的標志位置為false
qnode.locked = false;
//此時代表前繼節點的QNode對象已經沒有用了,這里將其復用
myNode.set(myPred.get());
}
}
CLH鎖在大多數情況下表現都很優異，書中只給了一處例外，就是CLH鎖不適合用在NUMA體系結構的計算機上，在NUMA體系結構的計算機上則應該使用另外一種同樣是基于隊列的鎖方法--MCS鎖，具體什么是MCS鎖這里就不展開說，有興趣的可以去看我推薦的那本書的7.5.3節。
至于什么是NUMA體系結構的計算機，可以看一看這篇文章http://www.cnblogs.com/yubo/archive/2010/04/23/1718810.html
因為與AQS無關，我這里就不再多說了。
AQS原理概覽
在真正開始閱讀源碼之前，我先用簡要地說明一下AQS的原理。
AQS維護著兩個隊列，一個是由AQS類維護的CLH隊列（用于運行CLH算法），另一個是由AQS的內部類ConditionObject維護的Condition隊列（用于支持線程間的同步，提供await,signal,signalAll方法）。
AQS中維護的CLH隊列看起來大概像這樣：
具體運作看接下來的源碼詳解。
AQS源碼圖解
有了CLH鎖相關的知識后，就可以來看一看AQS到底是怎么應用這一優秀的鎖算法的了。
Node內部類
前面說過，CLH鎖是基于隊列的，隊列中每個節點對應著一個等待資源的線程，在AQS中這個節點對用這一個叫做Node的內部類來表示，我列舉一下它比較中要的幾個字段：
- waitStatus: 等待狀態，有以下幾種取值
//代表線程已經被取消
static final int CANCELLED = 1;
//代表后續節點需要喚醒
static final int SIGNAL = -1;
//代表線程在condition queue中，等待某一條件
static final int CONDITION = -2;
//代表后續結點會傳播喚醒的操作，共享模式下起作用
static final int PROPAGATE = -3;
- prev: CLH隊列的前繼
- next: CLH隊列的后繼
- nextWaiter: Condition隊列的后繼
- thread: 這個節點所代表的線程
從這幾個字段可以看出，AQS中維護著兩個隊列（兩個隊列都是由Node組成），一個隊列就是CLH鎖算法中的那個隊列（我將其稱之為CLH隊列），另一個是Condition隊列（下文再講Condition隊列是用來做什么的）。
acquire方法
acquire方法是在獨占模式下用于獲取鎖的，它的主體邏輯我梳理了一下，如下（只梳理了主題邏輯，所以代碼中一些我認為不重要的細節就忽略了）：
圖中紅色的節點代表開始和終止的節點，圖中節點編號對應代碼如下。
①
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
這個節點對應著acquireQueued方法的第一個參數中對addWaiter的調用。
addWaiter方法會為當前線程建立一個Node節點，并將節點加入CLH隊列后返回。
從上面這段代碼我們也可以看出，在開始真正的CLH算法（即acquireQueued方法）之前，會先嘗試一下獲得鎖（即由子類重寫的tryAcquire方法），這樣在競爭較小的情況下能夠提升程序的性能。
②
①結束之后，剩下的部分便全部在acquireQueued方法中進行，這個方法的代碼如下：
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return interrupted;
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
重點在這個for循環
對應著②的是for循環的前兩句：
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
如果發現了自己的前繼已經是頭節點了的話，則說明此時有獲得鎖的可能，就會調用tryAcquire進行嘗試。
③
③是for循環的終結狀態，當前面的tryAcquire獲取鎖成功時會執行如下代碼（863~868行）：
//這里p是前繼節點
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return interrupted;
}
可以看到這里把自己對應的Node設置成了頭結點，拋棄掉了原本的頭節點（即前繼出隊）。
④
當嘗試獲取鎖失敗時，當前線程就要考慮一下是否要將自己阻塞了，這個邏輯位于shouldParkAfterFailedAcquire方法中，代碼如下：
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus;
if (ws == Node.SIGNAL)
return true;
if (ws > 0) {
do {
node.prev = pred = pred.prev;
//waitStatus大于0的情況只有CANNCELLED
} while (pred.waitStatus > 0);
pred.next = node;
} else {
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
④就對應這個該方法的第二行，判斷前繼的waitStatus是SIGNAL（說明前繼已經準備好喚醒后繼節點）。
⑦
這里先將⑦，從⑥中的代碼可以看出，如果前繼的waitStatus是SIGNAL，則shouldParkAfterFailedAcquire直接放回true，然后參考一下上層的acquireQueued方法：
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
發現shouldParkAfterFailedAcquire返回true的話就會執行parkAndCheckInterrupt方法，parkAndCheckInterrupt方法的內容如下：
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
return Thread.interrupted();
}
發現AQS其實是調用concurrent包下的LockSupport來阻塞線程的。
⑥
如果發現前繼被CANCELLED了，則會跳過前繼，一直找到第一個沒有被CANCELLED的節點作為自己的前繼，代碼如下(shouldParkAfterFailedAcquire方法的第二個if判斷)：
if (ws > 0) {
do {
node.prev = pred = pred.prev;
//waitStatus大于0的情況只有CANNCELLED
} while (pred.waitStatus > 0);
pred.next = node;
}
⑤
上面的if語句對應else就是⑤的代碼：
} else {
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
當前繼節點的waitStatus為0, PROPAGATE或者CONDITION時（其實這里不可能為CONDITION，這個是留在Condition隊列中使用的waitStatus，acquire方法不會涉及Condition隊列），則將前繼節點的waitStatus設置為SIGNAL。
總體流程
從我畫得流程圖中可以看出，acquire方法在幾次嘗試獲得鎖失敗后成功地將前繼線程的waitStatus設置為SIGNAL，然后阻塞自己。之后在某個時刻會被前繼線程喚醒，然后有經過幾次爭搶后可能會成功地獲得鎖。
release方法
相比上面的acquire方法，release方法可以說是非常的簡單，它做的就是如果tryRelease成功，就將頭結點的下一個節點對應的線程喚醒：
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;
}
unparkSuccessor方法會將h節點的后繼喚醒，點開這個方法會發現更多細節，比如，如果發現h的后繼節點為null或者狀態是CANCELLED時，會找出離tail最遠（或者說離h節點最近）的一個非CANCELLED節點喚醒，代碼如下：
private void unparkSuccessor(Node node) {
int ws = node.waitStatus;
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);
Node s = node.next;
/*
如果發現node的后繼節點為null或者狀態是CANCELLED時，
會找出離tail最遠（或者說離node節點最近）的一個非CANCELLED節點喚醒
*/
if (s == null || s.waitStatus > 0) {
s = null;
for (Node t = tail; t != null && t != node; t = t.prev)
if (t.waitStatus <= 0)
s = t;
}
if (s != null)
LockSupport.unpark(s.thread);
}
可以看出這里也是依靠LockSupport來喚醒線程的。
后繼線程被喚醒之后就會從前面我畫的acquire方法的流程圖中的節點⑦開始不斷地嘗試獲得鎖，直到成功。
AQS中對CLH算法的實現與標準的CLH算法有什么異同？
到這里已經可以解答這個問題了。AQS到底在哪些地方"變種"CLH鎖算法？
- CLH是一種自旋鎖算法（在得到鎖之前會不停地自旋），而AQS會在幾次自旋失敗后就將線程阻塞，這是為了避免不必要地占用CPU；
- CLH是自旋在前繼節點的標志位上的，而AQS是自旋在
p == head上面（即不停地判斷前繼節點是否是頭節點），只有在發現前繼節點是頭節點時，才會通過tryAcquire嘗試獲得鎖，這里有一個比較另我困惑的地方，就是head是一個volatile的全局引用，這么做的話顯然違背了CLH鎖的Local Spin的思想，具體原因未知，可能是因為AQS最初就是被設計為阻塞的同步器而不是自旋鎖吧。
acquireShared方法
點進這個方法，發現其邏輯和acquire基本一樣，唯獨不同的地方如下：
private void doAcquireShared(int arg) {
//共享模式入隊
final Node node = addWaiter(Node.SHARED);
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor();
if (p == head) {
int r = tryAcquireShared(arg);
if (r >= 0) {
//這里不同
setHeadAndPropagate(node, r);
p.next = null; // help GC
if (interrupted)
selfInterrupt();
failed = false;
return;
}
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
第一行的addWaiter會將節點標記為共享模式入隊（這個標記其實就是在Node的nextWaiter屬性上添加一個Node.SHARED，在CLH隊列中，nextWaiter屬性沒有用，所以這里就暫時拿來標記，isShared方法會用這個標記來判斷節點是否為共享模式）。
雖然寫法和acquire不太一樣，但是可以看出邏輯基本相同，唯一值得注意的地方是，acquire方法在tryAcquire成功時，直接setHead將自己置為CLH隊列的隊頭，而這里調用了一個叫做setHeadAndPropagate的方法，雖然名字看起來差不多，但是邏輯卻很不相同，點開來看看：
/**
* @param node the node
* @param propagate 剩余許可數量
*/
private void setHeadAndPropagate(Node node, int propagate) {
Node h = head; // Record old head for check below
setHead(node);
if (propagate > 0 || h == null || h.waitStatus < 0 ||
(h = head) == null || h.waitStatus < 0) {
Node s = node.next;
if (s == null || s.isShared())
doReleaseShared();
}
}
上面的代碼除了將自己置為頭節點外，還會繼續嘗試喚醒后繼節點（doReleaseShared），讓他們也來嘗試爭搶鎖。
doReleaseShared的代碼如下：
private void doReleaseShared() {
for (;;) {
Node h = head;
if (h != null && h != tail) {
int ws = h.waitStatus;
if (ws == Node.SIGNAL) {
if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
continue; // loop to recheck cases
unparkSuccessor(h);
}
else if (ws == 0 &&
!compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
continue; // loop on failed CAS
}
if (h == head) // loop if head changed
break;
}
}
可以看出這個方法會讓head的waitStatus產生如下變化：
releaseShared方法
主要就是調用上面提到的doReleaseShared方法：
public final boolean releaseShared(int arg) {
if (tryReleaseShared(arg)) {
doReleaseShared();
return true;
}
return false;
}
從這里我們可以看出doReleaseShared方法會在線程獲得鎖和釋放鎖時分別調用一次，所以在共享模式下一個線程對應的節點比較常見的狀態轉移大約是0(新建節點時) -> SIGNAL -> 0 -> PROPAGATE
ConditionObject內部類
雖然加鎖和釋放鎖的代碼都講完了，但是AQS遠沒有那么簡單。
仔細看一下源碼，發現AQS還有一個叫做ConditionObject的內部類，這個類是用來干嘛的呢？
在使用conncurrent包中的鎖（比如ReentrantLock）的時候，我們一般會使用lock.newCondition()方法返回一個Condition對象來對爭搶鎖的線程進行同步。
看一下ReentrantLock的newCondition方法的代碼：
public Condition newCondition() {
return sync.newCondition();
}
發現是委托給內部類Sync的一個實例sync的newCondition方法，在點進去看看Sync的newCondition方法，內容如下：
final ConditionObject newCondition() {
return new ConditionObject();
}
這里出現了ConditionObject，Sync繼承了AQS，這里的ConditionObject就是AQS中的內部類ConditionObject，這個類幾乎不需要經過任何修改就可以直接用來同步，感覺很神奇。
其實ConditionObject內部又維護了一個隊列，我稱之為Condition隊列，這個隊列同樣是由Node類的實例組成。
我們來看一下它的三個重要方法，分別是：
- await
- signal
- signalAll
await方法
await方法的主體邏輯如下：
public final void await() throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
//流程圖一
Node node = addConditionWaiter();
//二
int savedState = fullyRelease(node);
int interruptMode = 0;
//三
while (!isOnSyncQueue(node)) {
//四
LockSupport.park(this);
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
}
//五
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
if (node.nextWaiter != null) // clean up if cancelled
unlinkCancelledWaiters();
if (interruptMode != 0)
reportInterruptAfterWait(interruptMode);
}
①
對應著addConditionWaiter方法的調用，這個ConditionObject實例自己的方法。從addConditionWaiter方法可以看出，Node類的nextWaiter字段其實是用來存放Condition隊列的后繼的，要和next字段（用來存放CLH隊列后繼）進行區分。
| 字段 | 含義 |
|---|---|
| next | CLH隊列中的后繼 |
| nextWaiter | Condition隊列中的后繼，如果Node節點在CLH隊列中，這個字段也可能作為共享模式（Node.SHARED）的標記 |
private Node addConditionWaiter() {
Node t = lastWaiter;
// If lastWaiter is cancelled, clean out.
if (t != null && t.waitStatus != Node.CONDITION) {
unlinkCancelledWaiters();
t = lastWaiter;
}
Node node = new Node(Thread.currentThread(), Node.CONDITION);
if (t == null)
firstWaiter = node;
else
t.nextWaiter = node;
lastWaiter = node;
return node;
}
②
對應著fullyRelease方法的調用，fullyRelease會先保存當前同步變量（state），然后通過之前講過的release方法將其全部釋放掉，最后將其保存的同步變量（state）返回給上層方法，留復原的時候用，代碼如下：
final int fullyRelease(Node node) {
boolean failed = true;
try {
int savedState = getState();
if (release(savedState)) {
failed = false;
return savedState;
} else {
throw new IllegalMonitorStateException();
}
} finally {
if (failed)
node.waitStatus = Node.CANCELLED;
}
}
③
這一步其實就是while循環的判斷條件isOnSyncQueue方法：
final boolean isOnSyncQueue(Node node) {
if (node.waitStatus == Node.CONDITION || node.prev == null)
return false;
if (node.next != null) // If has successor, it must be on queue
return true;
return findNodeFromTail(node);
}
這個方法其實就是在判斷node節點是否在CLH隊列中，這個node就是在第①步中創建并加入Condition隊列的節點。
可能會疑惑，明明是在Condition隊列中的節點，怎么又突然跑到CLH隊列中呢？其實是下文中的signal方法搞的鬼。
④
這一步很明顯就是while循環中的LockSupport.park(this);，這里也是利用LockSupport阻塞線程的。
這里需要注意的一個細節是下面兩句的中斷檢查：
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
點開checkInterruptWhileWaiting方法：
/**
* Checks for interrupt, returning THROW_IE if interrupted
* before signalled, REINTERRUPT if after signalled, or
* 0 if not interrupted.
*/
private int checkInterruptWhileWaiting(Node node) {
return Thread.interrupted() ?
(transferAfterCancelledWait(node) ? THROW_IE : REINTERRUPT) :
0;
}
英文注釋中已經解釋了這個方法的含義：如果中斷發生在signal之前，則在await最后會拋出InterruptedException異常（這里標記為THROW_IE）；如果中斷發生在signale之后，則選擇在最后重置中斷位（標記為REINTERRUPT）。標記的處理在await方法的最后一句reportInterruptAfterWait調用里面進行，reportInterruptAfterWait內容如下：
private void reportInterruptAfterWait(int interruptMode)
throws InterruptedException {
if (interruptMode == THROW_IE)
throw new InterruptedException();
else if (interruptMode == REINTERRUPT)
selfInterrupt();
}
含義非常顯而易見。
為什么要做這兩種不同的中斷處理呢？我覺得是為了方便上層應用區分：線程從await方法中蘇醒究竟是因為中斷（THROW_IE）還是因為被其他線程signal（REINTERRUPT）。
| 標記 | 行為 | 含義 |
|---|---|---|
| THROW_IE | await方法的最后拋出InterruptedException異常 | 線程蘇醒是由中斷引起的 |
| REINTERRUPT | await方法的最后重置中斷標志位 | 線程蘇醒是由其他線程調用signal方法引起的 |
再回到checkInterruptWhileWaiting方法，這個方法中處理判斷要怎么處理中斷以外，transferAfterCancelledWait調用還干了其他事情，代碼如下：
final boolean transferAfterCancelledWait(Node node) {
if (compareAndSetWaitStatus(node, Node.CONDITION, 0)) {
enq(node);
return true;
}
/*
* If we lost out to a signal(), then we can't proceed
* until it finishes its enq(). Cancelling during an
* incomplete transfer is both rare and transient, so just
* spin.
*/
while (!isOnSyncQueue(node))
Thread.yield();
return false;
}
這個方法一定會等到節點加入CLH隊列才會返回，而且按照英文注釋，下面那種自旋的情況只有在release方法將節點從Condition隊列搬運到CLH隊列的工程中才會發生，發生的可能性是很低的，所以我們可以認為當線程被中斷后，它就會立刻將自己加入CLH隊列。
⑤
⑤主要就是對我之前講過的acquireQueued方法的調用，里面的過程見我對acquire方法的講解，線程會在這個方法里反復嘗試，直到獲得鎖才會退出該方法（即便遇到了中斷也直到獲得鎖才會退出，這時acquireQueued返回true）。
signal方法
主體邏輯的流程圖如下：
① ②
signal方法的代碼如下：
public final void signal() {
//流程圖節點一
if (!isHeldExclusively())
//二
throw new IllegalMonitorStateException();
//剩下的步驟（三,四,五,六,七）
Node first = firstWaiter;
if (first != null)
doSignal(first);
}
①②兩步對應著signal方法的前兩句，非常顯然，就不多說了。
③
接下來的步驟的關鍵是doSignal方法：
private void doSignal(Node first) {
do {
if ( (firstWaiter = first.nextWaiter) == null)
lastWaiter = null;
first.nextWaiter = null;
} while (!transferForSignal(first) &&
(first = firstWaiter) != null);
}
第二行的firstWaiter = first.nextWaiter會獲取Condition隊列的下一個節點，這個節點被獲取過之后就會被從Condition隊列中刪除。
④
④其實就是while語句中的第一個判斷條件，第二個判斷條件很好懂，就是如果一直到隊列尾部都沒有找到合適的節點，循環就結束。
這個循環中需要注意一點的是，雖然每次一進來就會獲取下一個節點（將Condition隊列隊頭(firstWaiter)設置為下一個節點 ），但是傳進while的第一個判斷條件transferForSignal方法的參數其實是前一個節點（first），第二個判斷條件用的才是firstWaiter節點。
第一個判斷條件的含義需要點開transferForSignal方法才能明白：
final boolean transferForSignal(Node node) {
if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
return false;
Node p = enq(node);
int ws = p.waitStatus;
if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
LockSupport.unpark(node.thread);
return true;
}
只有在第一行的CAS操作失敗時才會返回false，個人認為在這里CAS操作失敗的唯一可能就是node的waitStatus不是CONDITION，所以我認為第一個判斷條件的含義就是判斷節點的waitStatus是否是CONDITION。
⑤
從transferForSignal方法中可以看出在CAS操作成功后，首先就會調用enq方法將node節點加入CLH隊列（node節點在前面的while循環中已經從Condition隊列刪除了，所以node節點同時只會在一個隊列），enq方法同時會返回node節點的前繼。在這里我們也可以看出，之所以Condition隊列和CLH隊列都采用Node類作為節點的原因就是為了方便將節點從Condition隊列搬運到CLH隊列。
⑥ ⑦
transferForSignal的最后幾句干的就是這件事情：
if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
LockSupport.unpark(node.thread);
調用signal方法的線程先企圖幫助node節點對應的等待線程將它的CLH隊列的前繼的waitStatus設置為SIGNAL，如果不成功的話才將等待線程喚醒，讓其自行設置。
之所以要進行這么一次嘗試，是為了減少線程切換的開銷，盡量在當前線程把事情都做掉，就不再麻煩等待線程了，等到有資源的時候，自然會有它CLH隊列的前繼來將其喚醒。
signalAll方法
它與signal唯一的不同就在于，將transferForSignal方法加入了循環體，并且將while循環的判斷條件改成了first != null。
do {
Node next = first.nextWaiter;
first.nextWaiter = null;
transferForSignal(first);
first = next;
} while (first != null);
也就是說它會遍歷完Condition隊列將他們全部加入CLH隊列。
參考文獻
《The Art of Multiprocessor Programming》
