JDK1.8 AbstractQueuedSynchronizer的實現分析（學習筆記）
lock方法會呼叫acquire方法，該方法在AQS中實現
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}正常使用一個ReentrantLock 的lock() 方法時，在不能獲得所得情況下，該方法是阻塞的，對吧
以上acquire方法拆解一下方法呼叫
首先tryAcquire(arg)，英語不好的我Acquire，百度給出的意思是獲得，獲取，那麼好這裡可以給成意思是嘗試獲得的意思？
如果申請資源失敗，則返回false，那麼會先呼叫addWaiter(Node.EXCLUSIVE)，這裡的Node.EXCLUSIVE代表獨佔的意思，so這個節點是獨佔的？
/**
* Creates and enqueues node for current thread and given mode.
*
* @param mode Node.EXCLUSIVE for exclusive, Node.SHARED for shared
* @return the new node
*/
private Node addWaiter(Node mode) {
//封裝了當前執行緒？？
Node node = new Node(Thread.currentThread(), mode);
// Try the fast path of enq; backup to full enq on failure 這裡考慮多執行緒呼叫的情況，這裡的連結串列不存線上程安全問題，因為對每個頭尾節點的操作都是CAS的。詳見程式碼片段裡的
compareAndSetHead和compareAndSetTail方法。
/**
* Inserts node into queue, initializing if necessary. See picture above.
* @param node the node to insert
* @return node's predecessor
*/
private Node enq(final Node node) {
for (;;) {
Node t = tail;
//第一次的時候尾節點肯定是一個 null，則初始話一個空內容節點為頭節點，第二次迴圈時尾節點已經不是null了
if (t == null) { // Must initialize
if (compareAndSetHead(new Node()))
tail = head;
} else {
node.prev = t; //將node節點的前驅節點設定成尾節點，即先嚐試追加到連結串列的尾部，如果尾節點是t，則將尾節點設定成node，退出迴圈
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}
所以第一個等待鎖的執行緒A在AQS中的資料結構是這樣的？
空節點 -> node(name:A)
看到這裡，AQS中對內部連結串列的頭尾操作都是CAS的，所以連結串列中的節點排序也是完全按照申請鎖的順序排列的。addWaiter方法的操作無非是將執行緒封裝為一個node，追加該節點到連結串列的尾節點,然後addWaiter 方法返回封裝好的node方法，繼續呼叫acquireQueued(node) ，
acquireQueued 方法是一個自旋的方法，假設當前只有一個執行緒A排隊申請鎖，目前連結串列形式為。
空節點 -> node(name:A)
/**
* Acquires in exclusive uninterruptible mode for thread already in
* queue. Used by condition wait methods as well as acquire.
*
* @param node the node
* @param arg the acquire argument
* @return {@code true} if interrupted while waiting
*/
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {//自旋方法
final Node p = node.predecessor();
//獲得p的前驅節點，並判斷是否為head節點，如果為head節點且成功獲取到資源，就將當前執行緒節點設定成佇列的頭節點，並返回
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);
}
}這裡判斷p==head，如果node的前驅節點是head，說明該節點排成了老二，而老二如果成功獲取到資源，則變成老大，那麼這裡老大的起到的是什麼作用？
>
我的程式有一把鎖在外邊阻塞中(sleep)，從程式碼上看一開始tryAcquire方法就成功申請到資源，就不會有他的node維護在這裡，就是說他的鎖不需要在這裡排隊？那麼後續的unlock是怎樣的一個機制？
因為鎖在別的執行緒中持有（state>0），所以這個acquireQueued方法中的tryAcquire會返回false
然後shouldParkAfterFailedAcquire，字面意思如果申請資源失敗則判斷是否可以掛起執行緒
/**
* Checks and updates status for a node that failed to acquire.
* Returns true if thread should block. This is the main signal
* control in all acquire loops. Requires that pred == node.prev.
*
* @param pred node's predecessor holding status
* @param node the node
* @return {@code true} if thread should block
*/
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
//獲取節點的前驅節點等待狀態
int ws = pred.waitStatus;
//如果是SIGNAL狀態，返回true，第一次來這個肯定不會成立，因為是node的前驅節點是一個空節點。
//空節點->node(A)
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) { //Node.CANCLED 如果節點是被放棄的（什麼情況下會放棄，中斷麼？？）
/*
* 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.
*/
//將前驅節點的狀態設定成SIGNAL
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
至此針對我的測試，這個方法會走compareAndSetWaitStatus(pred, ws, Node.SIGNAL); 分支，所以目前node(name:A)節點的前驅（head節點）的waitStatus狀態為 SIGNAL，該方法的第一次呼叫會返回false
目前針對執行緒A的連結串列表示
node(waitStatus:SIGNAL)->node(name:A)
因為shouldParkAfterFailedAcquire返回了false，所以不會呼叫parkAndCheckInterrupt，那麼會進入第二次迴圈。
node的前驅節點是head 這個是毫無疑問的，但是就是因為獲取鎖的執行緒還是一個熊孩子，沒有釋放資源（state>0）
所以依舊會呼叫shouldParkAfterFailedAcquire方法，但此時方法內部已經不一樣了，這裡已經開始滿足第一個條件分支了，所以此方法此次會返回true，因為因為shouldParkAfterFailedAcquire返回了true，所以會接著呼叫parkAndCheckInterrupt()方法
該方法實現如下:
/**
* Convenience method to park and then check if interrupted
*
* @return {@code true} if interrupted
*/
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);//呼叫park()使執行緒進入waiting狀態
return Thread.interrupted();//如果被喚醒，檢視自己是不是被中斷的。
}
LockSupport.park(this); 大神說park()會讓當前執行緒進入waiting狀態。在此狀態下，有兩種途徑可以喚醒該執行緒：1）被unpark()；2）被interrupt()。
如果當前執行緒waiting了，那麼就不會有第三次迴圈了….因為當前執行緒已經waiting了……
這裡阻塞的執行緒應該是申請鎖的執行緒，LockSupport.park(this);引數的作用是對應的blocker會記錄在Thread的一個parkBlocker屬性中,通過jstack命令可以非常方便的監控具體的阻塞物件.
如果此時又有一個執行緒B，按照此邏輯繼續申請一把鎖,按AQS的處理邏輯會維護成如下形式
node(waitStatus:SIGNAL)->node(name:A)->node(name:B)
假設tryAcquire(arg)依舊失敗，state依舊不給釋放，熊孩子還不還，那麼對於node(name:B) 來說，在acquireQueued中他的前驅肯定不是head節點，所以他只能走shouldParkAfterFailedAcquire方法設定前驅節點的狀態，然後呼叫parkAndCheckInterrupt()方法，去阻塞當前當前申請鎖的執行緒。
同上經歷2次自旋後在AQS中連結串列的維護成如下形式
node(waitStatus:SIGNAL)->node(name:A,waitStatus:SIGNAL)->node(name:B)
這裡貼一個大神的總結和圖
再來總結下它的流程吧：
呼叫自定義同步器的tryAcquire()嘗試直接去獲取資源，如果成功則直接返回；
沒成功，則addWaiter()將該執行緒加入等待佇列的尾部，並標記為獨佔模式；
acquireQueued()使執行緒在等待佇列中休息，有機會時（輪到自己，會被unpark()）會去嘗試獲取資源。獲取到資源後才返回。如果在整個等待過程中被中斷過，則返回true，否則返回false。
如果執行緒在等待過程中被中斷過，它是不響應的。只是獲取資源後才再進行自我中斷selfInterrupt()，將中斷補上。
由於此函式是重中之重，我再用流程圖總結一下：
現在AQS的連結串列裡有三個節點。
node(waitStatus:SIGNAL)->node(name:A,waitStatus:SIGNAL)->node(name:B)
假設一開始長時間阻塞不還鎖的執行緒，時間到了玩夠了回家吃飯去，執行緒中呼叫了reentrantlock.unlock(); 方法，他玩夠了我這邊兩個兄弟還在那waiting呢，是不是會釋放他的執行緒標誌
釋放鎖的程式碼也是很簡單的
public void unlock() {
sync.release(1);
}
這裡sync是實現AQS的一個內部類Sync的例項，所以本質上還是在呼叫AQS的功能，看看怎麼做的。
/**
* Releases in exclusive mode. Implemented by unblocking one or
* more threads if {@link #tryRelease} returns true.
* This method can be used to implement method {@link Lock#unlock}.
*
* @param arg the release argument. This value is conveyed to
* {@link #tryRelease} but is otherwise uninterpreted and
* can represent anything you like.
* @return the value returned from {@link #tryRelease}
*/
public final boolean release(int arg) {
if (tryRelease(arg)) {//釋放資源
Node h = head;
if (h != null && h.waitStatus != 0) //頭結點不為null，且頭結點是有狀態的？
unparkSuccessor(h);//喚醒等待佇列裡的下一個執行緒
return true;
}
return false;
}由上文得知，呼叫AQS的acquire(int args)方法，會呼叫子類的tryAcquire(int args)實現從而實現對執行緒狀態的重置，那麼這裡有一個tryRelease(arg) 是不是也是子類的一個實現呢？其實就是呼叫的子類實現，依舊不去管他的實現
暫且把tryRelease當作釋放資源，如果釋放成功則將頭節點做為引數，呼叫unparkSuccessor方法。
/**
* Wakes up node's successor, if one exists.
*
* @param node the node
*/
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; //拿到連結串列中的第二個節點，本例是node(name:A,waitstatus:SIGNAL)
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); //喚醒執行緒
}依據上面的邏輯本例中的node(name:A,waitstatus:SIGNAL) 節點所持有的執行緒將得到釋放。但是這個節點並沒有被移除。AQS中的連結串列結構變成了這樣
node(waitstatus:0)->node(name:A,waitstatus:SIGNAL)->node(name:B)
此時執行緒A將得到喚醒，然後他會繼續做final boolean acquireQueued(final Node node, int arg) 方法中的自旋。為方法繼續把acquireQueued的程式碼拿出來再貼一遍
/**
* Acquires in exclusive uninterruptible mode for thread already in
* queue. Used by condition wait methods as well as acquire.
*
* @param node the node
* @param arg the acquire argument
* @return {@code true} if interrupted while waiting
*/
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {//自旋方法
final Node p = node.predecessor();
//獲得p的前驅節點，並判斷是否為head節點，如果為head節點且成功獲取到資源，就將當前執行緒節點設定成佇列的頭節點，並返回
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);
}
}此時執行緒A發現他的前驅節點為head，並且此時再申請資源tryAcquire(arg) ，因為那個熊孩子把資源釋放了，所以此時申請資源是成功的，然後會將當前節點設定為連結串列的頭結點，並釋放原來的頭結點佔用的記憶體。
這樣連結串列結構就成了這個樣子：
node(name:A,waitstatus:SIGNAL)->node(name:B)
針對執行緒A來說acquireQueued 方法已經執行完成，假設我們一直老老實實的等沒有通知中斷執行緒，則執行緒A中的程式碼行reentrantLock.lock() 方法將返回，一個程式碼行執行完成，會接著執行下一個程式碼行，lock() 加鎖成功了！那麼問題來了（問題和挖掘機沒有任何關係）tryAcquire和tryRelease 到底在爭搶和釋放什麼東西？
繼續看tryAcquire方法在ReentrantLock類中的實現（公平鎖）
/**
* Fair version of tryAcquire. Don't grant access unless
* recursive call or no waiters or is first.
*/
protected final boolean tryAcquire(int acquires) {
//獲得當前執行緒
final Thread current = Thread.currentThread();
//getState來自AQS，放方法取AQS中的全域性變數state 注意是全域性
int c = getState();
if (c == 0) { //AQS中預設state值為0，如果為0應該可以證明當前AQS佇列裡的執行緒沒有修改過state，也就是說沒有人持有鎖
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;
}
可以發現tryAcquire 方法會先獲取AQS中的全域性變數，也可以說AQS維護的連結串列中的所有節點都會去檢查state這個變數，所以這個state是一個執行緒狀態，也可以看作是他們在搶的一把鎖，如果發現state為0，則代表競爭到資源，並通過CAS的方式設定該值為1，然後設定當前執行緒為exclusiveOwnerThread，另一個條件因為鎖是可重入的啊老鐵
這裡有一個hasQueuedPredecessors() 方法，參照某大神所說
正如hasQueuedPredecessors的註釋所說，該方法的作用是為了避免 “執行緒闖入”，即對於ReentrantLock來說，即便是state為0時，AQS佇列中也可能是有節點的(被取消的，打斷的節點)等等，這個時候為了保證AQS佇列的公平性，不再嘗試加鎖，而是返回false，到AQS的佇列中去排隊。所以，這也是該方法被用在公平鎖中的原因。
遺留問題：
1.為什麼用連結串列管理執行緒
2.節點的狀態SIGNAL 主要含義
3.在AQS中的執行緒如何響應中斷，中斷策略是什麼？
/** waitStatus value to indicate thread has cancelled */ static final int CANCELLED = 1; /** waitStatus value to indicate successor's thread needs unparking */ static final int SIGNAL = -1; /** waitStatus value to indicate thread is waiting on condition */ static final int CONDITION = -2; /** * waitStatus value to indicate the next acquireShared should * unconditionally propagate */ static final int PROPAGATE = -3;