一、前言
在鎖框架中，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抽象類的原始碼如下
public abstract class AbstractOwnableSynchronizer implements java.io.Serializable { // 版本序列號 private static final long serialVersionUID = 3737899427754241961L; // 建構函式 protected AbstractOwnableSynchronizer() { } // 獨佔模式下的執行緒 private transient Thread exclusiveOwnerThread; // 設定獨佔執行緒 protected final void setExclusiveOwnerThread(Thread thread) { exclusiveOwnerThread = thread; } // 獲取獨佔執行緒 protected final Thread getExclusiveOwnerThread() { return exclusiveOwnerThread; } }
說明：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類
// 內部類 public class ConditionObject implements Condition, java.io.Serializable { // 版本號 private static final long serialVersionUID = 1173984872572414699L; /** First node of condition queue. */ // condition佇列的頭結點 private transient Node firstWaiter; /** Last node of condition queue. */ // condition佇列的尾結點 private transient Node lastWaiter; /** * Creates a new {@code ConditionObject} instance. */ // 建構函式 public ConditionObject() { } // Internal methods /** * Adds a new waiter to wait queue. * @return its new wait node */ // 新增新的waiter到wait佇列 private Node addConditionWaiter() { // 儲存尾結點 Node t = lastWaiter; // If lastWaiter is cancelled, clean out. if (t != null && t.waitStatus != Node.CONDITION) { // 尾結點不為空，並且尾結點的狀態不為CONDITION // 清除狀態為CONDITION的結點 unlinkCancelledWaiters(); // 將最後一個結點重新賦值給t t = lastWaiter; } // 新建一個結點 Node node = new Node(Thread.currentThread(), Node.CONDITION); if (t == null) // 尾結點為空 // 設定condition佇列的頭結點 firstWaiter = node; else // 尾結點不為空 // 設定為節點的nextWaiter域為node結點 t.nextWaiter = node; // 更新condition佇列的尾結點 lastWaiter = node; return node; } /** * Removes and transfers nodes until hit non-cancelled one or * null. Split out from signal in part to encourage compilers * to inline the case of no waiters. * @param first (non-null) the first node on condition queue */ private void doSignal(Node first) { // 迴圈 do { if ( (firstWaiter = first.nextWaiter) == null) // 該節點的nextWaiter為空 // 設定尾結點為空 lastWaiter = null; // 設定first結點的nextWaiter域 first.nextWaiter = null; } while (!transferForSignal(first) && (first = firstWaiter) != null); // 將結點從condition佇列轉移到sync佇列失敗並且condition佇列中的頭結點不為空，一直迴圈 } /** * Removes and transfers all nodes. * @param first (non-null) the first node on condition queue */ private void doSignalAll(Node first) { // condition佇列的頭結點尾結點都設定為空 lastWaiter = firstWaiter = null; // 迴圈 do { // 獲取first結點的nextWaiter域結點 Node next = first.nextWaiter; // 設定first結點的nextWaiter域為空 first.nextWaiter = null; // 將first結點從condition佇列轉移到sync佇列 transferForSignal(first); // 重新設定first first = next; } while (first != null); } /** * Unlinks cancelled waiter nodes from condition queue. * Called only while holding lock. This is called when * cancellation occurred during condition wait, and upon * insertion of a new waiter when lastWaiter is seen to have * been cancelled. This method is needed to avoid garbage * retention in the absence of signals. So even though it may * require a full traversal, it comes into play only when * timeouts or cancellations occur in the absence of * signals. It traverses all nodes rather than stopping at a * particular target to unlink all pointers to garbage nodes * without requiring many re-traversals during cancellation * storms. */ // 從condition佇列中清除狀態為CANCEL的結點 private void unlinkCancelledWaiters() { // 儲存condition佇列頭結點 Node t = firstWaiter; Node trail = null; while (t != null) { // t不為空 // 下一個結點 Node next = t.nextWaiter; if (t.waitStatus != Node.CONDITION) { // t結點的狀態不為CONDTION狀態 // 設定t節點的額nextWaiter域為空 t.nextWaiter = null; if (trail == null) // trail為空 // 重新設定condition佇列的頭結點 firstWaiter = next; else // trail不為空 // 設定trail結點的nextWaiter域為next結點 trail.nextWaiter = next; if (next == null) // next結點為空 // 設定condition佇列的尾結點 lastWaiter = trail; } else // t結點的狀態為CONDTION狀態 // 設定trail結點 trail = t; // 設定t結點 t = next; } } // public methods /** * Moves the longest-waiting thread, if one exists, from the * wait queue for this condition to the wait queue for the * owning lock. * * @throws IllegalMonitorStateException if {@link #isHeldExclusively} * returns {@code false} */ // 喚醒一個等待執行緒。如果所有的執行緒都在等待此條件，則選擇其中的一個喚醒。在從 await 返回之前，該執行緒必須重新獲取鎖。 public final void signal() { if (!isHeldExclusively()) // 不被當前執行緒獨佔，丟擲異常 throw new IllegalMonitorStateException(); // 儲存condition佇列頭結點 Node first = firstWaiter; if (first != null) // 頭結點不為空 // 喚醒一個等待執行緒 doSignal(first); } /** * Moves all threads from the wait queue for this condition to * the wait queue for the owning lock. * * @throws IllegalMonitorStateException if {@link #isHeldExclusively} * returns {@code false} */ // 喚醒所有等待執行緒。如果所有的執行緒都在等待此條件，則喚醒所有執行緒。在從 await 返回之前，每個執行緒都必須重新獲取鎖。 public final void signalAll() { if (!isHeldExclusively()) // 不被當前執行緒獨佔，丟擲異常 throw new IllegalMonitorStateException(); // 儲存condition佇列頭結點 Node first = firstWaiter; if (first != null) // 頭結點不為空 // 喚醒所有等待執行緒 doSignalAll(first); } /** * Implements uninterruptible condition wait. * <ol> * <li> Save lock state returned by {@link #getState}. * <li> Invoke {@link #release} with saved state as argument, * throwing IllegalMonitorStateException if it fails. * <li> Block until signalled. * <li> Reacquire by invoking specialized version of * {@link #acquire} with saved state as argument. * </ol> */ // 等待，當前執行緒在接到訊號之前一直處於等待狀態，不響應中斷 public final void awaitUninterruptibly() { // 新增一個結點到等待佇列 Node node = addConditionWaiter(); // 獲取釋放的狀態 int savedState = fullyRelease(node); boolean interrupted = false; while (!isOnSyncQueue(node)) { // // 阻塞當前執行緒 LockSupport.park(this); if (Thread.interrupted()) // 當前執行緒被中斷 // 設定interrupted狀態 interrupted = true; } if (acquireQueued(node, savedState) || interrupted) // selfInterrupt(); } /* * For interruptible waits, we need to track whether to throw * InterruptedException, if interrupted while blocked on * condition, versus reinterrupt current thread, if * interrupted while blocked waiting to re-acquire. */ /** Mode meaning to reinterrupt on exit from wait */ private static final int REINTERRUPT = 1; /** Mode meaning to throw InterruptedException on exit from wait */ private static final int THROW_IE = -1; /** * 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; } /** * Throws InterruptedException, reinterrupts current thread, or * does nothing, depending on mode. */ private void reportInterruptAfterWait(int interruptMode) throws InterruptedException { if (interruptMode == THROW_IE) throw new InterruptedException(); else if (interruptMode == REINTERRUPT) selfInterrupt(); } /** * Implements interruptible condition wait. * <ol> * <li> If current thread is interrupted, throw InterruptedException. * <li> Save lock state returned by {@link #getState}. * <li> Invoke {@link #release} with saved state as argument, * throwing IllegalMonitorStateException if it fails. * <li> Block until signalled or interrupted. * <li> Reacquire by invoking specialized version of * {@link #acquire} with saved state as argument. * <li> If interrupted while blocked in step 4, throw InterruptedException. * </ol> */ // // 等待，當前執行緒在接到訊號或被中斷之前一直處於等待狀態 public final void await() throws InterruptedException { if (Thread.interrupted()) // 當前執行緒被中斷，丟擲異常 throw new InterruptedException(); // 在wait佇列上新增一個結點 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); } /** * Implements timed condition wait. * <ol> * <li> If current thread is interrupted, throw InterruptedException. * <li> Save lock state returned by {@link #getState}. * <li> Invoke {@link #release} with saved state as argument, * throwing IllegalMonitorStateException if it fails. * <li> Block until signalled, interrupted, or timed out. * <li> Reacquire by invoking specialized version of * {@link #acquire} with saved state as argument. * <li> If interrupted while blocked in step 4, throw InterruptedException. * </ol> */ // 等待，當前執行緒在接到訊號、被中斷或到達指定等待時間之前一直處於等待狀態 public final long awaitNanos(long nanosTimeout) throws InterruptedException { if (Thread.interrupted()) throw new InterruptedException(); Node node = addConditionWaiter(); int savedState = fullyRelease(node); final long deadline = System.nanoTime() + nanosTimeout; int interruptMode = 0; while (!isOnSyncQueue(node)) { if (nanosTimeout <= 0L) { transferAfterCancelledWait(node); break; } if (nanosTimeout >= spinForTimeoutThreshold) LockSupport.parkNanos(this, nanosTimeout); if ((interruptMode = checkInterruptWhileWaiting(node)) != 0) break; nanosTimeout = deadline - System.nanoTime(); } if (acquireQueued(node, savedState) && interruptMode != THROW_IE) interruptMode = REINTERRUPT; if (node.nextWaiter != null) unlinkCancelledWaiters(); if (interruptMode != 0) reportInterruptAfterWait(interruptMode); return deadline - System.nanoTime(); } /** * Implements absolute timed condition wait. * <ol> * <li> If current thread is interrupted, throw InterruptedException. * <li> Save lock state returned by {@link #getState}. * <li> Invoke {@link #release} with saved state as argument, * throwing IllegalMonitorStateException if it fails. * <li> Block until signalled, interrupted, or timed out. * <li> Reacquire by invoking specialized version of * {@link #acquire} with saved state as argument. * <li> If interrupted while blocked in step 4, throw InterruptedException. * <li> If timed out while blocked in step 4, return false, else true. * </ol> */ // 等待，當前執行緒在接到訊號、被中斷或到達指定最後期限之前一直處於等待狀態 public final boolean awaitUntil(Date deadline) throws InterruptedException { long abstime = deadline.getTime(); if (Thread.interrupted()) throw new InterruptedException(); Node node = addConditionWaiter(); int savedState = fullyRelease(node); boolean timedout = false; int interruptMode = 0; while (!isOnSyncQueue(node)) { if (System.currentTimeMillis() > abstime) { timedout = transferAfterCancelledWait(node); break; } LockSupport.parkUntil(this, abstime); if ((interruptMode = checkInterruptWhileWaiting(node)) != 0) break; } if (acquireQueued(node, savedState) && interruptMode != THROW_IE) interruptMode = REINTERRUPT; if (node.nextWaiter != null) unlinkCancelledWaiters(); if (interruptMode != 0) reportInterruptAfterWait(interruptMode); return !timedout; } /** * Implements timed condition wait. * <ol> * <li> If current thread is interrupted, throw InterruptedException. * <li> Save lock state returned by {@link #getState}. * <li> Invoke {@link #release} with saved state as argument, * throwing IllegalMonitorStateException if it fails. * <li> Block until signalled, interrupted, or timed out. * <li> Reacquire by invoking specialized version of * {@link #acquire} with saved state as argument. * <li> If interrupted while blocked in step 4, throw InterruptedException. * <li> If timed out while blocked in step 4, return false, else true. * </ol> */ // 等待，當前執行緒在接到訊號、被中斷或到達指定等待時間之前一直處於等待狀態。此方法在行為上等效於：awaitNanos(unit.toNanos(time)) > 0 public final boolean await(long time, TimeUnit unit) throws InterruptedException { long nanosTimeout = unit.toNanos(time); if (Thread.interrupted()) throw new InterruptedException(); Node node = addConditionWaiter(); int savedState = fullyRelease(node); final long deadline = System.nanoTime() + nanosTimeout; boolean timedout = false; int interruptMode = 0; while (!isOnSyncQueue(node)) { if (nanosTimeout <= 0L) { timedout = transferAfterCancelledWait(node); break; } if (nanosTimeout >= spinForTimeoutThreshold) LockSupport.parkNanos(this, nanosTimeout); if ((interruptMode = checkInterruptWhileWaiting(node)) != 0) break; nanosTimeout = deadline - System.nanoTime(); } if (acquireQueued(node, savedState) && interruptMode != THROW_IE) interruptMode = REINTERRUPT; if (node.nextWaiter != null) unlinkCancelledWaiters(); if (interruptMode != 0) reportInterruptAfterWait(interruptMode); return !timedout; } // support for instrumentation /** * Returns true if this condition was created by the given * synchronization object. * * @return {@code true} if owned */ final boolean isOwnedBy(AbstractQueuedSynchronizer sync) { return sync == AbstractQueuedSynchronizer.this; } /** * Queries whether any threads are waiting on this condition. * Implements {@link AbstractQueuedSynchronizer#hasWaiters(ConditionObject)}. * * @return {@code true} if there are any waiting threads * @throws IllegalMonitorStateException if {@link #isHeldExclusively} * returns {@code false} */ // 查詢是否有正在等待此條件的任何執行緒 protected final boolean hasWaiters() { if (!isHeldExclusively()) throw new IllegalMonitorStateException(); for (Node w = firstWaiter; w != null; w = w.nextWaiter) { if (w.waitStatus == Node.CONDITION) return true; } return false; } /** * Returns an estimate of the number of threads waiting on * this condition. * Implements {@link AbstractQueuedSynchronizer#getWaitQueueLength(ConditionObject)}. * * @return the estimated number of waiting threads * @throws IllegalMonitorStateException if {@link #isHeldExclusively} * returns {@code false} */ // 返回正在等待此條件的執行緒數估計值 protected final int getWaitQueueLength() { if (!isHeldExclusively()) throw new IllegalMonitorStateException(); int n = 0; for (Node w = firstWaiter; w != null; w = w.nextWaiter) { if (w.waitStatus == Node.CONDITION) ++n; } return n; } /** * Returns a collection containing those threads that may be * waiting on this Condition. * Implements {@link AbstractQueuedSynchronizer#getWaitingThreads(ConditionObject)}. * * @return the collection of threads * @throws IllegalMonitorStateException if {@link #isHeldExclusively} * returns {@code false} */ // 返回包含那些可能正在等待此條件的執行緒集合 protected final Collection<Thread> getWaitingThreads() { if (!isHeldExclusively()) throw new IllegalMonitorStateException(); ArrayList<Thread> list = new ArrayList<Thread>(); for (Node w = firstWaiter; w != null; w = w.nextWaiter) { if (w.waitStatus == Node.CONDITION) { Thread t = w.thread; if (t != null) list.add(t); } } return list; } }
說明：此類實現了Condition介面，Condition介面定義了條件操作規範，具體如下
public interface Condition { // 等待，當前執行緒在接到訊號或被中斷之前一直處於等待狀態 void await() throws InterruptedException; // 等待，當前執行緒在接到訊號之前一直處於等待狀態，不響應中斷 void awaitUninterruptibly(); //等待，當前執行緒在接到訊號、被中斷或到達指定等待時間之前一直處於等待狀態 long awaitNanos(long nanosTimeout) throws InterruptedException; // 等待，當前執行緒在接到訊號、被中斷或到達指定等待時間之前一直處於等待狀態。此方法在行為上等效於：awaitNanos(unit.toNanos(time)) > 0 boolean await(long time, TimeUnit unit) throws InterruptedException; // 等待，當前執行緒在接到訊號、被中斷或到達指定最後期限之前一直處於等待狀態 boolean awaitUntil(Date deadline) throws InterruptedException; // 喚醒一個等待執行緒。如果所有的執行緒都在等待此條件，則選擇其中的一個喚醒。在從 await 返回之前，該執行緒必須重新獲取鎖。 void signal(); // 喚醒所有等待執行緒。如果所有的執行緒都在等待此條件，則喚醒所有執行緒。在從 await 返回之前，每個執行緒都必須重新獲取鎖。 void signalAll(); }
說明：Condition介面中定義了await、signal函式，用來等待條件、釋放條件。之後會詳細分析CondtionObject的原始碼。
3.3 類的屬性
public abstract class AbstractQueuedSynchronizer extends AbstractOwnableSynchronizer implements java.io.Serializable { // 版本號 private static final long serialVersionUID = 7373984972572414691L; // 頭結點 private transient volatile Node head; // 尾結點 private transient volatile Node tail; // 狀態 private volatile int state; // 自旋時間 static final long spinForTimeoutThreshold = 1000L; // Unsafe類例項 private static final Unsafe unsafe = Unsafe.getUnsafe(); // state記憶體偏移地址 private static final long stateOffset; // head記憶體偏移地址 private static final long headOffset; // state記憶體偏移地址 private static final long tailOffset; // tail記憶體偏移地址 private static final long waitStatusOffset; // next記憶體偏移地址 private static final long nextOffset; // 靜態初始化塊 static { try { stateOffset = unsafe.objectFieldOffset (AbstractQueuedSynchronizer.class.getDeclaredField("state")); headOffset = unsafe.objectFieldOffset (AbstractQueuedSynchronizer.class.getDeclaredField("head")); tailOffset = unsafe.objectFieldOffset (AbstractQueuedSynchronizer.class.getDeclaredField("tail")); waitStatusOffset = unsafe.objectFieldOffset (Node.class.getDeclaredField("waitStatus")); nextOffset = unsafe.objectFieldOffset (Node.class.getDeclaredField("next")); } catch (Exception ex) { throw new Error(ex); } } }
說明：屬性中包含了頭結點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