逐行分析AQS源碼(3)——共享鎖的獲取與釋放

前言

前面兩篇我們以ReentrantLock爲例瞭解了AQS獨佔鎖的獲取與釋放，本篇我們來看看共享鎖。由於AQS對於共享鎖與獨佔鎖的實現框架比較類似，因此如果你搞定了前面的獨佔鎖模式，則共享鎖也就很容易弄懂了。

系列文章目錄

共享鎖與獨佔鎖的區別

共享鎖與獨佔鎖最大的區別在於，獨佔鎖是獨佔的，排他的，因此在獨佔鎖中有一個exclusiveOwnerThread屬性，用來記錄當前持有鎖的線程。當獨佔鎖已經被某個線程持有時，其他線程只能等待它被釋放後，才能去爭鎖，並且同一時刻只有一個線程能爭鎖成功。

而對於共享鎖而言，由於鎖是可以被共享的，因此它可以被多個線程同時持有。換句話說，如果一個線程成功獲取了共享鎖，那麼其他等待在這個共享鎖上的線程就也可以嘗試去獲取鎖，並且極有可能獲取成功。

共享鎖的實現和獨佔鎖是對應的，我們可以從下面這張表中看出：

獨佔鎖	共享鎖
tryAcquire(int arg)	tryAcquireShared(int arg)
tryAcquireNanos(int arg, long nanosTimeout)	tryAcquireSharedNanos(int arg, long nanosTimeout)
acquire(int arg)	acquireShared(int arg)
acquireQueued(final Node node, int arg)	doAcquireShared(int arg)
acquireInterruptibly(int arg)	acquireSharedInterruptibly(int arg)
doAcquireInterruptibly(int arg)	doAcquireSharedInterruptibly(int arg)
doAcquireNanos(int arg, long nanosTimeout)	doAcquireSharedNanos(int arg, long nanosTimeout)
release(int arg)	releaseShared(int arg)
tryRelease(int arg)	tryReleaseShared(int arg)
-	doReleaseShared()

可以看出，除了最後一個屬於共享鎖的doReleaseShared()方法沒有對應外，其他的方法，獨佔鎖和共享鎖都是一一對應的。

事實上，其實與doReleaseShared()對應的獨佔鎖的方法應當是unparkSuccessor(h)，只是doReleaseShared()邏輯不僅僅包含了unparkSuccessor(h)，還包含了其他操作，這一點我們下面分析源碼的時候再看。

另外，尤其需要注意的是，在獨佔鎖模式中，我們只有在獲取了獨佔鎖的節點釋放鎖時，纔會喚醒後繼節點——這是合理的，因爲獨佔鎖只能被一個線程持有，如果它還沒有被釋放，就沒有必要去喚醒它的後繼節點。

然而，在共享鎖模式下，當一個節點獲取到了共享鎖，我們在獲取成功後就可以喚醒後繼節點了，而不需要等到該節點釋放鎖的時候，這是因爲共享鎖可以被多個線程同時持有，一個鎖獲取到了，則後繼的節點都可以直接來獲取。因此，在共享鎖模式下，在獲取鎖和釋放鎖結束時，都會喚醒後繼節點。 這一點也是doReleaseShared()方法與unparkSuccessor(h)方法無法直接對應的根本原因所在。

共享鎖的獲取

public final void acquireShared(int arg) {
    if (tryAcquireShared(arg) < 0)
        doAcquireShared(arg);
}

我們拿它和獨佔鎖模式對比一下：

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

這兩者的結構看上去似乎有點差別，但事實上是一樣的，只不過是共享鎖模式下，將與addWaiter(Node.EXCLUSIVE)對應的addWaiter(Node.SHARED)，以及selfInterrupt()操作全部移到了doAcquireShared方法內部，這一點我們在下面分析doAcquireShared方法時就一目瞭然了。

不過這裏先插一句，相對於獨佔的鎖的tryAcquire(int arg)返回boolean類型的值，共享鎖的tryAcquireShared(int acquires)返回的是一個整型值：

• 如果該值小於0，則代表當前線程獲取共享鎖失敗
• 如果該值大於0，則代表當前線程獲取共享鎖成功，並且接下來其他線程嘗試獲取共享鎖的行爲很可能成功
• 如果該值等於0，則代表當前線程獲取共享鎖成功，但是接下來其他線程嘗試獲取共享鎖的行爲會失敗

因此，只要該返回值大於等於0，就表示獲取共享鎖成功。

acquireShared中的tryAcquireShared方法由具體的子類負責實現，這裏我們暫且不表。

接下來我們看看doAcquireShared方法，它對應於獨佔鎖的acquireQueued，兩者其實很類似，我們把它們相同的部分註釋掉，只看不同的部分：

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);
    }*/
}

關於上面的if部分，獨佔鎖對應的acquireQueued方法爲：

if (p == head && tryAcquire(arg)) {
    setHead(node);
    p.next = null; // help GC
    failed = false;
    return interrupted;
}

因此，綜合來看，這兩者的邏輯僅有兩處不同：

1. addWaiter(Node.EXCLUSIVE) -> addWaiter(Node.SHARED)
2. setHead(node) -> setHeadAndPropagate(node, r)

這裏第一點不同就是獨佔鎖的acquireQueued調用的是addWaiter(Node.EXCLUSIVE)，而共享鎖調用的是addWaiter(Node.SHARED)，表明了該節點處於共享模式，這兩種模式的定義爲：

/** Marker to indicate a node is waiting in shared mode */
static final Node SHARED = new Node();
/** Marker to indicate a node is waiting in exclusive mode */
static final Node EXCLUSIVE = null;

該模式被賦值給了節點的nextWaiter屬性：

Node(Thread thread, Node mode) {     // Used by addWaiter
    this.nextWaiter = mode;
    this.thread = thread;
}

我們知道，在條件隊列中，nextWaiter是指向條件隊列中的下一個節點的，它將條件隊列中的節點串起來，構成了單鏈表。但是在sync queue隊列中，我們只用prev,next屬性來串聯節點，形成雙向鏈表，nextWaiter屬性在這裏只起到一個標記作用，不會串聯節點，這裏不要被Node SHARED = new Node()所指向的空節點迷惑，這個空節點並不屬於sync queue，不代表任何線程，它只起到標記作用，僅僅用作判斷節點是否處於共享模式的依據：

// Node#isShard()
final boolean isShared() {
    return nextWaiter == SHARED;
}

這裏的第二點不同就在於獲取鎖成功後的行爲，對於獨佔鎖而言，是直接調用了setHead(node)方法，而共享鎖調用的是setHeadAndPropagate(node, r)：

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

在該方法內部我們不僅調用了setHead(node)，還在一定條件下調用了doReleaseShared()來喚醒後繼的節點。這是因爲在共享鎖模式下，鎖可以被多個線程所共同持有，既然當前線程已經拿到共享鎖了，那麼就可以直接通知後繼節點來拿鎖，而不必等待鎖被釋放的時候再通知。

關於這個doReleaseShared方法，我們到下面分析鎖釋放的時候再看。

共享鎖的釋放

我們使用releaseShared(int arg)方法來釋放共享鎖：

public final boolean releaseShared(int arg) {
    if (tryReleaseShared(arg)) {
        doReleaseShared();
        return true;
    }
    return false;
}

該方法對應於獨佔鎖的release(int arg)方法：

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

在獨佔鎖模式下，由於頭節點就是持有獨佔鎖的節點，在它釋放獨佔鎖後，如果發現自己的waitStatus不爲0，則它將負責喚醒它的後繼節點。

在共享鎖模式下，頭節點就是持有共享鎖的節點，在它釋放共享鎖後，它也應該喚醒它的後繼節點，但是值得注意的是，我們在之前的setHeadAndPropagate方法中可能已經調用過該方法了，也就是說它可能會被同一個頭節點調用兩次，也有可能在我們從releaseShared方法中調用它時，當前的頭節點已經易主了，下面我們就來詳細看看這個方法：

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

該方法可能是共享鎖模式最難理解的方法了，在看該方法時，我們需要明確以下幾個問題：

(1) 該方法有幾處調用？

該方法有兩處調用，一處在acquireShared方法的末尾，當線程成功獲取到共享鎖後，在一定條件下調用該方法；一處在releaseShared方法中，當線程釋放共享鎖的時候調用。

(2) 調用該方法的線程是誰？

在獨佔鎖中，只有獲取了鎖的線程才能調用release釋放鎖，因此調用unparkSuccessor(h)喚醒後繼節點的必然是持有鎖的線程，該線程可看做是當前的頭節點(雖然在setHead方法中已經將頭節點的thread屬性設爲了null，但是這個頭節點曾經代表的就是這個線程)

在共享鎖中，持有共享鎖的線程可以有多個，這些線程都可以調用releaseShared方法釋放鎖；而這些線程想要獲得共享鎖，則它們必然曾經成爲過頭節點，或者就是現在的頭節點。因此，如果是在releaseShared方法中調用的doReleaseShared，可能此時調用方法的線程已經不是頭節點所代表的線程了，頭節點可能已經被易主好幾次了。

(3) 調用該方法的目的是什麼？

無論是在acquireShared中調用，還是在releaseShared方法中調用，該方法的目的都是在當前共享鎖是可獲取的狀態時，喚醒head節點的下一個節點。這一點看上去和獨佔鎖似乎一樣，但是它們的一個重要的差別是——在共享鎖中，當頭節點發生變化時，是會回到循環中再立即喚醒head節點的下一個節點的。也就是說，在當前節點完成喚醒後繼節點的任務之後將要退出時，如果發現被喚醒後繼節點已經成爲了新的頭節點，則會立即觸發喚醒head節點的下一個節點的操作，如此周而復始。

(4) 退出該方法的條件是什麼

該方法是一個自旋操作(for(;;))，退出該方法的唯一辦法是走最後的break語句：

if (h == head)   // loop if head changed
    break;

即，只有在當前head沒有易主時，纔會退出，否則繼續循環。
這個怎麼理解呢？
爲了說明問題，這裏我們假設目前sync queue隊列中依次排列有

dummy node -> A -> B -> C -> D

現在假設A已經拿到了共享鎖，則它將成爲新的dummy node，

dummy node (A) -> B -> C -> D

此時，A線程會調用doReleaseShared，我們寫做doReleaseShared[A]，在該方法中將喚醒後繼的節點B，它很快獲得了共享鎖，成爲了新的頭節點：

dummy node (B) -> C -> D

此時，B線程也會調用doReleaseShared，我們寫做doReleaseShared[B]，在該方法中將喚醒後繼的節點C，但是別忘了，在doReleaseShared[B]調用的時候，doReleaseShared[A]還沒運行結束呢，當它運行到if(h == head)時，發現頭節點現在已經變了，所以它將繼續回到for循環中，與此同時，doReleaseShared[B]也沒閒着，它在執行過程中也進入到了for循環中。。。

由此可見，我們這裏形成了一個doReleaseShared的“調用風暴”，大量的線程在同時執行doReleaseShared，這極大地加速了喚醒後繼節點的速度，提升了效率，同時該方法內部的CAS操作又保證了多個線程同時喚醒一個節點時，只有一個線程能操作成功。

那如果這裏doReleaseShared[A]執行結束時，節點B還沒有成爲新的頭節點時，doReleaseShared[A]方法不就退出了嗎？是的，但即使這樣也沒有關係，因爲它已經成功喚醒了線程B，即使doReleaseShared[A]退出了，當B線程成爲新的頭節點時，doReleaseShared[B]就開始執行了，它也會負責喚醒後繼節點的，這樣即使變成這種每個節點只喚醒自己後繼節點的模式，從功能上講，最終也可以實現喚醒所有等待共享鎖的節點的目的，只是效率上沒有之前的“調用風暴”快。

由此我們知道，這裏的“調用風暴”事實上是一個優化操作，因爲在我們執行到該方法的末尾的時候，unparkSuccessor基本上已經被調用過了，而由於現在是共享鎖模式，所以被喚醒的後繼節點極有可能已經獲取到了共享鎖，成爲了新的head節點，當它成爲新的head節點後，它可能還是要在setHeadAndPropagate方法中調用doReleaseShared喚醒它的後繼節點。

明確了上面幾個問題後，我們再來詳細分析這個方法，它最重要的部分就是下面這兩個if語句：

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很好理解，如果當前ws值爲Node.SIGNAL，則說明後繼節點需要喚醒，這裏採用CAS操作先將Node.SIGNAL狀態改爲0，這是因爲前面講過，可能有大量的doReleaseShared方法在同時執行，我們只需要其中一個執行unparkSuccessor(h)操作就行了，這裏通過CAS操作保證了unparkSuccessor(h)只被執行一次。

比較難理解的是第二個else if，首先我們要弄清楚ws啥時候爲0，一種是上面的compareAndSetWaitStatus(h, Node.SIGNAL, 0)會導致ws爲0，但是很明顯，如果是因爲這個原因，則它是不會進入到else if語句塊的。所以這裏的ws爲0是指當前隊列的最後一個節點成爲了頭節點。爲什麼是最後一個節點呢，因爲每次新的節點加進來，在掛起前一定會將自己的前驅節點的waitStatus修改成Node.SIGNAL的。(對這一點不理解的看這裏)

其次，compareAndSetWaitStatus(h, 0, Node.PROPAGATE)這個操作什麼時候會失敗？既然這個操作失敗，說明就在執行這個操作的瞬間，ws此時已經不爲0了，說明有新的節點入隊了，ws的值被改爲了Node.SIGNAL，此時我們將調用continue，在下次循環中直接將這個剛剛新入隊但準備掛起的線程喚醒。

這裏我們複習一下新節點入隊的過程，在發現新節點的前驅不是head節點的時候，它將調用shouldParkAfterFailedAcquire：

private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
    int ws = pred.waitStatus;
    if (ws == Node.SIGNAL)
        /*
         * This node has already set status asking a release
         * to signal it, so it can safely park.
         */
        return true;
    if (ws > 0) {
        /*
         * Predecessor was cancelled. Skip over predecessors and
         * indicate retry.
         */
        do {
            node.prev = pred = pred.prev;
        } while (pred.waitStatus > 0);
        pred.next = node;
    } else {
        /*
         * 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.
         */
        compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
    }
    return false;
}

由於前驅節點的ws值現在還爲0，新節點將會把它改爲Node.SIGNAL，但修改後，該方法返回的是false，也就是說線程不會立即掛起，而是回到上層再嘗試一次搶鎖：

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;
                }
            }
            // shouldParkAfterFailedAcquire的返回處
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}

當我們再次回到for(;;)循環中，由於此時當前節點的前驅節點已經成爲了新的head，所以它可以參與搶鎖，由於它搶的是共享鎖，所以大概率它是搶的到的，所以極有可能它不會被掛起。這有可能導致在上面的doReleaseShared調用unparkSuccessor方法unpark了一個並沒有被park的線程。然而，這一操作是被允許的，當我們unpark一個並沒有被park的線程時，該線程在下一次調用park方法時就不會被掛起，而這一行爲是符合我們的場景的——因爲當前的共享鎖處於可獲取的狀態，後繼的線程應該直接來獲取鎖，不應該被掛起。

事實上，我個人認爲：

else if (ws == 0 && !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
    continue;  // loop on failed CAS

這一段是完全沒有必要的，網上有很多博客解釋說這裏將節點的狀態設置成Node.PROPAGATE是爲了“確保將共享狀態向後傳播”，其實不然，因爲這個CAS操作能成功通常是因爲當前節點已經是頭節點了，而且後面沒有新的節點入隊，所以並沒有向後傳播的意義，而當新的節點到來時，首先新的節點的前驅就是頭節點，因此基本不會掛起，退一步講，就算它搶鎖失敗進入shouldParkAfterFailedAcquire了，由於shouldParkAfterFailedAcquire的最後一個else對待waitStatus的值爲0和爲Node.PROPAGATE的處理是一樣的，所以這裏的compareAndSetWaitStatus(h, 0, Node.PROPAGATE)也沒有必要。

所以個人認爲，這裏的compareAndSetWaitStatus(h, 0, Node.PROPAGATE)的作用更多的是在於檢測當前有沒有恰好準備要掛起的節點，如果有（即CAS如果失敗了），則無論那個要掛起的節點將來會不會執行park操作，都一律先執行一次unpark, 阻止該線程的掛起。

總結

• 共享鎖的調用框架和獨佔鎖很相似，它們最大的不同在於獲取鎖的邏輯——共享鎖可以被多個線程同時持有，而獨佔鎖同一時刻只能被一個線程持有。
• 由於共享鎖同一時刻可以被多個線程持有，因此當頭節點獲取到共享鎖時，可以立即喚醒後繼節點來爭鎖，而不必等到釋放鎖的時候。因此，共享鎖觸發喚醒後繼節點的行爲可能有兩處，一處在當前節點成功獲得共享鎖後，一處在當前節點釋放共享鎖後。

（完）

系列文章目錄