JUC 公平鎖釋放機制深度解析：從 unlock() 到 unparkSuccessor() 的完整鏈路

繼上篇剖析公平鎖獲取流程後，本文聚焦 公平鎖釋放過程。釋放鎖雖相對簡單，但涉及狀態更新、線程喚醒、CLH 隊列維護等關鍵環節，是理解 AQS 同步器核心機制的另一半拼圖。基於 JDK 1.7.0_40 源碼，我們逐層拆解 unlock() → release() → tryRelease() → unparkSuccessor() 的完整調用鏈。

類結構回顧：ReentrantLock、Sync 與 AQS 的關係

public class ReentrantLock implements Lock, Serializable {
    private final Sync sync;              // 組合關係：持有同步器實例
    
    abstract static class Sync extends AbstractQueuedSynchronizer { // Sync 繼承 AQS
        // FairSync / NonfairSync 繼承 Sync
    }
}

sync 是 ReentrantLock 的成員對象，Sync 繼承 AbstractQueuedSynchronizer (AQS)。公平鎖對應 FairSync，非公平鎖對應 NonfairSync。

釋放鎖四部曲：逐層拆解

1. unlock()：入口方法

public void unlock() {
    sync.release(1); // 委託給 AQS 的 release()
}

• 參數 1 表示「釋放一個鎖許可」。因為 ReentrantLock 可重入，同一線程每獲取一次鎖狀態 +1，釋放時 -1
• 僅做委託，核心邏輯在 AQS 與 Sync 中

2. release(int arg)：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;
}

• 模板方法模式：tryRelease() 由子類（Sync）實現具體釋放邏輯
• 釋放成功（返回 true）且隊列非空（head != null）且頭節點狀態非 0，則喚醒後繼線程

3. tryRelease(int releases)：Sync 核心邏輯（公平/非公平共用）

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;                             // 返回是否完全釋放
}

• 權限檢查：只有鎖持有者才能釋放，否則拋 IllegalMonitorStateException
• 狀態更新：state 遞減，歸零則標記為完全釋放（free=true）並清除 exclusiveOwnerThread
• getState()/setState() 操作 AQS 的 volatile int state；getExclusiveOwnerThread()/setExclusiveOwnerThread() 來自父類 AbstractOwnableSynchronizer

4. unparkSuccessor(Node node)：喚醒後繼線程

private void unparkSuccessor(Node node) {
    int ws = node.waitStatus;
    if (ws < 0)                              // 狀態為負（SIGNAL/CONDITION/PROPAGATE）
        compareAndSetWaitStatus(node, ws, 0); // 嘗試重置為 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);        // 喚醒線程
}

• 狀態清理：頭節點 waitStatus 若為負值（通常是 SIGNAL=-1），CAS 重置為 0
• 後繼查找：優先取 node.next；若無效（空或 CANCELLED=1），從 tail 向前遍歷 prev 指針找首個 waitStatus <= 0 的節點（應對取消/中斷導致的間隙）
• 線程喚醒：調用 LockSupport.unpark(thread)，使線程從 park() 恢復運行

CLH 隊列節點狀態機（waitStatus 詳解）

釋放流程時序圖解

Thread A (持有鎖)                    CLH 隊列                    Thread B (等待中)
    │                                  │                            │
    ├─ unlock()                        │                            │
    │                                  │                            │
    ├─ release(1)                      │                            │
    │   ├─ tryRelease(1) → true        │                            │
    │   │   state: 1 → 0               │                            │
    │   │   owner: A → null            │                            │
    │   │                              │                            │
    │   ├─ head.waitStatus != 0        │                            │
    │   ├─ unparkSuccessor(head)       │                            │
    │   │   ├─ CAS head.waitStatus→0   │                            │
    │   │   ├─ 找後繼節點 (B)          │                            │
    │   │   └─ LockSupport.unpark(B)   │                            │
    │   │                              │                            │
    │   │                              ├─ park() 返回               │
    │   │                              │                            │
    │   │                              ├─ acquireQueued() 重試     │
    │   │                              ├─ tryAcquire(1) → true     │
    │   │                              ├─ setHead(B)               │
    │   │                              └─ 獲得鎖，繼續執行         │
    │                                  │                            │
    └─ 返回                            │                            │

關鍵設計亮點總結

1. 模板方法解耦：AQS release() 定義骨架，Sync.tryRelease() 實現細節，支持獨占/共享多種模式
2. 狀態機驅動：waitStatus 作為協議標誌，無需額外同步即可協調線程喚醒
3. 容錯的後繼查找：從尾部反向掃描機制，優雅處理節點取消導致的 next 指針失效
4. 輕量級阻塞原語：LockSupport.park/unpark 替代 Object.wait/notify，無需持有監視器鎖，性能更優

公平鎖釋放過程雖比獲取簡單，但蘊含了 AQS 同步器設計的精髓：狀態原子更新 + CLH 隊列維護 + LockSupport 線程阻塞/喚醒 三位一體。理解這一流程，對排查死鎖、鎖饑餓、線程無法喚醒等疑難雜症極具指導意義。