接上文《深入淺出Java並發包—鎖機制(一) 》
2、Sync.FairSync.TryAcquire（公平鎖）
我們直接來看代碼
protected final boolean tryAcquire(int acquires) { final Thread current = Thread.currentThread(); int c = getState(); if (c == 0) { if (isFirst(current) && 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; }
和明細我們可以看出，公平鎖就比不公平鎖多了一個判斷頭結點的方法，就是采用此方法來保證鎖的公平性。
3、AbstractQueuedSynchronizer.addWaiter
tryAcquire失敗就意味着入隊列了。此時AQS的隊列中節點Node就開始發揮作用了。一般情況下AQS支持獨占鎖和共享鎖，而獨占鎖在Node中就意味着條件（Condition）隊列為空。在java.util.concurrent.locks.AbstractQueuedSynchronizer.Node中有兩個常量
static final Node EXCLUSIVE = null; //獨占節點模式 static final Node SHARED = new Node(); //共享節點模式
addWaiter(mode)中的mode就是節點模式，也就是共享鎖還是獨占鎖模式。添加的節點是當前線程。(注：ReentrantLock是獨占鎖模式)，我們來看下對應的實現代碼：
private Node addWaiter(Node mode) { Node node = new Node(Thread.currentThread(), mode); // Try the fast path of enq; backup to full enq on failure Node pred = tail; if (pred != null) { node.prev = pred; if (compareAndSetTail(pred, node)) { pred.next = node; return node; } } enq(node); return node; }
這塊代碼並不復雜，如果當前隊尾存在元素（tail!=null），則通過CAS添加當前線程到隊尾，如果隊尾為空或者CAS失敗，則通過enq方法設置tail。我們來看下enq的代碼
private Node enq(final Node node) { for (;;) { Node t = tail; if (t == null) { // Must initialize Node h = new Node(); // Dummy header h.next = node; node.prev = h; if (compareAndSetHead(h)) { tail = node; return h; } } else { node.prev = t; if (compareAndSetTail(t, node)) { t.next = node; return t; } } } }
該方法就是循環調用CAS，即使有高並發的場景，無限循環將會最終成功把當前線程追加到隊尾（或設置隊頭）。總而言之，addWaiter的目的就是通過CAS把當前現在追加到隊尾，並返回包裝后的Node實例。
把線程要包裝為Node對象的主要原因，除了用Node構造供虛擬隊列外，還用Node包裝了各種線程狀態，這些狀態被精心設計為一些數字值：
1)、 SIGNAL(-1) ：線程的后繼線程正/已被阻塞，當該線程release或cancel時要重新這個后繼線程(unpark)
2)、 CANCELLED(1)：因為超時或中斷，該線程已經被取消
3)、 CONDITION(-2)：表明該線程被處於條件隊列，就是因為調用了Condition.await而被阻塞
4)、 PROPAGATE(-3)：傳播共享鎖
5)、 0：0代表無狀態
3、AbstractQueuedSynchronizer.acquireQueued(進行阻塞)
acquireQueued的主要作用是把已經追加到隊列的線程節點（addWaiter方法返回值）進行阻塞，但阻塞前又通過tryAccquire重試是否能獲得鎖，如果重試成功能則無需阻塞，直接返回。下面我們來看以下它對應的源碼信息
final boolean acquireQueued(final Node node, int arg) { try { boolean interrupted = false; for (;;) { final Node p = node.predecessor(); if (p == head && tryAcquire(arg)) { setHead(node); p.next = null; // help GC return interrupted; } if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) interrupted = true; } } catch (RuntimeException ex) { cancelAcquire(node); throw ex; } }
仔細看看這個方法是個無限循環，感覺如果p == head && tryAcquire(arg)條件不滿足循環將永遠無法結束，當然不會出現死循環，奧秘在於parkAndCheckInterrupt會把當前線程掛起，從而阻塞住線程的調用棧。我們來看下他的實現方法：
private final boolean parkAndCheckInterrupt() { LockSupport.park(this); return Thread.interrupted(); }
如前面所述，LockSupport.park最終把線程交給系統（Linux）內核進行阻塞。當然也不是馬上把請求不到鎖的線程進行阻塞，還要檢查該線程的狀態，比如如果該線程處於Cancel狀態則沒有必要，具體的檢查在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; }
檢查原則如下：
1、如果前繼節點的waitStatus為signal，則說明前面的節點都還滅有獲取到鎖，此時當前線程需要阻塞，直接返回true
2、如果前繼節點waitStatus>0，說明前繼節點已經被取消，則重新設置當前節點的前繼節點，返回false，之后無限循環直到第一步狀態返回true，導致線程阻塞
3、如果前繼節點waitStatus小於0而且不等於-1(signal)，則通過CAS設置前繼節點額外isignal，並返回false，之后無限循環直到步驟1返回true，線程阻塞。
請求鎖不成功的線程會被掛起在acquireQueued方法的第12行，12行以后的代碼必須等線程被解鎖鎖才能執行，假如被阻塞的線程得到解鎖，則執行第13行，即設置interrupted = true，之后又進入無限循環。
從無限循環的代碼可以看出，並不是得到解鎖的線程一定能獲得鎖，必須在第6行中調用tryAccquire重新競爭，非公平鎖中有可能被新加入的線程獲取到，從而導致剛剛被喚醒的線程再次阻塞；公平鎖通過判斷當前節點是否是頭結點來保證鎖的公平性。上面的代碼我們還可以看到，因為每次第一個被解鎖的是頭結點，因此一般p==head的判斷都會成功。解鎖相對比較簡單，主要體現在AbstractQueuedSynchronizer.release和Sync.tryRelease方法中：
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; }
這個邏輯也比較簡單：
1.判斷持有鎖的線程是否是當前線程，如果不是就拋出IllegalMonitorStateExeception()，因為一個線程是不能釋放另一個線程持有的鎖（否則鎖就失去了意義）。否則進行2。
2.將AQS狀態位減少要釋放的次數（對於獨占鎖而言總是1），如果剩余的狀態位0（也就是沒有線程持有鎖），那么當前線程就是最后一個持有鎖的線程，清空AQS持有鎖的獨占線程。進行3。
3.將剩余的狀態位寫回AQS，如果沒有線程持有鎖就返回true，否則就是false。
從上面我們可以知道，這里c==0決定了是否完全釋放了鎖。由於ReentrantLock是可重入鎖，因此同一個線程可能多重持有鎖，那么當且僅當最后一個持有鎖的線程釋放鎖是才能將AQS中持有鎖的獨占線程清空，這樣接下來的操作才需要喚醒下一個需要鎖的AQS節點（Node），否則就只是減少鎖持有的計數器，並不能改變其他操作。
當tryRelease操作成功后（也就是完全釋放了鎖），release操作才能檢查是否需要喚醒下一個繼任節點。這里的前提是AQS隊列的頭結點需要鎖(waitStatus!=0)，如果頭結點需要鎖，就開始檢測下一個繼任節點是否需要鎖操作。
上文說道acquireQueued操作完成后（拿到了鎖），會將當前持有鎖的節點設為頭結點，所以一旦頭結點釋放鎖，那么就需要尋找頭結點的下一個需要鎖的繼任節點，並喚醒它。我們來看下對應的實現代碼：
private void unparkSuccessor(Node node) { /* * If status is negative (i.e., possibly needing signal) try * to clear in anticipation of signalling. It is OK if this * fails or if status is changed by waiting thread. */ int ws = node.waitStatus; if (ws < 0) compareAndSetWaitStatus(node, ws, 0); /* * Thread to unpark is held in successor, which is normally * just the next node. But if cancelled or apparently null, * traverse backwards from tail to find the actual * non-cancelled successor. */ 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); }
對比對應的代碼我們可以看出，一旦頭結點的后繼結點被喚醒，那么后繼結點就嘗試去獲取鎖，如果獲取成功就將頭結點設置為自身，並將頭結點的前任節點清空。
final boolean acquireQueued(final Node node, int arg) { try { boolean interrupted = false; for (;;) { final Node p = node.predecessor(); if (p == head && tryAcquire(arg)) { setHead(node); p.next = null; // help GC return interrupted; } if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) interrupted = true; } } catch (RuntimeException ex) { cancelAcquire(node); throw ex; } }
對比lock，unlock是相當比較簡單的，主要是釋放需要響應的資源，並喚醒AQS隊列中有效的后繼結點，這樣就試圖以請求的順序獲取鎖資源了。
對比公平鎖和不公平鎖，其實就是在獲取鎖的時候有區別，釋放鎖的時候都是一樣的。非公平鎖總是嘗試看當前有沒有線程持有鎖，如果沒有則使用現有的線程去搶占鎖資源，但是一旦搶占失敗，也就和公平鎖一樣，進入阻塞隊列老老實實排隊去了，也就是說公平鎖和非公平鎖只有在進入AQS的CLH隊列之前有區別，后面都是按照隊列的順序請求鎖資源的。