@
前言
JDK1.5以前只有synchronized同步鎖，並且效率非常低，因此大神Doug Lea自己寫了一套併發框架，這套框架的核心就在於AbstractQueuedSynchronizer類（即AQS），效能非常高，所以被引入JDK包中，即JUC。那麼AQS是怎麼實現的呢？本篇就是對AQS及其相關元件進行分析，瞭解其原理，並領略大神的優美而又精簡的程式碼。
AbstractQueuedSynchronizer
AQS是JUC下最核心的類，沒有之一，所以我們先來分析一下這個類的資料結構。
AQS內部是使用了雙向連結串列將等待執行緒連結起來，當發生併發競爭的時候，就會初始化該佇列並讓執行緒進入睡眠等待喚醒，同時每個節點會根據是否為共享鎖標記狀態為共享模式或獨佔模式。這個資料結構需要好好理解並牢牢記住，下面分析的元件都將基於此實現。
Lock
Lock是一個介面，提供了加/解鎖的通用API，JUC主要提供了兩種鎖，ReentrantLock和ReentrantReadWriteLock，前者是重入鎖，實現Lock介面，後者是讀寫鎖，本身並沒有實現Lock介面，而是其內部類ReadLock或WriteLock實現了Lock介面。先來看看Lock都提供了哪些介面：
// 普通加鎖，不可打斷；未獲取到鎖進入AQS阻塞
void lock();
// 可打斷鎖
void lockInterruptibly() throws InterruptedException;
// 嘗試加鎖，未獲取到鎖不阻塞，返回標識
boolean tryLock();
// 帶超時時間的嘗試加鎖
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
// 解鎖
void unlock();
// 建立一個條件佇列
Condition newCondition();
看到這裡讀者們可以先思考下，自己如何來實現上面這些介面。
ReentrantLock
加鎖
synchronized和ReentrantLock都是可重入的，後者使用更加靈活，也提供了更多的高階特性，但其本質的實現原理是差不多的（據說synchronized是借鑑了ReentrantLock的實現原理）。ReentrantLock提供了兩個構造方法：
public ReentrantLock() {
sync = new NonfairSync();
}
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
有參構造是根據引數建立公平鎖或非公平鎖，而無參構造預設則是非公平鎖，因為非公平鎖效能非常高，並且大部分業務並不需要使用公平鎖。至於為什麼非公平鎖效能很高，我們們接著往下看。
非公平鎖/公平鎖
lock
非公平鎖和公平鎖在實現上基本一致，只有個別的地方不同，因此下面會採用對比分析方法進行分析。
從lock方法開始：
public void lock() {
sync.lock();
}
實際上是委託給了內部類Sync，該類實現了AQS（其它元件實現方法也基本上都是這個套路）；由於有公平和非公平兩種模式，因此該類又實現了兩個子類：FairSync和NonfairSync：
// 非公平鎖
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
// 公平鎖
final void lock() {
acquire(1);
}
這裡就是公平鎖和非公平鎖的第一個不同，非公平鎖首先會呼叫CAS將state從0改為1，如果能改成功則表示獲取到鎖，直接將exclusiveOwnerThread設定為當前執行緒，不用再進行後續操作；否則則同公平鎖一樣呼叫acquire方法獲取鎖，這個是在AQS中實現的模板方法：
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
tryAcquire
這裡兩種鎖唯一不同的實現就是tryAcquire方法，先來看非公平鎖的實現：
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
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;
}
state=0表示還沒有被執行緒持有鎖，直接通過CAS修改，能修改成功的就獲取到鎖，修改失敗的執行緒先判斷exclusiveOwnerThread是不是當前執行緒，是則state+1，表示重入次數+1並返回true，加鎖成功，否則則返回false表示嘗試加鎖失敗並呼叫acquireQueued入隊。
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;
}
public final boolean hasQueuedPredecessors() {
Node t = tail; // Read fields in reverse initialization order
Node h = head;
Node s;
// 首尾不相等且頭結點執行緒不是當前執行緒則表示需要進入佇列
return h != t &&
((s = h.next) == null || s.thread != Thread.currentThread());
}
上面就是公平鎖的嘗試獲取鎖的程式碼，可以看到基本和非公平鎖的程式碼是一樣的，區別在於首次加鎖需要判斷是否已經有佇列存在，沒有才去加鎖，有則直接返回false。
addWaiter
接著來看addWaiter方法，當嘗試加鎖失敗時，首先就會呼叫該方法建立一個Node節點並新增到佇列中去。
private Node addWaiter(Node mode) {
Node node = new Node(Thread.currentThread(), mode);
Node pred = tail;
// 尾節點不為null表示已經存在佇列，直接將當前執行緒作為尾節點
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) { // 只會有一個執行緒設定頭節點成功
if (compareAndSetHead(new Node()))
tail = head;
} else { // 其它設定頭節點失敗的都會自旋設定尾節點
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}
這裡首先傳入了一個獨佔模式的空節點，並根據該節點和當前執行緒建立了一個Node，然後判斷是否已經存在佇列，若存在則直接入隊，否則呼叫enq方法初始化佇列，提高效率。
此處還有一個非常細節的地方，為什麼設定尾節點時都要先將之前的尾節點設定為node.pre的值呢，而不是在CAS之後再設定？比如像下面這樣：
if (compareAndSetTail(pred, node)) {
node.prev = pred;
pred.next = node;
return node;
}
因為如果這樣做的話，在CAS設定完tail後會存在一瞬間的tail.pre=null的情況，而Doug Lea正是考慮到這種情況，不論何時獲取tail.pre都不會為null。
acquireQueued
接著看acquireQueued方法：
final boolean acquireQueued(final Node node, int arg) {
// 為true表示存在需要取消加鎖的節點，僅從這段程式碼可以看出，
// 除非發生異常，否則不會存在需要取消加鎖的節點。
boolean failed = true;
try {
// 打斷標記，因為呼叫的是lock方法，所以是不可打斷的
// （但實際上是打斷了的，只不過這裡採用了一種**靜默**處理方式，稍後分析）
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 final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
return Thread.interrupted();
}
這裡就是佇列中執行緒加鎖/睡眠的核心邏輯，首先判斷剛剛呼叫addWaiter方法新增到佇列的節點是否是頭節點，如果是則再次嘗試加鎖，這個剛剛分析過了，非公平鎖在這裡就會再次搶一次鎖，搶鎖成功則設定為head節點並返回打斷標記；否則則和公平鎖一樣呼叫shouldParkAfterFailedAcquire判斷是否應該呼叫park方法進入睡眠。
park細節
為什麼在park前需要這麼一個判斷呢？因為當前節點的執行緒進入park後只能被前一個節點喚醒，那前一個節點怎麼知道有沒有後繼節點需要喚醒呢？因此當前節點在park前需要給前一個節點設定一個標識，即將waitStatus設定為Node.SIGNAL（-1），然後自旋一次再走一遍剛剛的流程，若還是沒有獲取到鎖，則呼叫parkAndCheckInterrupt進入睡眠狀態。
打斷
讀者可能會比較好奇Thread.interrupted這個方法是做什麼用的。
public static boolean interrupted() {
return currentThread().isInterrupted(true);
}
這個是用來判斷當前執行緒是否被打斷過，並清除打斷標記（若是被打斷過則會返回true，並將打斷標記設定為false），所以呼叫lock方法時，通過interrupt也是會打斷睡眠的執行緒的，只是Doug Lea做了一個假象，讓使用者無感知；但有些場景又需要知道該執行緒是否被打斷過，所以acquireQueued最終會返回interrupted打斷標記，如果是被打斷過，則返回的true，並在acquire方法中呼叫selfInterrupt再次打斷當前執行緒（將打斷標記設定為true）。
這裡我們對比看看lockInterruptibly的實現：
public void lockInterruptibly() throws InterruptedException {
sync.acquireInterruptibly(1);
}
public final void acquireInterruptibly(int arg)
throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
if (!tryAcquire(arg))
doAcquireInterruptibly(arg);
}
private void doAcquireInterruptibly(int arg)
throws InterruptedException {
final Node node = addWaiter(Node.EXCLUSIVE);
boolean failed = true;
try {
for (;;) {
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return;
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
throw new InterruptedException();
}
} finally {
if (failed)
cancelAcquire(node);
}
}
可以看到區別就在於使用lockInterruptibly加鎖被打斷後，是直接丟擲InterruptedException異常，我們可以捕獲這個異常進行相應的處理。
取消
最後來看看cancelAcquire是如何取消加鎖的，該情況比較特殊，簡單瞭解下即可：
private void cancelAcquire(Node node) {
if (node == null)
return;
// 首先將執行緒置空
node.thread = null;
// waitStatus > 0表示節點處於取消狀態，則直接將當前節點的pre指向在此之前的最後一個有效節點
Node pred = node.prev;
while (pred.waitStatus > 0)
node.prev = pred = pred.prev;
// 儲存前一個節點的下一個節點，如果在此之前存在取消節點，這裡就是之前取消被取消節點的頭節點
Node predNext = pred.next;
node.waitStatus = Node.CANCELLED;
// 當前節點是tail節點，則替換尾節點，替換成功則將新的尾結點的下一個節點設定為null；
// 否則需要判斷是將當前節點的下一個節點賦值給最後一個有效節點，還是喚醒下一個節點。
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
}
}
解鎖
public void unlock() {
sync.release(1);
}
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
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;
}
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);
}
解鎖就比較簡單了，先呼叫tryRelease對state執行減一操作，如果state==0，則表示完全釋放鎖；若果存在後繼節點，則呼叫unparkSuccessor喚醒後繼節點，喚醒後的節點的waitStatus會重新被設定為0.
只是這裡有一個小細節，為什麼是從後向前找呢？因為我們在開始說過，設定尾節點保證了node.pre不會為null，但pre.next仍有可能是null，所以這裡只能從後向前找到最後一個有效節點。
小結
上面是ReentrantLock的加鎖流程，可以看到整個流程不算複雜，只是判斷和跳轉比較多，主要是Doug Lea將程式碼和效能都優化到了極致，程式碼非常精簡，但細節卻非常多。另外通過上面的分析，我們也可以發現，公平鎖和非公平鎖的區別就在於非公平鎖不管是否有執行緒在排隊，先搶三次鎖，而公平鎖則會判斷是否存在佇列，有執行緒在排隊則直接進入佇列排隊；另外執行緒在park被喚醒後非公平鎖還會搶鎖，公平鎖仍然需要排隊，所以非公平鎖的效能比公平鎖高很多，大部分情況下我們使用非公平鎖即可。
ReentrantReadWriteLock
ReentrantLock是一把獨佔鎖，只支援重入，不支援共享，所以JUC包下還提供了讀寫鎖，這把鎖支援讀讀併發，但讀寫、寫寫都是互斥的。
讀寫鎖也是基於AQS實現的，也包含了一個繼承自AQS的內部類Sync，同樣也有公平和非公平兩種模式，下面主要討論非公平模式下的讀寫鎖實現。
讀寫鎖實現相對比較複雜，在ReentrantLock中就是使用的int型的state屬性來表示鎖被某個執行緒佔有和重入次數，而ReentrantReadWriteLock分為了讀和寫兩種鎖，要怎麼用一個欄位表示兩種鎖的狀態呢？Doug Lea大師將state欄位分為了高二位元組和低二位元組，即高16位用來表示讀鎖狀態，低16位則用來表示寫鎖，如下圖：
因為讀寫鎖狀態都只用了兩個位元組，所以可重入的次數最多是65535，當然正常情況下重入是不可能達到這麼多的。
那它是怎麼實現的呢？還是先從構造方法開始：
public ReentrantReadWriteLock() {
this(false);
}
public ReentrantReadWriteLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
readerLock = new ReadLock(this);
writerLock = new WriteLock(this);
}
同樣預設就是非公平鎖，同時還建立了readerLock和writerLock兩個物件，我們只需要像下面這樣就能獲取到讀寫鎖：
private static ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
private static Lock r = lock.readLock();
private static Lock w = lock.writeLock();
寫鎖
由於寫鎖的加鎖過程相對更簡單，下面先從寫鎖加鎖開始分析，入口在ReentrantReadWriteLock#WriteLock.lock()方法，點進去看，發現還是使用的AQS中的acquire方法：
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
所以不同的地方也只有tryAcquire方法，我們重點分析這個方法就行：
static final int SHARED_SHIFT = 16;
// 65535
static final int MAX_COUNT = (1 << SHARED_SHIFT) - 1;
// 低16位是1111....1111
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;
// 得到c低16位的值
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }
protected final boolean tryAcquire(int acquires) {
Thread current = Thread.currentThread();
int c = getState();
// 獲取寫鎖加鎖和重入的次數
int w = exclusiveCount(c);
if (c != 0) { // 已經有執行緒持有鎖
// 這裡有兩種情況：1. c!=0 && w==0表示有執行緒獲取了讀鎖，不論是否是當前執行緒，直接返回false，
// 也就是說讀-寫鎖是不支援升級重入的（但支援寫-讀降級），原因後文會詳細分析；
// 2. c!=0 && w!=0 && current != getExclusiveOwnerThread()表示有其它執行緒持有了寫鎖，寫寫互斥
if (w == 0 || current != getExclusiveOwnerThread())
return false;
// 超出65535，拋異常
if (w + exclusiveCount(acquires) > MAX_COUNT)
throw new Error("Maximum lock count exceeded");
// 否則寫鎖的次數直接加1
setState(c + acquires);
return true;
}
// c==0才會走到這，但這時存在兩種情況，有佇列和無佇列，所以公平鎖和非公平鎖處理不同，
// 前者需要判斷是否存在佇列，有則嘗試加鎖失敗，無則加鎖成功，而非公平鎖直接使用CAS加鎖即可
if (writerShouldBlock() ||
!compareAndSetState(c, c + acquires))
return false;
setExclusiveOwnerThread(current);
return true;
}
寫鎖嘗試加鎖的過程就分析完了，其餘的部分上文已經講過，這裡不再贅述。
讀鎖
public void lock() {
sync.acquireShared(1);
}
public final void acquireShared(int arg) {
if (tryAcquireShared(arg) < 0)
doAcquireShared(arg);
}
讀鎖在加鎖開始就和其它鎖不同，呼叫的是acquireShared方法，意為獲取共享鎖。
static final int SHARED_UNIT = (1 << SHARED_SHIFT);
// 右移16位得到讀鎖狀態的值
static int sharedCount(int c) { return c >>> SHARED_SHIFT; }
protected final int tryAcquireShared(int unused) {
Thread current = Thread.currentThread();
int c = getState();
// 為什麼讀寫互斥？因為讀鎖一上來就判斷了是否有其它執行緒持有了寫鎖（當前執行緒持有寫鎖再獲取讀鎖是可以的）
if (exclusiveCount(c) != 0 &&
getExclusiveOwnerThread() != current)
return -1;
int r = sharedCount(c);
// 公平鎖判斷是否存在佇列，非公平鎖判斷第一個節點是不是EXCLUSIVE模式，是的話會返回true
// 返回false則需要判斷讀鎖加鎖次數是否超過65535，沒有則使用CAS給讀鎖+1
if (!readerShouldBlock() &&
r < MAX_COUNT &&
compareAndSetState(c, c + SHARED_UNIT)) {
if (r == 0) {
// 第一個讀鎖執行緒就是當前執行緒
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) {
// 記錄讀鎖的重入
firstReaderHoldCount++;
} else {
// 獲取最後一次加讀鎖的重入次數記錄器HoldCounter
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
// 當前執行緒第一次重入需要初始化，以及當前執行緒和快取的最後一次記錄器的執行緒id不同，需要從ThreadLocalHoldCounter拿到對應的記錄器
cachedHoldCounter = rh = readHolds.get();
else if (rh.count == 0)
// 快取到ThreadLocal
readHolds.set(rh);
rh.count++;
}
return 1;
}
return fullTryAcquireShared(current);
}
這段程式碼有點複雜，首先需要保證讀寫互斥，然後進行初次加鎖，若加鎖失敗就會呼叫fullTryAcquireShared方法進行兜底處理。在初次加鎖中與寫鎖不同的是，寫鎖的state可以直接用來記錄寫鎖的重入次數，因為寫寫互斥，但讀鎖是共享的，state用來記錄讀鎖的加鎖次數了，重入次數該怎麼記錄呢？重入是指同一執行緒，那麼是不是可以使用ThreadLocl來儲存呢？沒錯，Doug Lea就是這麼處理的，新增了一個HoldCounter類，這個類只有執行緒id和重入次數兩個欄位，當執行緒重入的時候就會初始化這個類並儲存在ThreadLocalHoldCounter類中，這個類就是繼承ThreadLocl的，用來初始化HoldCounter物件並儲存。
這裡還有個小細節，為什麼要使用cachedHoldCounter快取最後一次加讀鎖的HoldCounter？因為大部分情況下，重入和釋放鎖的執行緒很有可能就是最後一次加鎖的執行緒，所以這樣做能夠提高加解鎖的效率，Doug Lea真是把效能優化到了極致。
上面只是初次加鎖，有可能會加鎖失敗，就會進入到fullTryAcquireShared方法：
final int fullTryAcquireShared(Thread current) {
HoldCounter rh = null;
for (;;) {
int c = getState();
if (exclusiveCount(c) != 0) {
if (getExclusiveOwnerThread() != current)
return -1;
} else if (readerShouldBlock()) {
if (firstReader == current) {
// assert firstReaderHoldCount > 0;
} else {
if (rh == null) {
rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current)) {
rh = readHolds.get();
if (rh.count == 0)
readHolds.remove();
}
}
if (rh.count == 0)
return -1;
}
}
if (sharedCount(c) == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
if (compareAndSetState(c, c + SHARED_UNIT)) {
if (sharedCount(c) == 0) {
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) {
firstReaderHoldCount++;
} else {
if (rh == null)
rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();
else if (rh.count == 0)
readHolds.set(rh);
rh.count++;
cachedHoldCounter = rh; // cache for release
}
return 1;
}
}
}
這個方法中程式碼和tryAcquireShared基本上一致，只是採用了自旋的方式，處理初次加鎖中的漏網之魚，讀者們可自行閱讀分析。
上面兩個方法若返回大於0則表示加鎖成功，小於0則會呼叫doAcquireShared方法，這個就和之前分析的acquireQueued差不多了：
private void doAcquireShared(int arg) {
// 先新增一個SHARED型別的節點到佇列
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) {
// 設定head節點以及傳播喚醒後面的讀執行緒
setHeadAndPropagate(node, r);
p.next = null; // help GC
if (interrupted)
selfInterrupt();
failed = false;
return;
}
}
// 只有前一個節點的waitStatus=-1時才會park，=0或者-3（先不考慮-2和1的情況）都會設定為-1後再次自旋嘗試加鎖，若還是加鎖失敗就會park
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
private void setHeadAndPropagate(Node node, int propagate) {
// 設定頭節點
Node h = head; // Record old head for check below
setHead(node);
// propagate是tryAcquireShared的返回值，當前執行緒加鎖成功還要去喚醒後繼的共享節點
// （其餘的判斷比較複雜，筆者也還未想明白，知道的讀者可以指點一下）
if (propagate > 0 || h == null || h.waitStatus < 0 ||
(h = head) == null || h.waitStatus < 0) {
Node s = node.next;
// 判斷後繼節點是否是共享節點
if (s == null || s.isShared())
doReleaseShared();
}
}
private void doReleaseShared() {
for (;;) {
Node h = head;
// 存在後繼節點
if (h != null && h != tail) {
int ws = h.waitStatus;
if (ws == Node.SIGNAL) {
// 當前一個節點加鎖成功後自然需要將-1改回0，並喚醒後繼執行緒，同時自旋將0改為-2讓喚醒傳播下去
if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
continue;
unparkSuccessor(h);
}
// 設定頭節點的waitStatus=-2，使得喚醒可以傳播下去
else if (ws == 0 &&
!compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
continue;
}
if (h == head)
break;
}
}
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;
}
這裡的邏輯也非常的繞，當多個執行緒同時呼叫addWaiter新增到佇列中後，並且假設這些節點的第一個節點的前一個節點就是head節點，那麼第一個節點就能加鎖成功（假設都是SHARED節點），其餘的節點在第一個節點設定頭節點之前都會進入shouldParkAfterFailedAcquire方法，這時候waitStatus都等於0，所以繼續自旋不會park，若再次加鎖還失敗就會park（因為這時候waitStatus=-1），但都是讀執行緒的情況下一般都不會出現，因為setHeadAndPropagate第一步就是修改head，所以其餘SHARED節點最終都能加鎖成功並一直將喚醒傳播下去。
以上就是讀寫鎖加鎖過程，解鎖比較簡單，這裡就不詳細分析了。
小結
讀寫鎖將state分為了高二位元組和低二位元組，分別儲存讀鎖和寫鎖的狀態，實現更為的複雜，在使用上還有幾點需要注意：
- 讀讀共享，但是在讀中間穿插了寫的話，後面的讀都會被阻塞，直到前面的寫釋放鎖後，後面的讀才會共享，相關原理看完前文不難理解。
- 讀寫鎖只支援降級重入，不支援升級重入。因為如果支援升級重入的話，是會出現死鎖的。如下面這段程式碼：
private static void rw() {
r.lock();
try {
log.info("獲取到讀鎖");
w.lock();
try {
log.info("獲取到寫鎖");
} finally {
w.unlock();
}
} finally {
r.unlock();
}
}
多個執行緒訪問都能獲取到讀鎖，但讀寫互斥，彼此都要等待對方的讀鎖釋放才能獲取到寫鎖，這就造成了死鎖。
ReentrantReadWriteLock在某些場景下效能上不算高，因此Doug Lea在JDK1.8的時候又提供了一把高效能的讀寫鎖StampedLock，前者讀寫鎖都是悲觀鎖，而後者提供了新的模式——樂觀鎖，但它不是基於AQS實現的，本文不進行分析。
Condition
Lock介面中還有一個方法newCondition，這個方法就是建立一個條件佇列：
public Condition newCondition() {
return sync.newCondition();
}
final ConditionObject newCondition() {
return new ConditionObject();
}
所謂條件佇列就是建立一個新的ConditionObject物件，這個物件的資料結構在開篇就看過了，包含首、尾兩個節點欄位，每當呼叫Condition#await方法時就會在對應的Condition物件中排隊等待：
public final void await() throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
// 加入條件佇列
Node node = addConditionWaiter();
// 因為Condition.await必須配合Lock.lock使用，所以await時就是將已獲得鎖的執行緒全部釋放掉
int savedState = fullyRelease(node);
int interruptMode = 0;
// 判斷是在同步佇列還是條件佇列，後者則直接park
while (!isOnSyncQueue(node)) {
LockSupport.park(this);
// 獲取打斷處理方式（丟擲異常或重設標記）
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
}
// 呼叫aqs的方法
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
if (node.nextWaiter != null) // clean up if cancelled
// 清除掉已經進入同步佇列的節點
unlinkCancelledWaiters();
if (interruptMode != 0)
reportInterruptAfterWait(interruptMode);
}
private Node addConditionWaiter() {
Node t = lastWaiter;
// 清除狀態為取消的節點
if (t != null && t.waitStatus != Node.CONDITION) {
unlinkCancelledWaiters();
t = lastWaiter;
}
// 建立一個CONDITION狀態的節點並新增到佇列末尾
Node node = new Node(Thread.currentThread(), Node.CONDITION);
if (t == null)
firstWaiter = node;
else
t.nextWaiter = node;
lastWaiter = node;
return node;
}
await方法實現比較簡單，大部分程式碼都是上文分析過的，這裡不再重複。接著來看signal方法：
public final void signal() {
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
// 從條件佇列第一個節點開始喚醒
Node first = firstWaiter;
if (first != null)
doSignal(first);
}
private void doSignal(Node first) {
do {
if ( (firstWaiter = first.nextWaiter) == null)
lastWaiter = null;
first.nextWaiter = null;
} while (!transferForSignal(first) &&
(first = firstWaiter) != null);
}
final boolean transferForSignal(Node node) {
// 修改waitStatus狀態，如果修改失敗，則說明該節點已經從條件佇列轉移到了同步佇列
if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
return false;
// 上面修改成功，則將該節點新增到同步佇列末尾，並返回之前的尾結點
Node p = enq(node);
int ws = p.waitStatus;
if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
// unpark當前執行緒，結合await方法看
LockSupport.unpark(node.thread);
return true;
}
signal的邏輯也比較簡單，就是喚醒條件佇列中的第一個節點，主要是要結合await的程式碼一起理解。
其它元件
上文分析的鎖都是用來實現併發安全控制的，而對於多執行緒協作JUC又基於AQS提供了CountDownLatch、CyclicBarrier、Semaphore等元件，下面一一分析。
CountDownLatch
CountDownLatch在建立的時候就需要指定一個計數：
CountDownLatch countDownLatch = new CountDownLatch(5);
然後在需要等待的地方呼叫countDownLatch.await()方法，然後在其它執行緒完成任務後呼叫countDownLatch.countDown()方法，每呼叫一次該計數就會減一，直到計數為0時，await的地方就會自動喚醒，繼續後面的工作，所以CountDownLatch適用於一個執行緒等待多個執行緒的場景，那它是怎麼實現的呢？讀者們可以結合上文自己先思考下。
public CountDownLatch(int count) {
if (count < 0) throw new IllegalArgumentException("count < 0");
this.sync = new Sync(count);
}
Sync(int count) {
setState(count);
}
與前面講的鎖一樣，也有一個內部類Sync繼承自AQS，並且在構造時就將傳入的計數設定到了state屬性，看到這裡不難猜到CountDownLatch的實現原理了。
public void await() throws InterruptedException {
sync.acquireSharedInterruptibly(1);
}
public final void acquireSharedInterruptibly(int arg)
throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
if (tryAcquireShared(arg) < 0)
doAcquireSharedInterruptibly(arg);
}
protected int tryAcquireShared(int acquires) {
return (getState() == 0) ? 1 : -1;
}
在await方法中使用的是可打斷的方式獲取的共享鎖，同樣除了tryAcquireShared方法，其餘的都是複用的之前分析過的程式碼，而tryAcquireShared就是判斷state是否等於0，不等於就阻塞。
public void countDown() {
sync.releaseShared(1);
}
public final boolean releaseShared(int arg) {
if (tryReleaseShared(arg)) {
doReleaseShared();
return true;
}
return false;
}
protected boolean tryReleaseShared(int releases) {
for (;;) {
int c = getState();
if (c == 0)
return false;
int nextc = c-1;
if (compareAndSetState(c, nextc))
return nextc == 0;
}
}
而呼叫countDown就更簡單了，每次對state遞減，直到為0時才會呼叫doReleaseShared釋放阻塞的執行緒。
最後需要注意的是CountDownLatch的計數是不支援重置的，每次使用都要新建一個。
CyclicBarrier
CyclicBarrier和CountDownLatch使用差不多，不過它只有await方法。CyclicBarrier在建立時同樣需要指定一個計數，當呼叫await的次數達到計數時，所有執行緒就會同時喚醒，相當於設定了一個“起跑線”，需要等所有運動員都到達這個“起跑線”後才能一起開跑。另外它還支援重置計數，提供了reset方法。
public CyclicBarrier(int parties) {
this(parties, null);
}
public CyclicBarrier(int parties, Runnable barrierAction) {
if (parties <= 0) throw new IllegalArgumentException();
this.parties = parties;
this.count = parties;
this.barrierCommand = barrierAction;
}
CyclicBarrier提供了兩個構造方法，我們可以傳入一個Runnable型別的回撥函式，當達到計數時，由最後一個呼叫await的執行緒觸發執行。
public int await() throws InterruptedException, BrokenBarrierException {
try {
return dowait(false, 0L);
} catch (TimeoutException toe) {
throw new Error(toe); // cannot happen
}
}
private int dowait(boolean timed, long nanos)
throws InterruptedException, BrokenBarrierException,
TimeoutException {
final ReentrantLock lock = this.lock;
lock.lock();
try {
final Generation g = generation;
if (g.broken)
throw new BrokenBarrierException();
// 是否打斷，打斷會喚醒所有條件佇列中的執行緒
if (Thread.interrupted()) {
breakBarrier();
throw new InterruptedException();
}
// 計數為0時，喚醒條件佇列中的所有執行緒
int index = --count;
if (index == 0) { // tripped
boolean ranAction = false;
try {
final Runnable command = barrierCommand;
if (command != null)
command.run();
ranAction = true;
nextGeneration();
return 0;
} finally {
if (!ranAction)
breakBarrier();
}
}
for (;;) {
try {
// 不帶超時時間直接進入條件佇列等待
if (!timed)
trip.await();
else if (nanos > 0L)
nanos = trip.awaitNanos(nanos);
} catch (InterruptedException ie) {
if (g == generation && ! g.broken) {
breakBarrier();
throw ie;
} else {
Thread.currentThread().interrupt();
}
}
if (g.broken)
throw new BrokenBarrierException();
if (g != generation)
return index;
if (timed && nanos <= 0L) {
breakBarrier();
throw new TimeoutException();
}
}
} finally {
lock.unlock();
}
}
private void nextGeneration() {
// signal completion of last generation
trip.signalAll();
// set up next generation
count = parties;
generation = new Generation();
}
這裡邏輯比較清晰，就是使用了ReentrantLock以及Condition來實現。在構造方法中我們可以看到儲存了兩個變數count和parties，每次呼叫await都會對count變數遞減，count不為0時都會進入到trip條件佇列中等待，否則就會通過signalAll方法喚醒所有的執行緒，並將parties重新賦值給count。
reset方法很簡單，這裡不詳細分析了。
Semaphore
Semaphore是訊號的意思，或者說許可，可以用來控制最大併發量。初始定義好有幾個訊號，然後在需要獲取訊號的地方呼叫acquire方法，執行完成後，需要呼叫release方法回收訊號。
public Semaphore(int permits) {
sync = new NonfairSync(permits);
}
public Semaphore(int permits, boolean fair) {
sync = fair ? new FairSync(permits) : new NonfairSync(permits);
}
它也有兩個構造方法，可以指定公平或是非公平，而permits就是state的值。
public void acquire() throws InterruptedException {
sync.acquireSharedInterruptibly(1);
}
// 非公平方式
final int nonfairTryAcquireShared(int acquires) {
for (;;) {
int available = getState();
int remaining = available - acquires;
if (remaining < 0 ||
compareAndSetState(available, remaining))
return remaining;
}
}
// 公平方式
protected int tryAcquireShared(int acquires) {
for (;;) {
if (hasQueuedPredecessors())
return -1;
int available = getState();
int remaining = available - acquires;
if (remaining < 0 ||
compareAndSetState(available, remaining))
return remaining;
}
}
acquire方法和CountDownLatch是一樣的，只是tryAcquireShared區分了公平和非公平方式。獲取到訊號相當於加共享鎖成功，否則則進入佇列阻塞等待；而release方法和讀鎖解鎖方式也是一樣的，只是每次release都會將state+1。
總結
本文詳細分析了AQS的核心原理、鎖的實現以及常用的相關元件，掌握其原理能讓我們準確的使用JUC下面的鎖以及執行緒協作元件。另外AQS程式碼設計是非常精良的，有非常多的細節，精簡的程式碼中把所有的情況都考慮到了，細細體味對我們自身編碼能力也會有很大的提高。
文章錯誤和不清楚的地方歡迎批評指出，另外超時相關的API本文都未涉及到，讀者可自行分析。