寫在前面:
實現的關鍵:CLH,state
非公平鎖的鎖搶佔是在各node(thread)入CLH隊列的時候確定的, head節點釋放鎖之後,CLH鏈上的節點依次獲得鎖.而不是釋放鎖之後再進行搶佔.
從Lock作爲切入點
我想以lock作爲切入點來講解AQS，畢竟同步鎖是解決線程安全問題的通用手段，也是我們工作中用得比較多的方式。
Lock API
Lock是一個接口，方法定義如下
void lock() // 如果鎖可用就獲得鎖，如果鎖不可用就阻塞直到鎖釋放
void lockInterruptibly() // 和 lock()方法相似, 但阻塞的線程可中斷，拋出 java.lang.InterruptedException異常
boolean tryLock() // 非阻塞獲取鎖;嘗試獲取鎖，如果成功返回true
boolean tryLock(long timeout, TimeUnit timeUnit) //帶有超時時間的獲取鎖方法
void unlock() // 釋放鎖
Lock的實現
實現Lock接口的類有很多，以下爲幾個常見的鎖實現
- ReentrantLock：表示重入鎖，它是唯一一個實現了Lock接口的類。重入鎖指的是線程在獲得鎖之後，再次獲取該鎖不需要阻塞，而是直接關聯一次計數器增加重入次數
- ReentrantReadWriteLock：重入讀寫鎖，它實現了ReadWriteLock接口，在這個類中維護了兩個鎖，一個是ReadLock，一個是WriteLock，他們都分別實現了Lock接口。讀寫鎖是一種適合讀多寫少的場景下解決線程安全問題的工具，基本原則是：
讀和讀不互斥、讀和寫互斥、寫和寫互斥。也就是說涉及到影響數據變化的操作都會存在互斥。 - StampedLock： stampedLock是JDK8引入的新的鎖機制，可以簡單認爲是讀寫鎖的一個改進版本，讀寫鎖雖然通過分離讀和寫的功能使得讀和讀之間可以完全併發，但是讀和寫是有衝突的，如果大量的讀線程存在，可能會引起寫線程的飢餓。stampedLock是一種樂觀的讀策略，使得樂觀鎖完全不會阻塞寫線程
ReentrantLock的簡單實用
如何在實際應用中使用ReentrantLock呢？我們通過一個簡單的demo來演示一下
public class Demo {
private static int count=0;
static Lock lock=new ReentrantLock();
public static void inc(){
lock.lock();
try {
Thread.sleep(1);
count++;
} catch (InterruptedException e) {
e.printStackTrace();
}finally{
lock.unlock();
}
}
這段代碼主要做一件事，就是通過一個靜態的incr()方法對共享變量count做連續遞增，在沒有加同步鎖的情況下多線程訪問這個方法一定會存在線程安全問題。所以用到了ReentrantLock來實現同步鎖，並且在finally語句塊中釋放鎖。
那麼我來引出一個問題，大家思考一下
多個線程通過lock競爭鎖時，當競爭失敗的鎖是如何實現等待以及被喚醒的呢?
什麼是AQS
aqs全稱爲AbstractQueuedSynchronizer，它提供了一個FIFO隊列，可以看成是一個用來實現同步鎖以及其他涉及到同步功能的核心組件，常見的有:ReentrantLock、CountDownLatch等。
AQS是一個抽象類，主要是通過繼承的方式來使用，它本身沒有實現任何的同步接口，僅僅是定義了同步狀態的獲取以及釋放的方法來提供自定義的同步組件。
可以這麼說，只要搞懂了AQS，那麼J.U.C中絕大部分的api都能輕鬆掌握。
AQS的兩種功能
從使用層面來說，AQS的功能分爲兩種：獨佔和共享
- 獨佔鎖，每次只能有一個線程持有鎖，比如前面給大家演示的ReentrantLock就是以獨佔方式實現的互斥鎖
- 共享鎖，允許多個線程同時獲取鎖，併發訪問共享資源，比如ReentrantReadWriteLock
ReentrantLock的類圖
仍然以ReentrantLock爲例，來分析AQS在重入鎖中的使用。畢竟單純分析AQS沒有太多的含義。先理解這個類圖，可以方便我們理解AQS的原理
AQS的內部實現
AQS的實現依賴內部的同步隊列(CLH),也就是FIFO的雙向隊列，如果當前線程競爭鎖失敗，那麼AQS會把當前線程以及等待狀態信息構造成一個Node加入到同步隊列中，同時再阻塞該線程。當獲取鎖的線程釋放鎖以後，會從隊列中喚醒一個阻塞的節點(線程)。
AQS隊列內部維護的是一個FIFO的雙向鏈表，這種結構的特點是每個數據結構都有兩個指針，分別指向直接的後繼節點和直接前驅節點。所以雙向鏈表可以從任意一個節點開始很方便的訪問前驅和後繼。每個Node其實是由線程封裝，當線程爭搶鎖失敗後會封裝成Node加入到ASQ隊列中去
Node類的組成如下
static final class Node {
static final Node SHARED = new Node();
static final Node EXCLUSIVE = null;
static final int CANCELLED = 1;
static final int SIGNAL = -1;
static final int CONDITION = -2;
static final int PROPAGATE = -3;
volatile int waitStatus;
volatile Node prev; //前驅節點
volatile Node next; //後繼節點
volatile Thread thread;//當前線程
Node nextWaiter; //存儲在condition隊列中的後繼節點
//是否爲共享鎖
final boolean isShared() {
return nextWaiter == SHARED;
}
final Node predecessor() throws NullPointerException {
Node p = prev;
if (p == null)
throw new NullPointerException();
else
return p;
}
Node() { // Used to establish initial head or SHARED marker
}
//將線程構造成一個Node，添加到等待隊列
Node(Thread thread, Node mode) { // Used by addWaiter
this.nextWaiter = mode;
this.thread = thread;
}
//這個方法會在Condition隊列使用，後續單獨寫一篇文章分析condition
Node(Thread thread, int waitStatus) { // Used by Condition
this.waitStatus = waitStatus;
this.thread = thread;
}
}
釋放鎖以及添加線程對於隊列的變化
添加節點
當出現鎖競爭以及釋放鎖的時候，AQS同步隊列中的節點會發生變化，首先看一下添加節點的場景。
這裏會涉及到兩個變化
- 新的線程封裝成Node節點追加到同步隊列中，設置prev節點以及修改當前節點的前置節點的next節點指向自己
- 通過CAS講tail重新指向新的尾部節點
釋放鎖移除節點
head節點表示獲取鎖成功的節點，當頭結點在釋放同步狀態時，會喚醒後繼節點，如果後繼節點獲得鎖成功，會把自己設置爲頭結點，節點的變化過程如下
這個過程也是涉及到兩個變化
- 修改head節點指向下一個獲得鎖的節點
- 新的獲得鎖的節點，將prev的指針指向null
這裏有一個小的變化，就是設置head節點不需要用CAS，原因是設置head節點是由獲得鎖的線程來完成的，而同步鎖只能由一個線程獲得，所以不需要CAS保證，只需要把head節點設置爲原首節點的後繼節點，並且斷開原head節點的next引用即可
AQS的源碼分析
清楚了AQS的基本架構以後，我們來分析一下AQS的源碼，仍然以ReentrantLock爲模型。
ReentrantLock的時序圖
調用ReentrantLock中的lock()方法，源碼的調用過程我使用了時序圖來展現
從圖上可以看出來，當鎖獲取失敗時，會調用addWaiter()方法將當前線程封裝成Node節點加入到AQS隊列，基於這個思路，我們來分析AQS的源碼實現
分析源碼
ReentrantLock.lock()
public void lock() {
sync.lock();
}
這個是獲取鎖的入口，調用sync這個類裏面的方法，sync是什麼呢？
abstract static class Sync extends AbstractQueuedSynchronizer
sync是一個靜態內部類，它繼承了AQS這個抽象類，前面說過AQS是一個同步工具，主要用來實現同步控制。我們在利用這個工具的時候，會繼承它來實現同步控制功能。
通過進一步分析，發現Sync這個類有兩個具體的實現，分別是NofairSync(非公平鎖),FailSync(公平鎖).
- 公平鎖 表示所有線程嚴格按照FIFO來獲取鎖
- 非公平鎖 表示可以存在搶佔鎖的功能，也就是說不管當前隊列上是否存在其他線程等待，新線程都有機會搶佔鎖
公平鎖和非公平鎖的實現上的差異，我會在文章後面做一個解釋，接下來的分析仍然以非公平鎖作爲主要分析邏輯。
NonfairSync.lock
final void lock() {
if (compareAndSetState(0, 1)) //通過cas操作來修改state狀態，表示爭搶鎖的操作
setExclusiveOwnerThread(Thread.currentThread());//設置當前獲得鎖狀態的線程
else
acquire(1); //嘗試去獲取鎖
}
這段代碼簡單解釋一下
- 由於這裏是非公平鎖，所以調用lock方法時，先去通過cas去搶佔鎖
- 如果搶佔鎖成功，保存獲得鎖成功的當前線程
- 搶佔鎖失敗，調用acquire來走鎖競爭邏輯
compareAndSetState
compareAndSetState的代碼實現邏輯如下
// See below for intrinsics setup to support this
return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}
這段代碼其實邏輯很簡單，就是通過cas樂觀鎖的方式來做比較並替換。上面這段代碼的意思是，如果當前內存中的state的值和預期值expect相等，則替換爲update。更新成功返回true，否則返回false. 這個操作是原子的，不會出現線程安全問題，這裏面涉及到Unsafe這個類的操作，一級涉及到state這個屬性的意義。 **state**
- 當state=0時，表示無鎖狀態
- 當state>0時，表示已經有線程獲得了鎖，也就是state=1，但是因爲ReentrantLock允許重入，所以同一個線程多次獲得同步鎖的時候，state會遞增，比如重入5次，那麼state=5。 而在釋放鎖的時候，同樣需要釋放5次直到state=0其他線程纔有資格獲得鎖
private volatile int state;需要注意的是：不同的AQS實現，state所表達的含義是不一樣的。
Unsafe
Unsafe類是在sun.misc包下，不屬於Java標準。但是很多Java的基礎類庫，包括一些被廣泛使用的高性能開發庫都是基於Unsafe類開發的，比如Netty、Hadoop、Kafka等；Unsafe可認爲是Java中留下的後門，提供了一些低層次操作，如直接內存訪問、線程調度等public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);這個是一個native方法， 第一個參數爲需要改變的對象，第二個爲偏移量(即之前求出來的headOffset的值)，第三個參數爲期待的值，第四個爲更新後的值
整個方法的作用是如果當前時刻的值等於預期值var4相等，則更新爲新的期望值 var5，如果更新成功，則返回true，否則返回false；
acquire
acquire是AQS中的方法，如果CAS操作未能成功，說明state已經不爲0，此時繼續acquire(1)操作,這裏大家思考一下，acquire方法中的1的參數是用來做什麼呢？如果沒猜中，往前面回顧一下state這個概念
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
這個方法的主要邏輯是
- 通過tryAcquire嘗試獲取獨佔鎖，如果成功返回true，失敗返回false
- 如果tryAcquire失敗，則會通過addWaiter方法將當前線程封裝成Node添加到AQS隊列尾部
- acquireQueued，將Node作爲參數，通過自旋去嘗試獲取鎖。
如果大家看過我寫的Synchronized源碼分析的文章，就應該能夠明白自旋存在的意義
NonfairSync.tryAcquire
這個方法的作用是嘗試獲取鎖，如果成功返回true，不成功返回false
它是重寫AQS類中的tryAcquire方法，並且大家仔細看一下AQS中tryAcquire方法的定義，並沒有實現，而是拋出異常。按照一般的思維模式，既然是一個不實現的模版方法，那應該定義成abstract，讓子類來實現呀？大家想想爲什麼
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
nonfairTryAcquire
tryAcquire(1)在NonfairSync中的實現代碼如下
ffinal boolean nonfairTryAcquire(int acquires) {
//獲得當前執行的線程
final Thread current = Thread.currentThread();
int c = getState(); //獲得state的值
if (c == 0) { //state=0說明當前是無鎖狀態
//通過cas操作來替換state的值改爲1，大家想想爲什麼要用cas呢？
//理由是，在多線程環境中，直接修改state=1會存在線程安全問題，你猜到了嗎？
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更新state狀態的值
- 如果當前線程是屬於重入，則增加重入次數
addWaiter
當tryAcquire方法獲取鎖失敗以後，則會先調用addWaiter將當前線程封裝成Node，然後添加到AQS隊列
private Node addWaiter(Node mode) { //mode=Node.EXCLUSIVE
//將當前線程封裝成Node，並且mode爲獨佔鎖
Node node = new Node(Thread.currentThread(), mode);
// Try the fast path of enq; backup to full enq on failure
// tail是AQS的中表示同步隊列隊尾的屬性，剛開始爲null，所以進行enq(node)方法
Node pred = tail;
if (pred != null) { //tail不爲空的情況，說明隊列中存在節點數據
node.prev = pred; //講當前線程的Node的prev節點指向tail
if (compareAndSetTail(pred, node)) {//通過cas講node添加到AQS隊列
pred.next = node;//cas成功，把舊的tail的next指針指向新的tail
return node;
}
}
enq(node); //tail=null，將node添加到同步隊列中
return node;
}
- 將當前線程封裝成Node
- 判斷當前鏈表中的tail節點是否爲空，如果不爲空，則通過cas操作把當前線程的node添加到AQS隊列
- 如果爲空或者cas失敗，調用enq將節點添加到AQS隊列
enq
enq就是通過自旋操作把當前節點加入到隊列中
private Node enq(final Node node) {
//自旋，不做過多解釋，不清楚的關注公衆號[架構師修煉寶典]
for (;;) {
Node t = tail; //如果是第一次添加到隊列，那麼tail=null
if (t == null) { // Must initialize
//CAS的方式創建一個空的Node作爲頭結點
if (compareAndSetHead(new Node()))
//此時隊列中只一個頭結點，所以tail也指向它
tail = head;
} else {
//進行第二次循環時，tail不爲null，進入else區域。將當前線程的Node結點的prev指向tail，然後使用CAS將tail指向Node
node.prev = t;
if (compareAndSetTail(t, node)) {
//t此時指向tail,所以可以CAS成功，將tail重新指向Node。此時t爲更新前的tail的值，即指向空的頭結點，t.next=node，就將頭結點的後續結點指向Node，返回頭結點
t.next = node;
return t;
}
}
}
}
假如有兩個線程t1,t2同時進入enq方法，t==null表示隊列是首次使用，需要先初始化
另外一個線程cas失敗，則進入下次循環，通過cas操作將node添加到隊尾
到目前爲止，通過addwaiter方法構造了一個AQS隊列，並且將線程添加到了隊列的節點中
acquireQueued
將添加到隊列中的Node作爲參數傳入acquireQueued方法，這裏面會做搶佔鎖的操作
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor();// 獲取prev節點,若爲null即刻拋出NullPointException
if (p == head && tryAcquire(arg)) {// 如果前驅爲head纔有資格進行鎖的搶奪
setHead(node); // 獲取鎖成功後就不需要再進行同步操作了,獲取鎖成功的線程作爲新的head節點
//凡是head節點,head.thread與head.prev永遠爲null, 但是head.next不爲null
p.next = null; // help GC
failed = false; //獲取鎖成功
return interrupted;
}
//如果獲取鎖失敗，則根據節點的waitStatus決定是否需要掛起線程
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())// 若前面爲true,則執行掛起,待下次喚醒的時候檢測中斷的標誌
interrupted = true;
}
} finally {
if (failed) // 如果拋出異常則取消鎖的獲取,進行出隊(sync queue)操作
cancelAcquire(node);
}
}
- 獲取當前節點的prev節點
- 如果prev節點爲head節點，那麼它就有資格去爭搶鎖，調用tryAcquire搶佔鎖
- 搶佔鎖成功以後，把獲得鎖的節點設置爲head，並且移除原來的初始化head節點
- 如果獲得鎖失敗，則根據waitStatus決定是否需要掛起線程
- 最後，通過cancelAcquire取消獲得鎖的操作
前面的邏輯都很好理解，主要看一下shouldParkAfterFailedAcquire這個方法和parkAndCheckInterrupt的作用
先提一下節點的waitStatus waitStatus
這裏我們說下Node。Node結點是對每一個等待獲取資源的線程的封裝，其包含了需要同步的線程本身及其等待狀態，如是否被阻塞、是否等待喚醒、是否已經被取消等。變量waitStatus則表示當前Node結點的等待狀態，共有5種取值CANCELLED、SIGNAL、CONDITION、PROPAGATE、0。
-
CANCELLED(1)：表示當前結點已取消調度。當timeout或被中斷（響應中斷的情況下），會觸發變更爲此狀態，進入該狀態後的結點將不會再變化。
-
SIGNAL(-1)：表示後繼結點在等待當前結點喚醒。後繼結點入隊時，會將前繼結點的狀態更新爲SIGNAL。
-
CONDITION(-2)：表示結點等待在Condition上，當其他線程調用了Condition的signal()方法後，CONDITION狀態的結點將從等待隊列轉移到同步隊列中，等待獲取同步鎖。
-
PROPAGATE(-3)：共享模式下，前繼結點不僅會喚醒其後繼結點，同時也可能會喚醒後繼的後繼結點。
-
0：新結點入隊時的默認狀態。tail節點總是0
注意，負值表示結點處於有效等待狀態，而正值表示結點已被取消。所以源碼中很多地方用>0、<0來判斷結點的狀態是否正常。
shouldParkAfterFailedAcquire
從上面的分析可以看出，只有隊列的第二個節點可以有機會爭用鎖，如果成功獲取鎖，則此節點晉升爲頭節點。對於第三個及以後的節點，if (p == head)條件不成立，首先進行shouldParkAfterFailedAcquire(p, node)操作
shouldParkAfterFailedAcquire方法是判斷一個爭用鎖的線程是否應該被阻塞。它首先判斷一個節點的前置節點的狀態是否爲Node.SIGNAL，如果是，是說明此節點已經將狀態設置爲:如果鎖釋放，則應當通知它，所以它可以安全的阻塞了，返回true。
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus; //前繼節點的狀態
if (ws == Node.SIGNAL)//如果是SIGNAL狀態，意味着當前線程需要被unpark喚醒
return true;
如果前節點的狀態大於0，即爲CANCELLED狀態時，則會從前節點開始逐步循環找到一個沒有被“CANCELLED”節點設置爲當前節點的前節點，返回false。在下次循環執行shouldParkAfterFailedAcquire時，返回true。這個操作實際是把隊列中CANCELLED的節點剔除掉。
if (ws > 0) {// 如果前繼節點是“取消”狀態，則設置 “當前節點”的 “當前前繼節點” 爲 “‘原前繼節點'的前繼節點”。
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else { // 如果前繼節點爲“0”或者“共享鎖”狀態，則設置前繼節點爲SIGNAL狀態。
/*
* 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;
}
整個流程中，如果前驅節點的狀態不是SIGNAL，那麼自己就不能安心去休息，需要去找個安心的休息點，同時可以再嘗試下看有沒有機會輪到自己拿號。
parkAndCheckInterrupt
如果shouldParkAfterFailedAcquire返回了true，則會執行：parkAndCheckInterrupt()方法，它是通過LockSupport.park(this)將當前線程掛起到WATING狀態，它需要等待一箇中斷、unpark方法來喚醒它，通過這樣一種FIFO的機制的等待，來實現了Lock的操作。
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);//調用park()使線程進入waiting狀態
return Thread.interrupted();//如果被喚醒，查看自己是不是被中斷的。
}
park()會讓當前線程進入waiting狀態。在此狀態下，有兩種途徑可以喚醒該線程：1）被unpark()；2）被interrupt()。。需要注意的是，Thread.interrupted()會清除當前線程的中斷標記位。
LockSupport
LockSupport類是Java6引入的一個類，提供了基本的線程同步原語。LockSupport實際上是調用了Unsafe類裏的函數，歸結到Unsafe裏，只有兩個函數：public native void unpark(Thread jthread); public native void park(boolean isAbsolute, long time);unpark函數爲線程提供“許可(permit)”，線程調用park函數則等待“許可”。這個有點像信號量，但是這個“許可”是不能疊加的，“許可”是一次性的。
permit相當於0/1的開關，默認是0，調用一次unpark就加1變成了1.調用一次park會消費permit，又會變成0。 如果再調用一次park會阻塞，因爲permit已經是0了。直到permit變成1.這時調用unpark會把permit設置爲1.每個線程都有一個相關的permit，permit最多隻有一個，重複調用unpark不會累積
鎖的釋放
ReentrantLock.unlock
加鎖的過程分析完以後，再來分析一下釋放鎖的過程，調用release方法，這個方法裏面做兩件事，1，釋放鎖 ；2，喚醒park的線程
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
這個動作可以認爲就是一個設置鎖狀態的操作，而且是將狀態減掉傳入的參數值（參數是1），如果結果狀態爲0，就將排它鎖的Owner設置爲null，以使得其它的線程有機會進行執行。
在排它鎖中，加鎖的時候狀態會增加1（當然可以自己修改這個值），在解鎖的時候減掉1，同一個鎖，在可以重入後，可能會被疊加爲2、3、4這些值，只有unlock()的次數與lock()的次數對應纔會將Owner線程設置爲空，而且也只有這種情況下才會返回true。
protected final boolean tryRelease(int releases) {
int c = getState() - releases; // 這裏是將鎖的數量減1
if (Thread.currentThread() != getExclusiveOwnerThread())// 如果釋放的線程和獲取鎖的線程不是同一個，拋出非法監視器狀態異常
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
// 由於重入的關係，不是每次釋放鎖c都等於0，
// 直到最後一次釋放鎖時，纔會把當前線程釋放
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}
unparkSuccessor
在方法unparkSuccessor(Node)中，就意味着真正要釋放鎖了，它傳入的是head節點（head節點是佔用鎖的節點），當前線程被釋放之後，需要喚醒下一個節點的線程
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) //然後從隊列尾部向前遍歷找到最前面的一個waitStatus小於0的節點, 至於爲什麼從尾部開始向前遍歷，因爲在doAcquireInterruptibly.cancelAcquire方法的處理過程中只設置了next的變化，沒有設置prev的變化，在最後有這樣一行代碼：node.next = node，如果這時執行了unparkSuccessor方法，並且向後遍歷的話，就成了死循環了，所以這時只有prev是穩定的
s = t;
}
//內部首先會發生的動作是獲取head節點的next節點，如果獲取到的節點不爲空，則直接通過：“LockSupport.unpark()”方法來釋放對應的被掛起的線程，這樣一來將會有一個節點喚醒後繼續進入循環進一步嘗試tryAcquire()方法來獲取鎖
if (s != null)
LockSupport.unpark(s.thread); //釋放許可
}
總結
通過這篇文章基本將AQS隊列的實現過程做了比較清晰的分析，主要是基於非公平鎖的獨佔鎖實現。在獲得同步鎖時，同步器維護一個同步隊列，獲取狀態失敗的線程都會被加入到隊列中並在隊列中進行自旋；移出隊列（或停止自旋）的條件是前驅節點爲頭節點且成功獲取了同步狀態。在釋放同步狀態時，同步器調用tryRelease(int arg)方法釋放同步狀態，然後喚醒頭節點的後繼節點。