JDK1.8原始碼分析之AbstractQueuedSynchronizer
一、前言
在鎖框架中，AbstractQueuedSynchronizer抽象類可以毫不誇張的說，佔據著核心地位，它提供了一個基於FIFO佇列，可以用於構建鎖或者其他相關同步裝置的基礎框架。所以很有必要好好分析。
二、AbstractQueuedSynchronizer資料結構
分析類，首先就要分析底層採用了何種資料結構，抓住核心點進行分析，經過分析可知，AbstractQueuedSynchronizer類的資料結構如下
說明：AbstractQueuedSynchronizer類底層的資料結構是使用雙向連結串列，是佇列的一種實現，故也可看成是佇列，其中Sync queue，即同步佇列，是雙向連結串列，包括head結點和tail結點，head結點主要用作後續的排程。而Condition queue不是必須的，其是一個單向連結串列，只有當使用Condition時，才會存在此單向連結串列。並且可能會有多個Condition queue。
三、AbstractQueuedSynchronizer原始碼分析
3.1 類的繼承關係
public abstract class AbstractQueuedSynchronizer
extends AbstractOwnableSynchronizer
implements java.io.Serializable
說明：從類繼承關係可知，AbstractQueuedSynchronizer繼承自AbstractOwnableSynchronizer抽象類，並且實現了Serializable介面，可以進行序列化。而AbstractOwnableSynchronizer抽象類的原始碼如下
View Code
說明：AbstractOwnableSynchronizer抽象類中，可以設定獨佔資源執行緒和獲取獨佔資源執行緒。分別為setExclusiveOwnerThread與getExclusiveOwnerThread方法，這兩個方法會被子類呼叫。
3.2 類的內部類
AbstractQueuedSynchronizer類有兩個內部類，分別為Node類與ConditionObject類。下面分別做介紹。
1. Node類
static final class Node {
// 模式，分為共享與獨佔
// 共享模式
static final Node SHARED = new Node();
// 獨佔模式
static final Node EXCLUSIVE = null;
// 結點狀態
// CANCELLED，值為1，表示當前的執行緒被取消
// SIGNAL，值為-1，表示當前節點的後繼節點包含的執行緒需要執行，也就是unpark
// CONDITION，值為-2，表示當前節點在等待condition，也就是在condition佇列中
// PROPAGATE，值為-3，表示當前場景下後續的acquireShared能夠得以執行
// 值為0，表示當前節點在sync佇列中，等待著獲取鎖
static final int CANCELLED = 1;
static final int SIGNAL = -1;
static final int CONDITION = -2;
static final int PROPAGATE = -3;
// 結點狀態
volatile int waitStatus;
// 前驅結點
volatile Node prev;
// 後繼結點
volatile Node next;
// 結點所對應的執行緒
volatile Thread thread;
// 下一個等待者
Node nextWaiter;
// 結點是否在共享模式下等待
final boolean isShared() {
return nextWaiter == SHARED;
}
// 獲取前驅結點，若前驅結點為空，丟擲異常
final Node predecessor() throws NullPointerException {
// 儲存前驅結點
Node p = prev;
if (p == null) // 前驅結點為空，丟擲異常
throw new NullPointerException();
else // 前驅結點不為空，返回
return p;
}
// 無參建構函式
Node() { // Used to establish initial head or SHARED marker
}
// 建構函式
Node(Thread thread, Node mode) { // Used by addWaiter
this.nextWaiter = mode;
this.thread = thread;
}
// 建構函式
Node(Thread thread, int waitStatus) { // Used by Condition
this.waitStatus = waitStatus;
this.thread = thread;
}
}
說明：每個執行緒被阻塞的執行緒都會被封裝成一個Node結點，放入佇列。每個節點包含了一個Thread型別的引用，並且每個節點都存在一個狀態，具體狀態如下。
① CANCELLED，值為1，表示當前的執行緒被取消。
② SIGNAL，值為-1，表示當前節點的後繼節點包含的執行緒需要執行，需要進行unpark操作。
③ CONDITION，值為-2，表示當前節點在等待condition，也就是在condition queue中。
④ PROPAGATE，值為-3，表示當前場景下後續的acquireShared能夠得以執行。
⑤ 值為0，表示當前節點在sync queue中，等待著獲取鎖。
2. ConditionObject類
View Code
說明：此類實現了Condition介面，Condition介面定義了條件操作規範，具體如下
View Code
說明：Condition介面中定義了await、signal函式，用來等待條件、釋放條件。之後會詳細分析CondtionObject的原始碼。
3.3 類的屬性
View Code
說明：屬性中包含了頭結點head，尾結點tail，狀態state、自旋時間spinForTimeoutThreshold，還有AbstractQueuedSynchronizer抽象的屬性在記憶體中的偏移地址，通過該偏移地址，可以獲取和設定該屬性的值，同時還包括一個靜態初始化塊，用於載入記憶體偏移地址。
3.4 類的建構函式
protected AbstractQueuedSynchronizer() { }
說明：此類建構函式為從抽象建構函式，供子類呼叫。
3.5 類的核心函式
1. acquire函式
該函式以獨佔模式獲取(資源)，忽略中斷，即執行緒在aquire過程中，中斷此執行緒是無效的。原始碼如下
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
由上述原始碼可以知道，當一個執行緒呼叫acquire時，呼叫方法流程如下。
說明：
① 首先呼叫tryAcquire函式，呼叫此方法的執行緒會試圖在獨佔模式下獲取物件狀態。此方法應該查詢是否允許它在獨佔模式下獲取物件狀態，如果允許，則獲取它。在AbstractQueuedSynchronizer原始碼中預設會丟擲一個異常，即需要子類去重寫此函式完成自己的邏輯。之後會進行分析。
② 若tryAcquire失敗，則呼叫addWaiter函式，addWaiter函式完成的功能是將呼叫此方法的執行緒封裝成為一個結點並放入Sync queue。
③ 呼叫acquireQueued函式，此函式完成的功能是Sync queue中的結點不斷嘗試獲取資源，若成功，則返回true，否則，返回false。
由於tryAcquire預設實現是丟擲異常，所以此時，不進行分析，之後會結合一個例子進行分析。
首先分析addWaiter函式
// 新增等待者
private Node addWaiter(Node mode) {
// 新生成一個結點，預設為獨佔模式
Node node = new Node(Thread.currentThread(), mode);
// Try the fast path of enq; backup to full enq on failure
// 儲存尾結點
Node pred = tail;
if (pred != null) { // 尾結點不為空，即已經被初始化
// 將node結點的prev域連線到尾結點
node.prev = pred;
if (compareAndSetTail(pred, node)) { // 比較pred是否為尾結點，是則將尾結點設定為node
// 設定尾結點的next域為node
pred.next = node;
return node; // 返回新生成的結點
}
}
enq(node); // 尾結點為空(即還沒有被初始化過)，或者是compareAndSetTail操作失敗，則入佇列
return node;
}
說明：addWaiter函式使用快速新增的方式往sync queue尾部新增結點，如果sync queue佇列還沒有初始化，則會使用enq插入佇列中，enq方法原始碼如下
// 入佇列
private Node enq(final Node node) {
for (;;) { // 無限迴圈，確保結點能夠成功入佇列
// 儲存尾結點
Node t = tail;
if (t == null) { // 尾結點為空，即還沒被初始化
if (compareAndSetHead(new Node())) // 頭結點為空，並設定頭結點為新生成的結點
tail = head; // 頭結點與尾結點都指向同一個新生結點
} else { // 尾結點不為空，即已經被初始化過
// 將node結點的prev域連線到尾結點
node.prev = t;
if (compareAndSetTail(t, node)) { // 比較結點t是否為尾結點，若是則將尾結點設定為node
// 設定尾結點的next域為node
t.next = node;
return t; // 返回尾結點
}
}
}
}
說明：enq函式會使用無限迴圈來確保節點的成功插入。
現在，分析acquireQueue函式。其原始碼如下
// sync佇列中的結點在獨佔且忽略中斷的模式下獲取(資源)
final boolean acquireQueued(final Node node, int arg) {
// 標誌
boolean failed = true;
try {
// 中斷標誌
boolean interrupted = false;
for (;;) { // 無限迴圈
// 獲取node節點的前驅結點
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);
}
}
說明：首先獲取當前節點的前驅節點，如果前驅節點是頭結點並且能夠獲取(資源)，代表該當前節點能夠佔有鎖，設定頭結點為當前節點，返回。否則，呼叫shouldParkAfterFailedAcquire和parkAndCheckInterrupt函式，首先，我們看shouldParkAfterFailedAcquire函式，程式碼如下
// 當獲取(資源)失敗後，檢查並且更新結點狀態
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
// 獲取前驅結點的狀態
int ws = pred.waitStatus;
if (ws == Node.SIGNAL) // 狀態為SIGNAL，為-1
/*
* This node has already set status asking a release
* to signal it, so it can safely park.
*/
// 可以進行park操作
return true;
if (ws > 0) { // 表示狀態為CANCELLED，為1
/*
* Predecessor was cancelled. Skip over predecessors and
* indicate retry.
*/
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0); // 找到pred結點前面最近的一個狀態不為CANCELLED的結點
// 賦值pred結點的next域
pred.next = node;
} else { // 為PROPAGATE -3 或者是0 表示無狀態,(為CONDITION -2時，表示此節點在condition queue中)
/*
* waitStatus must be 0 or PROPAGATE. Indicate that we
* need a signal, but don't park yet. Caller will need to
* retry to make sure it cannot acquire before parking.
*/
// 比較並設定前驅結點的狀態為SIGNAL
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
// 不能進行park操作
return false;
}
說明：只有當該節點的前驅結點的狀態為SIGNAL時，才可以對該結點所封裝的執行緒進行park操作。否則，將不能進行park操作。再看parkAndCheckInterrupt函式，原始碼如下
// 進行park操作並且返回該執行緒是否被中斷
private final boolean parkAndCheckInterrupt() {
// 在許可可用之前禁用當前執行緒，並且設定了blocker
LockSupport.park(this);
return Thread.interrupted(); // 當前執行緒是否已被中斷，並清除中斷標記位
}
說明：parkAndCheckInterrupt函式裡的邏輯是首先執行park操作，即禁用當前執行緒，然後返回該執行緒是否已經被中斷。再看final塊中的cancelAcquire函式，其原始碼如下
// 取消繼續獲取(資源)
private void cancelAcquire(Node node) {
// Ignore if node doesn't exist
// node為空，返回
if (node == null)
return;
// 設定node結點的thread為空
node.thread = null;
// Skip cancelled predecessors
// 儲存node的前驅結點
Node pred = node.prev;
while (pred.waitStatus > 0) // 找到node前驅結點中第一個狀態小於0的結點，即不為CANCELLED狀態的結點
node.prev = pred = pred.prev;
// predNext is the apparent node to unsplice. CASes below will
// fail if not, in which case, we lost race vs another cancel
// or signal, so no further action is necessary.
// 獲取pred結點的下一個結點
Node predNext = pred.next;
// Can use unconditional write instead of CAS here.
// After this atomic step, other Nodes can skip past us.
// Before, we are free of interference from other threads.
// 設定node結點的狀態為CANCELLED
node.waitStatus = Node.CANCELLED;
// If we are the tail, remove ourselves.
if (node == tail && compareAndSetTail(node, pred)) { // node結點為尾結點，則設定尾結點為pred結點
// 比較並設定pred結點的next節點為null
compareAndSetNext(pred, predNext, null);
} else { // node結點不為尾結點，或者比較設定不成功
// If successor needs signal, try to set pred's next-link
// so it will get one. Otherwise wake it up to propagate.
int ws;
if (pred != head &&
((ws = pred.waitStatus) == Node.SIGNAL ||
(ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) &&
pred.thread != null) { // （pred結點不為頭結點，並且pred結點的狀態為SIGNAL）或者
// pred結點狀態小於等於0，並且比較並設定等待狀態為SIGNAL成功，並且pred結點所封裝的執行緒不為空
// 儲存結點的後繼
Node next = node.next;
if (next != null && next.waitStatus <= 0) // 後繼不為空並且後繼的狀態小於等於0
compareAndSetNext(pred, predNext, next); // 比較並設定pred.next = next;
} else {
unparkSuccessor(node); // 釋放node的前一個結點
}
node.next = node; // help GC
}
}
說明：該函式完成的功能就是取消當前執行緒對資源的獲取，即設定該結點的狀態為CANCELLED，接著我們再看unparkSuccessor函式，原始碼如下
// 釋放後繼結點
private void unparkSuccessor(Node node) {
/*
* If status is negative (i.e., possibly needing signal) try
* to clear in anticipation of signalling. It is OK if this
* fails or if status is changed by waiting thread.
*/
// 獲取node結點的等待狀態
int ws = node.waitStatus;
if (ws < 0) // 狀態值小於0，為SIGNAL -1 或 CONDITION -2 或 PROPAGATE -3
// 比較並且設定結點等待狀態，設定為0
compareAndSetWaitStatus(node, ws, 0);
/*
* Thread to unpark is held in successor, which is normally
* just the next node. But if cancelled or apparently null,
* traverse backwards from tail to find the actual
* non-cancelled successor.
*/
// 獲取node節點的下一個結點
Node s = node.next;
if (s == null || s.waitStatus > 0) { // 下一個結點為空或者下一個節點的等待狀態大於0，即為CANCELLED
// s賦值為空
s = null;
// 從尾結點開始從後往前開始遍歷
for (Node t = tail; t != null && t != node; t = t.prev)
if (t.waitStatus <= 0) // 找到等待狀態小於等於0的結點，找到最前的狀態小於等於0的結點
// 儲存結點
s = t;
}
if (s != null) // 該結點不為為空，釋放許可
LockSupport.unpark(s.thread);
}
說明：該函式的作用就是為了釋放node節點的後繼結點。
對於cancelAcquire與unparkSuccessor函式，如下示意圖可以清晰的表示。
說明：其中node為引數，在執行完cancelAcquire函式後的效果就是unpark了s結點所包含的t4執行緒。
現在，再來看acquireQueued函式的整個的邏輯。邏輯如下
① 判斷結點的前驅是否為head並且是否成功獲取(資源)。
② 若步驟①均滿足，則設定結點為head，之後會判斷是否finally模組，然後返回。
③ 若步驟①不滿足，則判斷是否需要park當前執行緒，是否需要park當前執行緒的邏輯是判斷結點的前驅結點的狀態是否為SIGNAL，若是，則park當前結點，否則，不進行park操作。
④ 若park了當前執行緒，之後某個執行緒對本執行緒unpark後，並且本執行緒也獲得機會執行。那麼，將會繼續進行步驟①的判斷。
2. release
以獨佔模式釋放物件，其原始碼如下
public final boolean release(int arg) {
if (tryRelease(arg)) { // 釋放成功
// 儲存頭結點
Node h = head;
if (h != null && h.waitStatus != 0) // 頭結點不為空並且頭結點狀態不為0
unparkSuccessor(h); //釋放頭結點的後繼結點
return true;
}
return false;
}
說明：其中，tryRelease的預設實現是丟擲異常，需要具體的子類實現，如果tryRelease成功，那麼如果頭結點不為空並且頭結點的狀態不為0，則釋放頭結點的後繼結點，unparkSuccessor函式已經分析過，不再累贅。
對於其他函式我們也可以分析，與前面分析的函式大同小異，所以，不再累贅。
四、示例分析
1. 示例一
藉助下面示例來分析AbstractQueuedSyncrhonizer內部的工作機制。示例原始碼如下
package com.hust.grid.leesf.abstractqueuedsynchronizer;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
class MyThread extends Thread {
private Lock lock;
public MyThread(String name, Lock lock) {
super(name);
this.lock = lock;
}
public void run () {
lock.lock();
try {
System.out.println(Thread.currentThread() + " running");
} finally {
lock.unlock();
}
}
}
public class AbstractQueuedSynchonizerDemo {
public static void main(String[] args) {
Lock lock = new ReentrantLock();
MyThread t1 = new MyThread("t1", lock);
MyThread t2 = new MyThread("t2", lock);
t1.start();
t2.start();
}
}
執行結果（可能的一種）：
Thread[t1,5,main] running Thread[t2,5,main] running
結果分析：從示例可知，執行緒t1與t2共用了一把鎖，即同一個lock。可能會存在如下一種時序。
說明：首先執行緒t1先執行lock.lock操作，然後t2執行lock.lock操作，然後t1執行lock.unlock操作，最後t2執行lock.unlock操作。基於這樣的時序，分析AbstractQueuedSynchronizer內部的工作機制。
① t1執行緒呼叫lock.lock函式，其函式呼叫順序如下，只給出了主要的函式呼叫。
說明：其中，前面的部分表示哪個類，後面是具體的類中的哪個方法，AQS表示AbstractQueuedSynchronizer類，AOS表示AbstractOwnableSynchronizer類。
② t2執行緒呼叫lock.lock函式，其函式呼叫順序如下，只給出了主要的函式呼叫。
說明：經過一系列的函式呼叫，最後達到的狀態是禁用t2執行緒，因為呼叫了LockSupport.lock。
③ t1執行緒呼叫lock.unlock，其函式呼叫順序如下，只給出了主要的函式呼叫。
說明：t1執行緒中呼叫lock.unlock後，經過一系列的呼叫，最終的狀態是釋放了許可，因為呼叫了LockSupport.unpark。這時，t2執行緒就可以繼續運行了。此時，會繼續恢復t2執行緒執行環境，繼續執行LockSupport.park後面的語句，即進一步呼叫如下。
說明：在上一步呼叫了LockSupport.unpark後，t2執行緒恢復執行，則執行parkAndCheckInterrupt，之後，繼續執行acquireQueued函式，最後達到的狀態是頭結點head與尾結點tail均指向了t2執行緒所在的結點，並且之前的頭結點已經從sync佇列中斷開了。
④ t2執行緒呼叫lock.unlock，其函式呼叫順序如下，只給出了主要的函式呼叫。
說明：t2執行緒執行lock.unlock後，最終達到的狀態還是與之前的狀態一樣。
2. 示例二
下面我們結合Condition實現生產者與消費者，來進一步分析AbstractQueuedSynchronizer的內部工作機制。
Depot（倉庫）類
package com.hust.grid.leesf.reentrantLock;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
public class Depot {
private int size;
private int capacity;
private Lock lock;
private Condition fullCondition;
private Condition emptyCondition;
public Depot(int capacity) {
this.capacity = capacity;
lock = new ReentrantLock();
fullCondition = lock.newCondition();
emptyCondition = lock.newCondition();
}
public void produce(int no) {
lock.lock();
int left = no;
try {
while (left > 0) {
while (size >= capacity) {
System.out.println(Thread.currentThread() + " before await");
fullCondition.await();
System.out.println(Thread.currentThread() + " after await");
}
int inc = (left + size) > capacity ? (capacity - size) : left;
left -= inc;
size += inc;
System.out.println("produce = " + inc + ", size = " + size);
emptyCondition.signal();
}
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.unlock();
}
}
public void consume(int no) {
lock.lock();
int left = no;
try {
while (left > 0) {
while (size <= 0) {
System.out.println(Thread.currentThread() + " before await");
emptyCondition.await();
System.out.println(Thread.currentThread() + " after await");
}
int dec = (size - left) > 0 ? left : size;
left -= dec;
size -= dec;
System.out.println("consume = " + dec + ", size = " + size);
fullCondition.signal();
}
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.unlock();
}
}
}
測試類
package com.hust.grid.leesf.reentrantLock;
class Consumer {
private Depot depot;
public Consumer(Depot depot) {
this.depot = depot;
}
public void consume(int no) {
new Thread(new Runnable() {
@Override
public void run() {
depot.consume(no);
}
}, no + " consume thread").start();
}
}
class Producer {
private Depot depot;
public Producer(Depot depot) {
this.depot = depot;
}
public void produce(int no) {
new Thread(new Runnable() {
@Override
public void run() {
depot.produce(no);
}
}, no + " produce thread").start();
}
}
public class ReentrantLockDemo {
public static void main(String[] args) throws InterruptedException {
Depot depot = new Depot(500);
new Producer(depot).produce(500);
new Producer(depot).produce(200);
new Consumer(depot).consume(500);
new Consumer(depot).consume(200);
}
}
執行結果（可能的一種）：
produce = 500, size = 500 Thread[200 produce thread,5,main] before await consume = 500, size = 0 Thread[200 consume thread,5,main] before await Thread[200 produce thread,5,main] after await produce = 200, size = 200 Thread[200 consume thread,5,main] after await consume = 200, size = 0
說明：根據結果，我們猜測一種可能的時序如下
說明：p1代表produce 500的那個執行緒，p2代表produce 200的那個執行緒，c1代表consume 500的那個執行緒，c2代表consume 200的那個執行緒。
1. p1執行緒呼叫lock.lock，獲得鎖，繼續執行，函式呼叫順序在前面已經給出。
2. p2執行緒呼叫lock.lock，由前面的分析可得到如下的最終狀態。
說明：p2執行緒呼叫lock.lock後，會禁止p2執行緒的繼續執行，因為執行了LockSupport.park操作。
3. c1執行緒呼叫lock.lock，由前面的分析得到如下的最終狀態。
說明：最終c1執行緒會在sync queue佇列的尾部，並且其結點的前驅結點（包含p2的結點）的waitStatus變為了SIGNAL。
4. c2執行緒呼叫lock.lock，由前面的分析得到如下的最終狀態。
說明：最終c1執行緒會在sync queue佇列的尾部，並且其結點的前驅結點（包含c1的結點）的waitStatus變為了SIGNAL。
5. p1執行緒執行emptyCondition.signal，其函式呼叫順序如下，只給出了主要的函式呼叫。
說明：AQS.CO表示AbstractQueuedSynchronizer.ConditionObject類。此時呼叫signal方法不會產生任何其他效果。
6. p1執行緒執行lock.unlock，根據前面的分析可知，最終的狀態如下。
說明：此時，p2執行緒所在的結點為頭結點，並且其他兩個執行緒（c1、c2）依舊被禁止，所以，此時p2執行緒繼續執行，執行使用者邏輯。
7. p2執行緒執行fullCondition.await，其函式呼叫順序如下，只給出了主要的函式呼叫。
說明：最終到達的狀態是新生成了一個結點，包含了p2執行緒，此結點在condition queue中；並且sync queue中p2執行緒被禁止了，因為在執行了LockSupport.park操作。從函式一些呼叫可知，在await操作中執行緒會釋放鎖資源，供其他執行緒獲取。同時，head結點後繼結點的包含的執行緒的許可被釋放了，故其可以繼續執行。由於此時，只有c1執行緒可以執行，故執行c1。
8. 繼續執行c1執行緒，c1執行緒由於之前被park了，所以此時恢復，繼續之前的步驟，即還是執行前面提到的acquireQueued函式，之後，c1判斷自己的前驅結點為head，並且可以獲取鎖資源，最終到達的狀態如下。
說明：其中，head設定為包含c1執行緒的結點，c1繼續執行。
9. c1執行緒執行fullCondtion.signal，其函式呼叫順序如下，只給出了主要的函式呼叫。
說明：signal函式達到的最終結果是將包含p2執行緒的結點從condition queue中轉移到sync queue中，之後condition queue為null，之前的尾結點的狀態變為SIGNAL。
10. c1執行緒執行lock.unlock操作，根據之前的分析，經歷的狀態變化如下。
說明：最終c2執行緒會獲取鎖資源，繼續執行使用者邏輯。
11. c2執行緒執行emptyCondition.await，由前面的第七步分析，可知最終的狀態如下。
說明：await操作將會生成一個結點放入condition queue中與之前的一個condition queue是不相同的，並且unpark頭結點後面的結點，即包含執行緒p2的結點。
12. p2執行緒被unpark，故可以繼續執行，經過CPU排程後，p2繼續執行，之後p2執行緒在AQS:await函式中被park，繼續AQS.CO:await函式的執行，其函式呼叫順序如下，只給出了主要的函式呼叫。
13. p2繼續執行，執行emptyCondition.signal，根據第九步分析可知，最終到達的狀態如下。
說明：最終，將condition queue中的結點轉移到sync queue中，並新增至尾部，condition queue會為空，並且將head的狀態設定為SIGNAL。
14. p2執行緒執行lock.unlock操作，根據前面的分析可知，最後的到達的狀態如下。
說明：unlock操作會釋放c2執行緒的許可，並且將頭結點設定為c2執行緒所在的結點。
15. c2執行緒繼續執行，執行fullCondition. signal，由於此時fullCondition的condition queue已經不存在任何結點了，故其不會產生作用。
16. c2執行lock.unlock，由於c2是sync佇列中最後一個結點，故其不會再呼叫unparkSuccessor了，直接返回true。即整個流程就完成了。
五、總結
對於AbstractQueuedSynchronizer的分析，最核心的就是sync queue的分析。
① 每一個結點都是由前一個結點喚醒
② 當結點發現前驅結點是head並且嘗試獲取成功，則會輪到該執行緒執行。
③ condition queue中的結點向sync queue中轉移是通過signal操作完成的。
④ 當結點的狀態為SIGNAL時，表示後面的結點需要執行。
當然，此次分析沒有涉及到中斷操作，如果涉及到中斷操作，又會複雜得多，以後遇到這種情況，我們再進行詳細分析，AbstractQueuedSynchronizer類的設計令人歎為觀止，以後有機會還會進行分析。也謝謝各位園友的觀看~
最後給出兩篇參考連結
http://ifeve.com/introduce-abstractqueuedsynchronizer/
http://blog.csdn.net/chen77716/article/details/6641477