香蕉午夜,老司机精品99在线播放,国产特级毛片aaaaaaa高清

從ReentrantLock的角度思考AQS

我們上一篇簡單介紹了AQS這個技術點，這一篇我們從ReentrantLock這個鎖的角度來分析AQS，幫助大家理解

首先，我們先看一下ReentrantLock的內部的抽象類Sync，這個是繼承于AQS的，重寫了其中的一些方法，我們會在下面源碼中解析，繼續往下看，記住這個Sync

從ReentrantLock的角度思考AQS

我們知道這個鎖可以實現公平鎖和非公平鎖，我們來看下是如何實現的

/**
* Sync object for non-fair locks
*/
static final class NonfairSync extends Sync {
private static final long serialVersionUID = 7316153563782823691L;
/**
* Performs lock. Try immediate barge, backing up to normal
* acquire on failure.
*/
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
}
/**
* Sync object for fair locks
*/
static final class FairSync extends Sync {
private static final long serialVersionUID = -3000897897090466540L;
final void lock() {
acquire(1);
}}

上面的是非公平鎖，下面的是公平鎖，默認的是非公平鎖，我們看下非公平鎖的實現是先通過CAS的方式去加鎖，加鎖成功之后就將當前線程設置為活躍的持有鎖的線程

/**
* The current owner of exclusive mode synchronization.
*/
private transient Thread exclusiveOwnerThread;

失敗的話會執行acquire方法，OK，這里我們再看下公平鎖FairSync的lock方法的實現，這個公平鎖沒有像上面非公平鎖那樣判斷，而是直接調用了acquire方法

這里大家應該也懂了非公平鎖和公平鎖的真正區別了吧，就是非公平鎖的時候，線程來的時候會多一次直接嘗試加鎖，剩下的操作就是一樣了

OK，讓我們進去acquire方法看

從ReentrantLock的角度思考AQS

看一下tryAcquire方法

從ReentrantLock的角度思考AQS

可以看出，這里只是AQS的簡單實現，具體獲取鎖的實現方法是由各自的公平鎖和非公平鎖單獨實現的(以ReentrantLock為例)

如果該方法返回了True，則說明當前線程獲取鎖成功，就不用往后執行了;如果獲取失敗，就需要加入到等待隊列中。下面會詳細解釋線程是何時以及怎樣被加入進等待隊列中的。

OK，知道了這個我們就得看看ReentrantLock是如何實現tryAcquire方法的

老規矩，先看一下非公平鎖中的具體實現

從ReentrantLock的角度思考AQS

大家看代碼應該也比較好理解，第一步先判斷state==0，這個0也就意味著這個共享資源處于空閑狀態，于是這里就會先嘗試去搶一下鎖，假如此時等待隊列中有等待線程，則就是等待線程中的第二個節點和這個新加入的這個線程去搶這個鎖了

為什么是第二個，因為第一個head節點存儲的永遠是占用鎖的線程節點Node

接下來就是判斷當前持有鎖的線程和當前線程是否是同一個，如果是同一個，則將state+1，這里就是ReentrantLock支持重入性的關鍵，到時候解鎖的時候也是通過減去這個state計數的

搶到鎖或者重入鎖，都會返回true，返回true，加鎖方法就直接加鎖了

從ReentrantLock的角度思考AQS

如果既沒搶到鎖，又發現占用鎖的線程不是當前線程，則返回false，繼續執行

上面這是非公平鎖的tryAcquire方法，接下來咱再看這個公平鎖的tryAcquire方法

從ReentrantLock的角度思考AQS

這個也是先判斷狀態是否為0，這個的==0之后的處理邏輯就很明了了，直接通過hasQueuedPredecessors方法判斷隊列中是否有等待的節點，如果沒有等待的節點，則直接通過CAS的方式進行判斷，然后就是把當前線程設置為活躍線程

如果有等待的節點，就會跳過CAS的判斷，緊接著會去判斷當前線程和持有鎖的線程是否是同一個線程，如果是同一個線程，還是進行計數+1，滿足可重入性

不是就返回false，此時tryAcquire方法返回false

此時，我們再把視角拉回到acquire方法

從ReentrantLock的角度思考AQS

返回false之后，則會執行addWaiter方法和acquireQueued方法

從ReentrantLock的角度思考AQS

這段代碼首先會創建一個和當前線程綁定的Node節點，Node為雙向鏈表。此時等待對內中的tail指針為空，直接調用enq(node)方法將當前線程加入等待隊列尾部：

從ReentrantLock的角度思考AQS

第一遍循環時tail指針為空，進入if邏輯，使用CAS操作設置head指針，將head指向一個新創建的Node節點。

此時AQS中數據：

從ReentrantLock的角度思考AQS

執行完成之后，head、tail、t都指向第一個Node元素。

接著執行第二遍循環，進入else邏輯，此時已經有了head節點，這里要操作的就是將線程二對應的Node節點掛到head節點后面。此時隊列中就有了兩個Node節點：

從ReentrantLock的角度思考AQS

addWaiter()方法執行完后，會返回當前線程創建的節點信息。繼續往后執行acquireQueued(addWaiter(Node.EXCLUSIVE), arg)邏輯，此時傳入的參數為線程二對應的Node節點信息

從ReentrantLock的角度思考AQS

acquireQueued()這個方法會先判斷當前傳入的Node對應的前置節點是否為head，如果是則嘗試加鎖。

加鎖成功過則將當前節點設置為head節點，然后空置之前的head節點，方便后續被垃圾回收掉。

如果加鎖失敗或者Node的前置節點不是head節點，就會通過shouldParkAfterFailedAcquire方法將head節點的waitStatus變為了SIGNAL=-1，最后執行parkAndChecknIterrupt方法，調用LockSupport.park()掛起當前線程。

我們不能發現的一點，就是AQS的設計內部，包括ReentrantLock的設計內部。很多地方都會嘗試用CAS的方式去加鎖，就是因為在高速的運轉下，可能在幾行代碼的時間一個線程就已經用完鎖了，這樣可以最高效率的來利用資源

parkAndCheckInterrupt主要用于掛起當前線程，阻塞調用棧，返回當前線程的中斷狀態。

給大家看個這里的流程圖，圖片來源于網絡，覺得挺不錯

從ReentrantLock的角度思考AQS

從上圖可以看出，跳出當前循環的條件是當“前置節點是頭結點，且當前線程獲取鎖成功”。

為了防止因死循環導致CPU資源被浪費，我們會判斷前置節點的狀態來決定是否要將當前線程掛起，具體掛起流程用流程圖表示如下(shouldParkAfterFailedAcquire流程)：

從ReentrantLock的角度思考AQS

acquireQueued中最后的finally中，如果失敗，則執行cancelAcquire

獲取當前節點的前驅節點，如果前驅節點的狀態是CANCELLED，那就一直往前遍歷，找到第一個waitStatus <= 0的節點，將找到的Pred節點和當前Node關聯，將當前Node設置為CANCELLED。

但是為什么所有的變化都是對Next指針進行了操作，而沒有對Prev指針進行操作呢?什么情況下會對Prev指針進行操作?

執行cancelAcquire的時候，當前節點的前置節點可能已經從隊列中出去了(已經執行過Try代碼塊中的shouldParkAfterFailedAcquire方法了)，如果此時修改Prev指針，有可能會導致Prev指向另一個已經移除隊列的Node，因此這塊變化Prev指針不安全。

shouldParkAfterFailedAcquire方法中，會執行下面的代碼，其實就是在處理Prev指針。shouldParkAfterFailedAcquire是獲取鎖失敗的情況下才會執行，進入該方法后，說明共享資源已被獲取，當前節點之前的節點都不會出現變化，因此這個時候變更Prev指針比較安全。