深入理解Java併發框架AQS系列（三）：獨佔鎖（Exclusive Lock）
阿新 • • 發佈：2021-03-25
[深入理解Java併發框架AQS系列（一）：執行緒](https://www.cnblogs.com/xijiu/p/14396061.html)
[深入理解Java併發框架AQS系列（二）：AQS框架簡介及鎖概念](https://www.cnblogs.com/xijiu/p/14522224.html)
[深入理解Java併發框架AQS系列（三）：獨佔鎖（Exclusive Lock）](https://www.cnblogs.com/xijiu/p/14579262.html)
# 一、前言
> 優秀的原始碼就在那裡
經過了前面兩章的鋪墊，終於要切入正題了，本章也是整個AQS的核心之一
從本章開始，我們要精讀AQS原始碼，在欣賞它的同時也要學會質疑它。當然本文不會帶著大家逐行過原始碼（會有“只在此山中，雲深不知處”的弊端），而是從功能入手，對其架構進行逐層剖析，在核心位置重點解讀，並提出質疑；雖然AQS原始碼讀起來比較“跳”，但我還是建議大家花時間及精力去好好讀它
本章我們採用經典併發類`ReentrantLock`來闡述獨佔鎖
# 二、整體回顧
獨佔鎖，顧名思義，即在同一時刻，僅允許一個執行緒執行同步塊程式碼。好比一夥兒人想要過河，但只有一根獨木橋，且只能承受一人的重量
相信我們平時寫獨佔鎖的程式大抵是這樣的：
```
ReentrantLock lock = new ReentrantLock();
try {
lock.lock();
doBusiness();
} finally {
lock.unlock();
}
```
上述程式碼分為三部分：
* 加鎖 `lock.lock()`
* 執行同步程式碼 `doBusiness()`
* 解鎖 `lock.unlock()`
加鎖部分，一定是眾矢之的，兵家爭搶的要地，對於高併發的程式來說，同一時刻，大量的執行緒爭相湧入，而`lock()`則保證只能有一個執行緒進入`doBusiness()`邏輯，且在其執行完畢`unlock()`方法之前，不能有其他執行緒進入。所以相對而言，`unlock()`方法相對輕鬆，不用處理多執行緒的場景
## 2.1、`waitStatus`
本章中，我們引入節點中一個關鍵的欄位`waitStatus`（後文簡寫為`ws`），在獨佔鎖模式中，可能會使用到的等待狀態如下：
* 1、`0` FLAG_STORE = new ThreadLocal<>();
private static ThreadLocal TIMES = ThreadLocal.withInitial(() -> 0);
private Sync sync = new Sync();
private static class Sync extends AbstractQueuedSynchronizer {
private Sync() {
setState(1);
}
public void lock() {
FLAG_STORE.set(++FLAG);
int state = getState();
if (state == 1 && compareAndSetState(state, 0)) {
return;
}
acquire(1);
}
@Override
protected boolean tryAcquire(int acquires) {
if (FLAG_STORE.get() == 2) {
Integer time = TIMES.get();
if (time == 0) {
TIMES.set(1);
} else {
// 模擬發生異常，第二個節點在第二次訪問tryAcquire方法時，將會扔出執行期異常
System.out.println("發生異常");
throw new RuntimeException("lkn aqs bug");
}
}
int state = getState();
if (state == 1 && compareAndSetState(state, 0)) {
return true;
}
return false;
}
@Override
protected final boolean tryRelease(int releases) {
setState(1);
return true;
}
public void unlock() {
release(1);
}
}
public void lock() {
sync.lock();
}
public void unlock() {
sync.unlock();
}
}
// 測試用例如下：
public class BugTest {
private static volatile int number = 0;
@Test
public void test2() throws InterruptedException {
List list = Lists.newArrayList();
FindBugAQS aqs = new FindBugAQS();
Thread thread1 = new Thread(() -> {
aqs.lock();
PubTools.sleep(5000);
number++;
aqs.unlock();
});
thread1.start();
list.add(thread1);
PubTools.sleep(500);
for (int i = 0; i < 4; i++) {
Thread thread2 = new Thread(() -> {
aqs.lock();
PubTools.sleep(500);
number++;
aqs.unlock();
});
thread2.start();
list.add(thread2);
}
for (Thread thread : list) {
thread.join();
}
System.out.println("number is " + number);
}
}
```
執行結果：
```
發生異常
Exception in thread "Thread-1" java.lang.RuntimeException: lkn aqs bug
at org.xijiu.share.aqs.bug.FindBugAQS$Sync.tryAcquire(FindBugAQS.java:42)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:863)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
at org.xijiu.share.aqs.bug.FindBugAQS$Sync.lock(FindBugAQS.java:31)
at org.xijiu.share.aqs.bug.FindBugAQS.lock(FindBugAQS.java:64)
at org.xijiu.share.aqs.bug.BugTest.lambda$test2$2(BugTest.java:61)
at java.lang.Thread.run(Thread.java:748)
number is 4
```
我們自定義了AQS實現類`FindBugAQS.java`，模擬第二個節點在第二次訪問`tryAcquire`會扔出異常；然後啟動5個執行緒，對`number`進行累加。可見，最後的結果符合預期，AQS處理的很完美。那程式發生異常後，阻塞佇列究竟如何應對？
舉例說明吧，假定現在除去頭結點外，阻塞佇列中還有3個節點，當第1個節點被喚醒執行時，發生了異常，那麼第1個節點會將`ws`置為`CANCELLED`，且將向後的鏈條打斷（指向自己），但向前鏈條保持不變，並喚醒下一個節點
由上圖可見，當某個節點響應中斷/發生異常後，其會主動打斷向後鏈條，但依舊保留向前的鏈條，這樣做的目的是為了後續節點在尋找前節點時，可以找到標記為`CANCELLED`狀態的節點，而不是找到`null`。至此便解答了3.2提出的兩個問題
a、為什麼阻塞佇列內有這麼多`CANCELLED`狀態的節點？