死磕java concurrent包系列（二）基於ReentrantLock理解AQS同步佇列的細節和設計模式

接下來我們看詳細實現

基於ReetrantLock分析AQS獨佔鎖模式的實現

非公平鎖的獲取鎖

AQS的實現依賴於內部的同步佇列(就是一個由node構成的FIFO的雙向連結串列對列)來完成對同步狀態(state)的管理，當前執行緒獲取鎖失敗時，AQS會將該執行緒封裝成一個Node並將其加入同步佇列，同時會阻塞當前執行緒，當同步資源釋放時，又會將頭結點head中的執行緒喚醒，讓其嘗試獲取同步狀態。這裡從ReetrantLock入手分析AQS的具體實現，我們先以非公平鎖為例進行分析。

獲取鎖

來看ReetrantLock的原始碼：

//預設構造，建立非公平鎖NonfairSync
public ReentrantLock() {
    sync = new NonfairSync();
}
//根據傳入引數建立鎖型別
public ReentrantLock(boolean fair) {
    sync = fair ? new FairSync() : new NonfairSync();
}

//加鎖操作
public void lock() {
     sync.lock();
}

複製程式碼

這裡說明ReetrantLock預設構造方法就是構造一個非公平鎖，呼叫lock方法時候：

/**
 * 非公平鎖實現
 */
static final class NonfairSync extends Sync {
    //加鎖
    final void lock() {
        //執行CAS操作，本質就是CAS更新state：
        //判斷state是否為0，如果為0則把0更新為1，並返回true否則返回false
        if (compareAndSetState(0, 1))
       //成功則將獨佔鎖執行緒設定為當前執行緒  
          setExclusiveOwnerThread(Thread.currentThread());
        else
            //否則再次請求同步狀態
            acquire(1);
    }
}

複製程式碼

也就是說，通過CAS機制保證併發的情況下只有一個執行緒可以成功將state設定為1，獲取到鎖；

此時，其它執行緒在執行compareAndSetState時，因為state此時不是0，所以會失敗並返回false，執行acquire(1);

加入同步佇列

public final void acquire(int arg) {
    //再次嘗試獲取同步狀態
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}

複製程式碼

這裡傳入引數arg是state的值，因為要獲取鎖，而status為0時是釋放鎖，1則是獲取鎖，所以這裡一般傳遞引數為1，進入方法後首先會執行tryAcquire(1)方法，在前面分析過該方法在AQS中並沒有具體實現，而是交由子類實現，因此該方法是由ReetrantLock類內部類實現的

//NonfairSync類
static final class NonfairSync extends Sync {

    protected final boolean tryAcquire(int acquires) {
         return nonfairTryAcquire(acquires);
     }
 }
複製程式碼

假設有三個執行緒：執行緒1已經獲得到了鎖，執行緒2正在同步佇列中排隊，此時執行緒3執行lock方法嘗試獲取鎖的時，執行緒1正好釋放了鎖，將state更新為0，那麼執行緒3就可能線上程2還沒有被喚醒之前去獲取到這個鎖。

如果此時還沒有獲取到鎖（nonfairTryAcquire返回false），那麼接下來會把該執行緒封裝成node去同步佇列裡排隊，程式碼層面上執行的是acquireQueued(addWaiter(Node.EXCLUSIVE), arg)

ReetrantLock為獨佔鎖，所以傳入的引數為Node.EXCLUSIVE

private Node addWaiter(Node mode) {
    //將請求同步狀態失敗的執行緒封裝成結點
    Node node = new Node(Thread.currentThread(), mode);

    Node pred = tail;
    //如果是第一個結點加入肯定為空，跳過。
    //如果非第一個結點則直接執行CAS入隊操作，嘗試在尾部快速新增
    if (pred != null) {
        node.prev = pred;
        //使用CAS執行尾部結點替換，嘗試在尾部快速新增
        if (compareAndSetTail(pred, node)) {
            pred.next = node;
            return node;
        }
    }
    //如果第一次加入或者CAS操作沒有成功執行enq入隊操作
    enq(node);
    return node;
}
複製程式碼

其中tail是AQS的成員變數，指向隊尾(這點前面的我們分析過AQS維持的是一個雙向的連結串列結構同步佇列)，如果第一次獲取到鎖，AQS還沒有初始化，則為tail肯定為空，那麼將執行enq(node)操作，如果非第一個結點即tail指向不為null，直接嘗試執行CAS操作加入隊尾（再一次使用CAS操作實現執行緒安全），如果CAS操作失敗或第一次加入同步佇列還是會執行enq(node)，繼續看enq(node)：

private Node enq(final Node node) {
    //死迴圈
    for (;;) {
         Node t = tail;
         //如果佇列為null，即沒有頭結點
         if (t == null) { // Must initialize
             //建立並使用CAS設定頭結點
             if (compareAndSetHead(new Node()))
                 tail = head;
         } else {//隊尾新增新結點
             node.prev = t;
             if (compareAndSetTail(t, node)) {
                 t.next = node;
                 return t;
             }
         }
     }
}
複製程式碼

這個方法使用一個死迴圈進行CAS操作，可以解決多執行緒併發問題。這裡做了兩件事：

一是佇列不存在的建立新結點並初始化tail、head：使用compareAndSetHead設定頭結點，head和tail都指向head。

二是佇列已存在，則將新結點node新增到隊尾。

注意addWaiter和enq這兩個方法都存在同樣的程式碼將執行緒設定為同步佇列的隊尾：

             node.prev = t;
             if (compareAndSetTail(t, node)) {
                 t.next = node;
                 return t;
             }複製程式碼

這是因為，在多執行緒環境中，假設執行緒1、2、3、4同時執行addWaiter()方法入隊，而此時頭節點不為null，那麼他們會同時執行addWaiter中的compareAndSetTail方法將隊尾指向它，新增到隊尾。

但這個時候CAS操作保證只有一個可以成功，假設此時執行緒1成功新增到隊尾，那麼執行緒2、3、4執行CAS都會失敗，那麼執行緒2、3、4會在enq這個方法內部死迴圈執行compareAndSetTail方法將隊尾指向它，直到成功新增到隊尾為止。enq這個方法在內部對併發情況下進行補償。

自旋

回到之前的acquire()方法，新增到同步佇列後，結點就會進入一個自旋過程，自旋的意思就是原地轉圈圈：即結點都在觀察時機準備獲取同步狀態,自旋過程是在acquireQueued(addWaiter(Node.EXCLUSIVE), arg))方法中執行的，先看前半部分

final boolean acquireQueued(final Node node, int arg) {
    boolean failed = true;
    try {
        boolean interrupted = false;
        //自旋，死迴圈
        for (;;) {
            //獲取前結點
            final Node p = node.predecessor();
            當且僅當p為頭結點才嘗試獲取同步狀態,FIFO
            if (p == head && tryAcquire(arg)) {
                //此時當前node前驅節點為head且已經tryAcquire獲取到了鎖，正在執行了它的相關資訊
                //已經沒有任何用處了，所以現在需要考慮將它GC掉
                //將node設定為頭結點
                setHead(node);
                //清空原來頭結點的引用便於GC
                p.next = null; // help GC
                failed = false;
                return interrupted;
            }
            //如果前驅結點不是head，判斷是否掛起執行緒
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;       
        }
    } finally {
        if (failed)
            //最終都沒能獲取同步狀態，結束該執行緒的請求
            cancelAcquire(node);
    }
}
複製程式碼

//設定為頭結點
private void setHead(Node node) {
        head = node;
        //清空結點資料以便於GC
        node.thread = null;
        node.prev = null;
}
複製程式碼

死迴圈中，如果滿足了if (p == head && tryAcquire(arg))

如下圖，會執行sethead方法：

當然如果前驅結點不是head而它又沒有獲取到鎖，那麼執行如下：

//如果前驅結點不是head，判斷是否掛起執行緒
if (shouldParkAfterFailedAcquire(p, node) &&parkAndCheckInterrupt())

      interrupted = true;
}

private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
        //獲取當前結點的等待狀態
        int ws = pred.waitStatus;
        //如果為等待喚醒（SIGNAL）狀態則返回true
        if (ws == Node.SIGNAL)
            return true;
        //如果ws>0 則說明是結束狀態，
        //遍歷前驅結點直到找到沒有結束狀態的結點
        if (ws > 0) {
            do {
                node.prev = pred = pred.prev;
            } while (pred.waitStatus > 0);
            pred.next = node;
        } else {
            //如果ws小於0又不是SIGNAL狀態，
            //則將其設定為SIGNAL狀態，代表該結點的執行緒正在等待喚醒。
            compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
        }
        return false;
    }

private final boolean parkAndCheckInterrupt() {
        //將當前執行緒掛起,執行緒會阻塞住
        LockSupport.park(this);
        //獲取執行緒中斷狀態,interrupted()是判斷當前中斷狀態，
        //並非中斷執行緒，因此可能true也可能false,並返回
        return Thread.interrupted();
}

複製程式碼

這段程式碼有個設計比較好的點：

通常我們在設計佇列時，我們需要考慮如何最大化的減少後續排隊節點對於CPU的消耗，而在AQS中，只要當前節點的前驅節點不是頭結點，再把當前節點加到佇列後就會執行LockSupport.park(this);將當前執行緒掛起，這樣可以最大程度減少CPU消耗。

總結：

是不是還是有點一頭霧水？

沒關係，為了方便理解：我們假設ABC三個執行緒現在同時去獲取鎖，A首先獲取到鎖後一直不釋放，BC加入佇列。那麼對於AQS的同步佇列結構是如何變化的呢？

1、A直接獲取到鎖:

程式碼執行路徑：

(ReetranLock.lock()-> compareAndSetState(0, 1) -> setExclusiveOwnerThread(Thread.currentThread())

此時AQS結構還沒有初始化：

2、B嘗試獲取鎖：

因為A存在把state設定為1，所以B獲取鎖失敗，進行入隊操作加入同步佇列，入隊時發現AQS還沒有初始化(AQS中的tail為null)，會在入隊前初始化程式碼在enq方法的死迴圈中：

初始化之後改變tail的prev指向，把自己加到隊尾：

接著會執行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);
    }
}複製程式碼

第一次執行：發現自己前序節點是head節點，於是乎再次嘗試獲取鎖，獲取失敗後再shouldParkAfterFailedAcquire方法中把前序節點設定為Singal狀態

第二次執行：再次嘗試獲取鎖，但因為前序節點是Signal狀態了,所以執行parkAndCheckInterrupt把自己休眠起來進行自旋

3、C嘗試獲取鎖：

C獲取鎖和B完全一樣，不同的是它的前序節點是B，所以它並不會一直嘗試獲取鎖，只會呆在B後面park住

AQS通過最簡單的CAS和LockSupport的park，設計出了高效的佇列模型和機制：

1、AQS結構其實是在第二個執行緒獲取鎖的時候再初始化的，就是lazy-Init的思想，最大程度減少不必要的程式碼執行的開銷

2、為了最大程度上提升效率，儘量避免執行緒間的通訊，採用了雙向連結串列的Node結構去儲存執行緒

3、為了最大程度上避免CPU上下文切換執行的消耗，在設計排隊執行緒時，只有頭結點的下一個的執行緒在一直重複執行獲取鎖，佇列後面的執行緒會通過LockSupport進行休眠。

非公平鎖的釋放鎖

上程式碼：

//ReentrantLock類的unlock
public void unlock() {
    sync.release(1);
}

//AQS類的release()方法
public final boolean release(int arg) {
    //嘗試釋放鎖
    if (tryRelease(arg)) {
        Node h = head;
        if (h != null && h.waitStatus != 0)
            //喚醒後繼結點的執行緒
            unparkSuccessor(h);
        return true;
    }
    return false;
}

//ReentrantLock類中的內部類Sync實現的tryRelease(int releases) 
protected final boolean tryRelease(int releases) {

      int c = getState() - releases;
      if (Thread.currentThread() != getExclusiveOwnerThread())
          throw new IllegalMonitorStateException();
      boolean free = false;
      //判斷狀態是否為0，如果是則說明已釋放同步狀態
      if (c == 0) {
          free = true;
          //設定Owner為null
          setExclusiveOwnerThread(null);
      }
      //設定更新同步狀態
      setState(c);
      return free;
  }

複製程式碼

一句話總結：釋放鎖首先就是把volatile型別的變數state減1。state從1變成0.

unparkSuccessor(h)的作用的喚醒後續的節點：

private void unparkSuccessor(Node node) {
    //這裡，node是head節點。
    int ws = node.waitStatus;
    if (ws < 0)//置零當前執行緒所在的結點狀態，允許失敗。
        compareAndSetWaitStatus(node, ws, 0);

    Node s = node.next;//找到下一個需要喚醒的結點s
    if (s == null || s.waitStatus > 0) {//如果為空或已取消
        s = null;
        for (Node t = tail; t != null && t != node; t = t.prev)
            if (t.waitStatus <= 0)//從這裡可以看出，<=0的結點，都是還有效的結點。
                s = t;
    }
    if (s != null)
        LockSupport.unpark(s.thread);//喚醒
}

複製程式碼

從程式碼執行操作來看，這裡主要作用是用unpark()喚醒同步佇列中最前邊未放棄執行緒(也就是狀態為CANCELLED的執行緒結點s)。此時，回憶前面分析進入自旋的函式acquireQueued()，s結點的執行緒被喚醒後，會進入acquireQueued()函式的if (p == head && tryAcquire(arg))的判斷，然後s把自己設定成head結點，表示自己已經獲取到資源了，最終acquire()也返回了，這就是獨佔鎖釋放的過程。 

總結

回到之前的圖：A B C三個執行緒獲取鎖，A已經獲取到了鎖，BC在佇列裡面，此時A釋放鎖

執行b.unpark，B被喚醒後繼續執行

if (p == head && tryAcquire(arg))
複製程式碼

因為B的前序節點是head，所以會執行tryAcquire方法嘗試獲取鎖，獲取到鎖之後執行setHead方法把自己設定為頭節點，並且把之前的頭結點也就是上圖中的new Node()設定為null以便於GC：

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)) {
                //獲取到鎖之後將當前node設定為頭結點 head指向當前節點node
                setHead(node);
                //p.next就是之前的頭結點，它沒有用了，所以把它gc掉
                p.next = null; // help GC
                failed = false;
                return interrupted;
            }
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}複製程式碼

總之，AQS內部有一個同步佇列，執行緒獲取同步狀態失敗之後會被封裝成node通過park進行自旋，而在釋放同步狀態時，通過unpark進行喚醒後面一個執行緒，讓後面執行緒得以繼續獲取鎖。

ReetrantLock中的公平鎖

瞭解完ReetrantLock中非公平鎖的實現後，我們再來看看公平鎖。與非公平鎖不同的是，在獲取鎖的時，公平鎖的獲取順序是完全遵循時間上的FIFO規則，也就是說先請求的執行緒一定會先獲取鎖，後來的執行緒肯定需要排隊。

下面比較一下公平鎖和非公平鎖lock方法： 

再比較一下公平鎖和非公平鎖lock方法：tryAcquire方法：

唯一的差別就是hasQueuedPredecessors()判斷同步佇列是否存在結點，這就是非公平鎖與公平鎖最大的區別，即公平鎖線上程請求到來時先會判斷同步佇列是否存在結點，如果存在先執行同步佇列中的結點執行緒，當前執行緒將封裝成node加入同步佇列等待。而非公平鎖呢，當執行緒請求到來時，不管同步佇列是否存線上程結點，直接上去嘗試獲取同步狀態，獲取成功直接訪問共享資源，但請注意在絕大多數情況下，非公平鎖才是我們理想的選擇，畢竟從效率上來說非公平鎖總是勝於公平鎖。

總結

以上便是ReentrantLock的內部實現原理，這裡我們簡單進行小結，重入鎖ReentrantLock，是一個基於AQS併發框架的併發控制類，其內部實現了3個類，分別是Sync、NoFairSync以及FairSync類，其中Sync繼承自AQS，實現了釋放鎖的模板方法tryRelease(int)，而NoFairSync和FairSync都繼承自Sync，實現各種獲取鎖的方法tryAcquire(int)。

ReentrantLock的所有方法實現幾乎都間接呼叫了這3個類，因此當我們在使用ReentrantLock時，大部分使用都是在間接呼叫AQS同步器中的方法。

AQS在設計時將效能優化到了極致，具體體現在同步佇列的park和unpark，初始化AQS時的懶載入，以及執行緒之間通過Node這樣的資料結構從而避免執行緒間通訊造成的額外開銷，這種由釋放鎖的執行緒主動喚醒後續執行緒的方式也是我們再實際過程中可以借鑑的。

AQS還不止於同步佇列，接下來我們會繼續探討AQS的條件佇列