從ReentrantLock角度解析AQS

知了一笑發表於2023-04-14
ReentrantLockAQS

是它，是它，就是它，併發包的基石；

一、概述

閒來不卷，隨便聊一點。

一般情況下，大家系統中至少也是JDK8了，那想必對於JDK5加入的一系列功能並不陌生吧。那時候重點加入了java.util.concurrent併發包，我們簡稱為JUC。JUC下提供了很多併發程式設計實用的工具類，比如併發鎖lock、原子操作atomic、執行緒池操作Executor等等。下面，我對JUC做了整理，大致分為下面幾點：

基於JDK8，今天重點來聊下JUC併發包下的一個類，AbstractQueuedSynchronizer。

首先，淺顯的從名字上看，抽象的佇列同步器；實際上，這名字也跟它的作用如出一轍。抽象，即需要被繼承；佇列同步器，其內部維護了一個佇列，供執行緒入隊等待；最終實現多個執行緒訪問共享資源的功能。

二、原始碼解析

進入AbstractQueuedSynchronizer內部，需要掌握三個重要的屬性：

private transient volatile Node head;

private transient volatile Node tail;

private volatile int state;
  • head：標記等待佇列頭部節點。
  • tail：標記等待佇列尾部節點。
  • state：執行緒的鎖定狀態；state=0，表示資源未被上鎖；state>0，表示資源被上鎖

我們除錯AQS的原始碼，必須尋找一個原始碼除錯的切入點，我這裡用我們併發程式設計常用的Lock鎖作為除錯AQS的切入點，因為這是解決執行緒安全問題常用的手段之一。

2.1、原始碼的切入點

AQS的原始碼除錯，從Lock介面出發，JDK原始碼定義如下：

public interface Lock {

    void lock();

    void lockInterruptibly() throws InterruptedException;

    boolean tryLock();

    boolean tryLock(long time, TimeUnit unit) throws InterruptedException;

    void unlock();

    Condition newCondition();
}

從原始碼中看到，Lock是一個介面，所以該介面會有一些實現類，其中有一個實現類ReentrantLock，可重入鎖，想必大家都不會陌生。

2.2、ReentrantLock的lock方法

透過跟蹤原始碼可以看到，ReentrantLock#lock內部實現貌似比較簡單，只有簡短的一行程式碼

public void lock() {
    sync.lock();
}

其實內部是維護了一個Sync的抽象類，呼叫的是Sync的lock()方法。

abstract static class Sync extends AbstractQueuedSynchronizer {
    private static final long serialVersionUID = -5179523762034025860L;

    abstract void lock();

    final boolean nonfairTryAcquire(int acquires) {
        final Thread current = Thread.currentThread();
        int c = getState();
        if (c == 0) {
            if (compareAndSetState(0, acquires)) {
                setExclusiveOwnerThread(current);
                return true;
            }
        }
        else if (current == getExclusiveOwnerThread()) {
            int nextc = c + acquires;
            if (nextc < 0) // overflow
                throw new Error("Maximum lock count exceeded");
            setState(nextc);
            return true;
        }
        return false;
    }

    protected final boolean tryRelease(int releases) {
        int c = getState() - releases;
        if (Thread.currentThread() != getExclusiveOwnerThread())
            throw new IllegalMonitorStateException();
        boolean free = false;
        if (c == 0) {
            free = true;
            setExclusiveOwnerThread(null);
        }
        setState(c);
        return free;
    }

    protected final boolean isHeldExclusively() {
        return getExclusiveOwnerThread() == Thread.currentThread();
    }
    // ...
}

可以看到，Sync也是個抽象類，它有兩個實現類：NonfairSync和FairSync，這裡其實就引出了我們今天的主角，AbstractQueuedSynchronizer，Sync繼承了它。

static final class NonfairSync extends Sync {
    private static final long serialVersionUID = 7316153563782823691L;

    final void lock() {
        if (compareAndSetState(0, 1))
            setExclusiveOwnerThread(Thread.currentThread());
        else
            acquire(1);
    }

    protected final boolean tryAcquire(int acquires) {
        return nonfairTryAcquire(acquires);
    }
}

static final class FairSync extends Sync {
    private static final long serialVersionUID = -3000897897090466540L;

    final void lock() {
        acquire(1);
    }

    protected final boolean tryAcquire(int acquires) {
        final Thread current = Thread.currentThread();
        int c = getState();
        if (c == 0) {
            if (!hasQueuedPredecessors() &&
                compareAndSetState(0, acquires)) {
                setExclusiveOwnerThread(current);
                return true;
            }
        }
        else if (current == getExclusiveOwnerThread()) {
            int nextc = c + acquires;
            if (nextc < 0)
                throw new Error("Maximum lock count exceeded");
            setState(nextc);
            return true;
        }
        return false;
    }
}

下面我整理了這一系列類的UML圖

透過類圖可知，lock()方法最終呼叫的是ReentrantLock類下，內部類NonfairSync或FairSync的lock方法；對於這兩個類，前者叫非公平鎖，後者叫公平鎖。透過ReentrantLock的構造器可知，預設使用NonfairSync類。

public ReentrantLock() {
    sync = new NonfairSync();
}

從NonfairSync類的lock方法出發，引出第一個AQS下的方法compareAndSetState。

final void lock() {
    if (compareAndSetState(0, 1))
        setExclusiveOwnerThread(Thread.currentThread());
    else
        acquire(1);
}

從compareAndSetState方法的命名可以發現，就是比較並交換的意思，典型的CAS無鎖機制。

protected final boolean compareAndSetState(int expect, int update) {
    // See below for intrinsics setup to support this
    return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}

我們可以觀察到，這裡其實呼叫的是Unsafe類的compareAndSwapInt方法，傳入的expect為0，update為1；意思是如果當前值為0，那我就把值最終更新為1。

Unsafe這個類下面，發現好多方法都是用native這個關鍵詞進行修飾的（也包括compareAndSwapInt方法），用native關鍵詞修飾的方法，表示原生的方法；原生方法的實現並不是Java語言，最終實現是C/C++；這並不是本文的討論範圍。

回到AQS的compareAndSetState方法，返回值是boolean型別，true表示值更新為1成功，false表示不成功。這裡出現兩個分支，成功，走setExclusiveOwnerThread方法；不成功，走acquire方法。我們優先討論acquire方法。

2.3、AQS的acquire方法

先來看一下該方法的原始碼；

public final void acquire(int arg) {
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}

這裡的核心是兩個方法，tryAcquire方法和acquireQueued方法。首先會呼叫tryAcquire()方法，看方法命名是嘗試獲取；實際上這個方法確實在就在做一件事“嘗試獲取資源”。

protected boolean tryAcquire(int arg) {
    throw new UnsupportedOperationException();
}

不過AQS中的這個方法是protected修飾，並沒有去實現，僅僅只是預留了方法入口，後期需要由其子類去實現；這裡的子類就是上文中的NonfairSync類，該類的原始碼在上文中已經貼出。這段原始碼其實運用了我們常見的一個設計模式，“模板方法模式”。

2.4、NonfairSync的tryAcquire方法

NonfairSync的tryAcquire方法原始碼如下

protected final boolean tryAcquire(int acquires) {
    return nonfairTryAcquire(acquires);
}

這裡並沒有直接去實現tryAcquire方法，而是呼叫了Sync類下的nonfairTryAcquire方法。

final boolean nonfairTryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {
        if (compareAndSetState(0, acquires)) {
            setExclusiveOwnerThread(current);
            return true;
        }
    }
    else if (current == getExclusiveOwnerThread()) {
        int nextc = c + acquires;
        if (nextc < 0) // overflow
            throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
    }
    return false;
}

這裡有個getState方法，最終返回的是AQS中的state欄位，這個欄位就是多個執行緒搶佔的共享資源，所以這個欄位很重要；volatile關鍵字修飾，保證記憶體的可見性，int型別，對於ReentrantLock鎖而言，當state=0時，表示無鎖，當state>0時，表示資源已被執行緒鎖定。

下面分析下這段程式碼：

  • 如果state=0表示無鎖，透過cas去更新state的值，這裡更新為1。
  • 將持有鎖的執行緒更新為當前執行緒。
  • 如果上述cas未更新成功，或者state!=0，表示已上鎖。
  • 繼續判斷下持有鎖的執行緒如果是當前執行緒，state欄位做疊加，這裡表示ReentrantLock的含義，表示可重入鎖。
  • 最後，state!=0，持有鎖的執行緒也不是當前執行緒，表示不能對資源加鎖，返回false。

tryAcquire方法的判斷至此結束，不過最終的走向需要看它的返回值；返回true，表示當前執行緒搶佔到鎖，或者當前執行緒就是搶佔鎖的執行緒，直接重入，加鎖流程結束；返回false，表示沒有搶佔到鎖，流程繼續，這裡就引出下個話題，CLH執行緒等待佇列。

2.5、AQS的addWaiter方法

2.5.1、CLH佇列

首先我們來看一段原始碼中的註釋

The wait queue is a variant of a "CLH" (Craig, Landin, and Hagersten) lock queue. CLH locks are normally used for spinlocks

大致意思是：CLH佇列是由Craig、Landin、Hagersten這三位老哥名字的首字母疊加在一起命名的，它是一個等待佇列，它是一個變種佇列，用到了自旋。

這裡的資訊要抓住三點：等待佇列、變種佇列、自旋。

2.5.2、Node類

在解析addWaiter方法實現之前，就不得不提到一個內部類Node；addWaiter方法的入參是這個型別，所以先來看看這個類。原始碼如下：

static final class Node {
    
    static final Node SHARED = new Node();
    
    static final Node EXCLUSIVE = null;
   
    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() {
    }

    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;
    }
}

這裡先大致介紹下，每個屬性的意思：

  • SHARED：型別就是Node，表示共享模式。
  • EXCLUSIVE：型別也是Node，表示獨佔模式，這裡的ReentrantLock就是獨佔模式。
  • waitStatus：int型別，當前Node節點下，儲存的執行緒狀態。
  • CANCELLED：int型別，等於1，waitStatus屬性的值之一，表示節點被取消狀態。
  • SIGNAL：int型別，等於-1，waitStatus屬性的值之一，表示當前節點需要去喚醒下一個節點。
  • CONDITION：int型別，等於-2，waitStatus屬性的值之一，表示節點處於等待狀態。
  • PROPAGATE：int型別，等於-2，waitStatus屬性的值之一，表示下一個被獲取的物件應該要無條件傳播，該值僅在共享模式下使用。
  • prev：Node型別，指向佇列中當前節點的前一個節點。
  • next：Node型別，指向佇列中當前節點的下一個節點。
  • thread：儲存當前執行緒資訊。
  • nextWaiter：用來儲存節點的指標，不過會出現兩種情況；等待佇列中，會將該屬性的值設定成SHARED或者EXCLUSIVE，用來區分當前節點處於共享模式還是獨享模式；條件佇列中，用於存放下一個節點的指標，所以當是條件佇列的情況下，這個佇列是單向佇列。
  • isShared()：返回是否屬於共享模式，true表示共享模式，false表示獨享模式。
  • predecessor()：獲取當前節點的前一個節點。

另外，Node類還有兩個有參構造器：
從作者的註釋就能看出來，第一個構造器是在等待佇列的時，建立節點使用，第二個構造器是在條件佇列時，建立節點使用。

2.5.3、方法解析

private Node addWaiter(Node mode) {
    Node node = new Node(Thread.currentThread(), mode);
    Node pred = tail;
    if (pred != null) {
        node.prev = pred;
        if (compareAndSetTail(pred, node)) {
            pred.next = node;
            return node;
        }
    }
    enq(node);
    return node;
}

private Node enq(final Node node) {
    for (;;) {
        Node t = tail;
        if (t == null) { // Must initialize
            if (compareAndSetHead(new Node()))
                tail = head;
        } else {
            node.prev = t;
            if (compareAndSetTail(t, node)) {
                t.next = node;
                return t;
            }
        }
    }
}

其實這段方法是在建立Node物件，Node物件就是組成CLH佇列的基礎元素。

  • 建立一個Node物件，mode引數由上述的acquire()方法傳遞而來，可以看到傳入Node.EXCLUSIVE，表示獨佔模式。
  • 判斷隊尾有指向節點，剛建立的節點放入佇列的隊尾，並且透過cas將隊尾指標改成當前建立節點，最後返回當前建立節點。
  • 如果隊尾沒有指向節點，呼叫enq方法，做佇列的初始化操作。
  • 這裡出現了第一個自旋，enq方法是無限迴圈的，就像作者註釋的一樣，Must initialize，必須初始化。
  • 這裡先是重新new了一個新的node（也可以叫空節點），標記它為佇列頭。
  • 隨後再將addWaiter方法中建立的node，加入到佇列尾。

總結下addWaiter方法乾的事情：

  1. 建立一個節點，儲存當前執行緒，並標記獨佔模式。
  2. 判斷佇列是否為空，不為空，透過cas將儲存當前執行緒的node節點加入到對尾，並且對該節點做對尾標記。
  3. 佇列為空，透過自旋，做初始化操作。
  4. 初始化過後的佇列，佇列頭是一個空節點，佇列尾是儲存當前執行緒的節點。

2.6、AQS的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);
    }
}

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;
        } while (pred.waitStatus > 0);
        pred.next = node;
    } else {
        compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
    }
    return false;
}

private void cancelAcquire(Node node) {
    if (node == null)
        return;

    node.thread = null;

    Node pred = node.prev;
    while (pred.waitStatus > 0)
        node.prev = pred = pred.prev;

    Node predNext = pred.next;

    node.waitStatus = Node.CANCELLED;

    if (node == tail && compareAndSetTail(node, pred)) {
        compareAndSetNext(pred, predNext, null);
    } else {
        int ws;
        if (pred != head &&
            ((ws = pred.waitStatus) == Node.SIGNAL ||
             (ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) &&
            pred.thread != null) {
            Node next = node.next;
            if (next != null && next.waitStatus <= 0)
                compareAndSetNext(pred, predNext, next);
        } else {
            unparkSuccessor(node);
        }
        node.next = node; // help GC
    }
}

從這個方法看到，又是運用了無限迴圈，需要分兩個步驟去觀察：1.當前方法中的判斷，自己的上一個節點是否是頭部節點（頭部節點就是佔用資源的節點）；2.當前節點正式入佇列，並且被掛起。

2.6.1、acquireQueued方法中的判斷

當前節點的前一個節點是佇列頭部，意味著當前節點的前一個節點，就是持有資源的節點；當資源被釋放，當前節點會去嘗試爭奪鎖資源；如果拿到鎖資源，當前節點會被標記為佇列頭部節點，它的上個節點（老的頭部節點）會被置為null，需要被GC及時清除，所以作者在這裡新增了一個註釋：help GC；下圖就是描述了這個流程：

2.6.2、shouldParkAfterFailedAcquire方法實現

如果當前節點的上一個節點，並不是頭部節點；這裡就需要用到上述Node類中介紹的各種狀態欄位了；先來重點介紹下Node類中的兩個狀態屬性：

  • CANCELLED：int型別，等於1，waitStatus屬性的值之一，表示節點被取消。
  • SIGNAL：int型別，等於-1，waitStatus屬性的值之一，表示當前節點需要去喚醒下一個節點。

進入的shouldParkAfterFailedAcquire這個方法內部，該方法接受兩個引數：當前節點前一個節點和當前節點。首先，獲取上一個節點的waitStatus屬性，然後透過這個屬性做如下判斷：

  1. 如果狀態是SIGNAL（即等於-1），直接返回true，後續就會交給parkAndCheckInterrupt方法去將當前執行緒掛起。
  2. 如果不是SIGNAL，對於當前ReentrantLock而言，ws>0的操作是滿足的，所以下面的步驟就是當前節點一直往前尋找，跳過已被標記狀態為CANCELLED的節點，直到找到狀態是SIGNAL的節點，將該節點作為當前節點的上一個節點。也印證了SIGNAL狀態的解釋：當前節點的上一個節點是SIGNAL，那麼當前節點需要掛起，等待被喚醒。最後進入下個迴圈，直到上個節點狀態是SIGNAL，執行上面的第一步，返回true。

這裡可以想象成一個排隊去食堂打飯的場景，你在低頭玩手機前，跟你前面的同學說，我玩會手機，快到了叫我一下；結果你前面的同學嫌隊伍長走了（CANCELLED狀態），所以你只能繼續找他的上一個同學；直到有同學回答你，好的（該同學被標記SIGNAL狀態）；然後你就低頭玩手機，等待回答你“好的”的那個同學叫你。

  1. 最後compareAndSetWaitStatus方法其實不用看也知道，透過cas機制，將當前節點的上一個節點的waitStatus修改成SIGNAL狀態，這樣的話，當前節點才能被掛起，等待喚醒。

再來看下parkAndCheckInterrupt這個方法

private final boolean parkAndCheckInterrupt() {
    LockSupport.park(this);
    return Thread.interrupted();
}

// LockSupport#park
public static void park(Object blocker) {
    Thread t = Thread.currentThread();
    setBlocker(t, blocker);
    UNSAFE.park(false, 0L);
    setBlocker(t, null);
}

其中最終又是這個Unsafe類，透過它的原生方法park，去掛起當前執行緒，這裡就不展開贅述了。

2.7、資源上鎖總結

下面整理下從lock方法作為切入點，一系列的呼叫：

2.8、ReentrantLock的unlock方法

之前一直在講資源“上鎖”，那麼這個方法就是給資源解鎖。這裡給出重要的部分原始碼

// AQS中
public final boolean release(int arg) {
    if (tryRelease(arg)) {
        Node h = head;
        if (h != null && h.waitStatus != 0)
            unparkSuccessor(h);
        return true;
    }
    return false;
}

// AQS中
private void unparkSuccessor(Node node) {
    int ws = node.waitStatus;
    if (ws < 0)
        compareAndSetWaitStatus(node, ws, 0);
    Node s = node.next;
    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);
}

// ReentrantLock中
protected final boolean tryRelease(int releases) {
    int c = getState() - releases;
    if (Thread.currentThread() != getExclusiveOwnerThread())
        throw new IllegalMonitorStateException();
    boolean free = false;
    if (c == 0) {
        free = true;
        setExclusiveOwnerThread(null);
    }
    setState(c);
    return free;
}

2.9、ReentrantLock的tryRelease方法

在呼叫unlock方法去解鎖後，最終是呼叫AQS中的release方法去實現這個解鎖功能的；在該方法中，首先會呼叫ReentrantLock中的tryRelease方法，去做state狀態值的遞減操作。

  1. 首先，獲取state值（在AQS中有這個公共屬性，上文提到過），這裡是對當前state值減去1。
  2. 再判斷當前解鎖的執行緒與持有鎖的執行緒是不是同一個，不是的話，直接拋異常。所以t執行緒佔用鎖，只有t執行緒才能解鎖，解鈴還須繫鈴人。
  3. 最後判斷做完遞減的值是不是等於0，如果為0，將持有鎖的執行緒清空，更新state欄位為遞減值（這裡是0），最後返回true，代表鎖已經被釋放了。
  4. 如果不是0，更新state欄位為遞減值（不是0），也不會清空持有鎖的執行緒，意味著資源還是被執行緒加鎖中，最後返回false。

2.10、AQS的release方法

在tryRelease方法返回false的時候，release方法並不會做任何操作，直接就結束了，意味著解鎖並沒有完成；
但是在返回true的時候，具體分以下幾部操作：

  1. 拿到CLH佇列被標記頭部的節點。
  2. 判斷不是空（佇列不能是空的），並且頭部節點的等待狀態不是0，在這種情況下，它只能是-1（SIGNAL），所以是需要去喚醒下個節點的。
  3. 最後，呼叫AQS中的unparkSuccessor方法，去喚醒執行緒。

2.11、AQS的unparkSuccessor方法

上面說到了，這個方法主要是用來喚醒執行緒的，下面還是做一下具體的解析：

  1. 該方法傳參是一個Node節點，這裡傳入的是被標記佇列頭的節點（頭部節點是持有鎖資源的節點）。
  2. 拿到頭部節點的waitStatus狀態屬性，並且判斷小於0的情況下（該情況是waitStatus=-1），透過cas機制將頭部節點的狀態改為0，初始化狀態。
  3. 拿到頭部節點的下個節點，也就是真正意義上處於等待中的第一個節點。
  4. 它還是先判斷了這個拿到的節點是否為null，或者狀態大於0（亦或說判斷狀態等於1）；如果條件成立，說明頭節點的下個節點是空，或者下個節點被取消了。
  5. 如果第四個判斷條件滿足，從隊尾一直從後往前找，找到離頭節點最近的那個節點。
  6. 透過Unsafe類的unpark原生方法去喚醒上述找到的，距離頭部節點最近的未處於取消狀態下的節點。

2.12、資源解鎖總結

透過上面的描述可以發現，資源解鎖是相對簡單的；它只能被上鎖的執行緒去解鎖；透過遞減AQS內部維護的state屬性值，直到state減為0，表示資源已被解鎖；當資源被解鎖後，需要透過Unsafe的unpark方法，去喚醒CLH佇列中，被掛起的第一個節點上的執行緒。

2.13、公平鎖與非公平鎖的差異

在2.2中說過，當我們使用無參構造器建立一把“鎖”的時候，預設是使用NonfairSync這個內部類，也就是非公平鎖；但是在原始碼中發現ReentrantLock還存在一個有參構造器，引數是一個boolean型別；

public ReentrantLock(boolean fair) {
    sync = fair ? new FairSync() : new NonfairSync();
}

很明顯，這種方式就是將選擇權交給開發人員，當我們傳入true時，就會建立一把“公平鎖”。還是一樣，先來看下公平鎖的內部；

static final class FairSync extends Sync {
    private static final long serialVersionUID = -3000897897090466540L;

    final void lock() {
        acquire(1);
    }

    protected final boolean tryAcquire(int acquires) {
        final Thread current = Thread.currentThread();
        int c = getState();
        if (c == 0) {
            if (!hasQueuedPredecessors() &&
                compareAndSetState(0, acquires)) {
                setExclusiveOwnerThread(current);
                return true;
            }
        }
        else if (current == getExclusiveOwnerThread()) {
            int nextc = c + acquires;
            if (nextc < 0)
                throw new Error("Maximum lock count exceeded");
            setState(nextc);
            return true;
        }
        return false;
    }
}

從原始碼的角度，我們來看下，為什麼一個叫“非公平鎖”，另一個叫“公平鎖”？

其實不難發現，NonfairSync內部的lock方法，它是一上來就透過cas機制去搶佔state公共資源，搶不到才去執行acquire方法實現後續入佇列等一系列的操作；而這裡FairSync的lock方法，它是直接執行acquire方法，執行後續的操作。等於非公平鎖，會去多爭取一次資源，對於在CLH佇列中等待的執行緒，是“不公平”的。

除了lock方法存在差異之外，在tryAcquire方法中，也存在著不同。FairSync類中，會多執行hasQueuedPredecessors方法，它是AQS下的一個公用方法，下面具體看下這個方法；

public final boolean hasQueuedPredecessors() {
    Node t = tail;
    Node h = head;
    Node s;
    return h != t &&
        ((s = h.next) == null || s.thread != Thread.currentThread());
}

只有簡短的幾行，卻有很多種可能性，但是整個方法主要功能就是判斷當前執行緒是否需要入佇列：返回false，佇列為空，不對等待；返回true，佇列不是空，去排隊等待。下面需要重點講下這一行程式碼：return h != t && ((s = h.next) == null || s.thread != Thread.currentThread());

2.13.1、hasQueuedPredecessors返回false

返回false，情況也有兩種：1、h != t** **是false，2、h != t是true，並且 (s = h.next) == null 是false， s.thread != Thread.currentThread()是false。

第一種情況比較簡單，意思是頭結點和尾節點是同一個，說明佇列是空的，不需要排隊等待，所以直接返回false。

第二種情況，頭尾不是同一個節點，頭部節點的下個節點也不是空，並且頭部節點的下一個節點就是當前執行緒。
其實就可以理解為，前面的資源剛釋放，正好輪到當前執行緒來搶佔資源，這種情況相對較少。

2.13.2、hasQueuedPredecessors返回true

返回true，有兩種情況：1、h != t是true，並且 (s = h.next) == null 是true。2、h != t是true，並且 (s = h.next) == null 是false， s.thread != Thread.currentThread()是true。

1、這裡的頭尾不是同一個節點是必要滿足的條件，保證了佇列起碼不是空的。然後(s = h.next) == null 滿足是true，這裡解釋起來就必須回顧下enq初始化佇列這個方法。

private Node enq(final Node node) {
    for (;;) {
        Node t = tail;
        if (t == null) { // Must initialize
            if (compareAndSetHead(new Node()))
                tail = head;
        } else {
            node.prev = t;
            if (compareAndSetTail(t, node)) {
                t.next = node;
                return t;
            }
        }
    }
}

從這個方法可知，先是將節點的prev指向前一個節點，然後再透過cas修改尾部標識，最後再將前一個節點的next指向當前節點；因此AQS，入隊操作是非原子性的。

繼續回到判斷本身，頭部節點拿到鎖在執行；中間節點沒拿到鎖在入隊；此時頭部節點執行完後釋放鎖，當前節點嘗試不入隊拿鎖，但是中間執行緒已經在排隊了，但是還沒來得及執行t.next = node的操作，導致(s = h.next) == null 滿足，所以當前節點必須入隊，最終返回true。

2、滿足s.thread != Thread.currentThread()的情況，執行到這裡，可以明確佇列首先不是空，並且h.next != null，也就是頭節點之後還有其他節點，最後再判斷了下，s.thread != Thread.currentThread為true，也就是頭節點的下個節點並不是當前節點，既然如此，那隻能乖乖去佇列中排隊了，所以最終返回true。

三、業務運用

想必大家對於併發鎖並不陌生了，上文我也是透過ReentrantLock這個併發鎖為入口，一步步來解析AQS中的實現。所以這裡就不用ReentrantLock舉例，這裡換一個同步工具：CountDownLatch，它也是基於AQS來實現的。

CountDownLatch是透過一個計數器來實現的，初始值為執行緒的數量。每當一個執行緒完成了自己的任務，計數器的值就相應得減1。當計數器到達0時，表示所有的執行緒都已執行完畢,然後在等待的執行緒就可以恢復執行任務。

這個其實跟ReentrantLock思路差不多，一個是state初始值就是0，透過“上鎖”一步步疊加這個值；一個是state讓使用者自己設定初始值，透過執行緒呼叫，一步步遞減這個值。

CountDownLatch具體的運用情況如下：1、一個主執行緒中，需要開啟多個子執行緒，並且要在多個子執行緒執行完畢後，主執行緒才能繼續往下執行。2、透過多個執行緒一起執行，提高執行的效率。

下面，透過一個真實的業務場景，來進一步瞭解下CountDownLatch這個同步工具，具體是怎麼使用的。

現在有這麼一個介面，查詢使用者的詳情資訊；使用者資訊由五部分組成：1、使用者基本資訊；2、使用者影像資訊；3、使用者工商資訊；4、使用者賬戶資訊；5、使用者組織架構資訊；按照原本的邏輯是按照順序1-5這樣一步步查詢，最後組裝使用者VO物件，介面返回。但是這裡可以用上CountDownLatch這個工具類，申請五個執行緒，分別去查詢這五種資訊，提高介面效率。

/**
 * @author 往事如風
 * @version 1.0
 * @date 2023/4/11 18:10
 * @description：匯出報表
 */
@RestController
public class QueryController {

    @GetMapping("/query")
    public Result download() throws InterruptedException {
        ExecutorService executorService = Executors.newFixedThreadPool(5);
        // 模擬查詢資料
        List<String> row1 = CollUtil.newArrayList("aa", "bb", "cc", "dd");
        List<String> row2 = CollUtil.newArrayList("aa1", "bb1", "cc1", "dd1");
        List<String> row3 = CollUtil.newArrayList("aa2", "bb2", "cc2", "dd2");
        List<String> row4 = CollUtil.newArrayList("aa3", "bb3", "cc3", "dd3");
        List<String> row5 = CollUtil.newArrayList("aa4", "bb4", "cc4", "dd4");
        CountDownLatch count = new CountDownLatch(5);
        DataQuery d = new DataQuery();
        // 開始時間
        long start = System.currentTimeMillis();
        System.out.println("開始查詢資料。。。。");
        executorService.execute(() -> {
            System.out.println("查詢使用者基本資訊。。。。。。");
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
            d.setBaseInfo(row1);
            count.countDown();
        });
        executorService.execute(() -> {
            System.out.println("查詢使用者影像資訊。。。。。。");
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
            d.setImgInfo(row2);
            count.countDown();
        });
        executorService.execute(() -> {
            System.out.println("查詢使用者工商資訊。。。。。。");
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
            d.setBusinessInfo(row3);
            count.countDown();
        });
        executorService.execute(() -> {
            System.out.println("查詢使用者賬戶資訊。。。。。。");
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
            d.setAccountInfo(row4);
            count.countDown();
        });
        executorService.execute(() -> {
            System.out.println("查詢使用者組織架構資訊。。。。。。");
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
            d.setOrgInfo(row5);
            count.countDown();
        });
        // 阻塞：直到count的值減為0
        count.await();
        executorService.shutdown();
        // 結束時間
        long end = System.currentTimeMillis();
        System.out.println("查詢結束。。。。。");
        System.out.println("用時時間：" + (end - start));
        return Result.success(d);
    }

    @Data
    class DataQuery {
        private List<String> baseInfo;
        private List<String> imgInfo;
        private List<String> businessInfo;
        private List<String> accountInfo;
        private List<String> orgInfo;
    }
}

/*
控制檯輸出：
開始查詢資料。。。。
查詢使用者基本資訊。。。。。。
查詢使用者影像資訊。。。。。。
查詢使用者工商資訊。。。。。。
查詢使用者賬戶資訊。。。。。。
查詢使用者組織架構資訊。。。。。。
查詢結束。。。。。
用時時間：1017
*/

這段程式碼做了模擬查詢各種使用者資訊的操作，其中每個執行緒都暫停1秒，代表在查詢這五種資料；最終列印的用時時間是1017ms，說明這五個執行緒是同時進行的，大大提高了介面的效率。

四、寫在最後

AQS提供了一個FIFO佇列，這裡稱為CLH佇列，可以看成是一個用來實現同步鎖以及其他涉及到同步功能的核心元件，常見的有:ReentrantLock、CountDownLatch、Semaphore等。

AQS是一個抽象類，主要是透過繼承的方式來使用，它本身沒有實現任何的同步介面，僅僅是定義了同步狀態的獲取以及釋放的方法來提供自定義的同步元件。

可以這麼說，只要搞懂了AQS，那麼J.U.C中絕大部分的api都能輕鬆掌握。

本文主要提供了從ReentrantLock出發，解析了AQS中的各種公用的方法，如果需要知道其他類中怎麼去使用AQS中的方法，其實也只需要找到切入點，一步步除錯下去即可，不過，我想很多地方都是和ReentrantLock中一致的。

相關文章