一篇文章，徹底理解ReentrantLock

本人免費整理了Java高級資料，涵蓋了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高并發分布式等教程，一共30G，需要自己領取。
傳送門：https://mp.weixin.qq.com/s/JzddfH-7yNudmkjT0IRL8Q

1. ReentrantLock的介紹

ReentrantLock重入鎖，是實現Lock接口的一個類，也是在實際編程中使用頻率很高的一個鎖，支持重入性，表示能夠對共享資源能夠重復加鎖，即當前線程獲取該鎖再次獲取不會被阻塞。在java關鍵字synchronized隱式支持重入性，synchronized通過獲取自增，釋放自減的方式實現重入。與此同時，ReentrantLock還支持公平鎖和非公平鎖兩種方式。那么，要想完完全全的弄懂ReentrantLock的話，主要也就是ReentrantLock同步語義的學習：1. 重入性的實現原理；2. 公平鎖和非公平鎖。

2. 重入性的實現原理

要想支持重入性，就要解決兩個問題：**1. 在線程獲取鎖的時候，如果已經獲取鎖的線程是當前線程的話則直接再次獲取成功；2. 由于鎖會被獲取n次，那么只有鎖在被釋放同樣的n次之后，該鎖才算是完全釋放成功，我們知道，同步組件主要是通過重寫AQS的幾個protected方法來表達自己的同步語義。針對第一個問題，我們來看看ReentrantLock是怎樣實現的，以非公平鎖為例，判斷當前線程能否獲得鎖為例，核心方法為nonfairTryAcquire：

final?boolean?nonfairTryAcquire(int?acquires)?{
????final?Thread?current?=?Thread.currentThread();
????int?c?=?getState();
????//1\.?如果該鎖未被任何線程占有，該鎖能被當前線程獲取
????if?(c?==?0)?{
????????if?(compareAndSetState(0,?acquires))?{
????????????setExclusiveOwnerThread(current);
????????????return?true;
????????}
????}
????//2.若被占有，檢查占有線程是否是當前線程
????else?if?(current?==?getExclusiveOwnerThread())?{
????????//?3\.?再次獲取，計數加一
????????int?nextc?=?c?+?acquires;
????????if?(nextc?<?0)?//?overflow
????????????throw?new?Error("Maximum?lock?count?exceeded");
????????setState(nextc);
????????return?true;
????}
????return?false;}

這段代碼的邏輯也很簡單，具體請看注釋。為了支持重入性，在第二步增加了處理邏輯，如果該鎖已經被線程所占有了，會繼續檢查占有線程是否為當前線程，如果是的話，同步狀態加1返回true，表示可以再次獲取成功。每次重新獲取都會對同步狀態進行加一的操作，那么釋放的時候處理思路是怎樣的了？（依然還是以非公平鎖為例）核心方法為tryRelease：

protected?final?boolean?tryRelease(int?releases)?{
????//1\.?同步狀態減1
????int?c?=?getState()?-?releases;
????if?(Thread.currentThread()?!=?getExclusiveOwnerThread())
????????throw?new?IllegalMonitorStateException();
????boolean?free?=?false;
????if?(c?==?0)?{
????????//2\.?只有當同步狀態為0時，鎖成功被釋放，返回true
????????free?=?true;
????????setExclusiveOwnerThread(null);
????}
????//?3\.?鎖未被完全釋放，返回false
????setState(c);
????return?free;}

代碼的邏輯請看注釋，需要注意的是，重入鎖的釋放必須得等到同步狀態為0時鎖才算成功釋放，否則鎖仍未釋放。如果鎖被獲取n次，釋放了n-1次，該鎖未完全釋放返回false，只有被釋放n次才算成功釋放，返回true。到現在我們可以理清ReentrantLock重入性的實現了，也就是理解了同步語義的第一條。

3. 公平鎖與公平鎖

ReentrantLock支持兩種鎖：公平鎖和非公平鎖。何謂公平性，是針對獲取鎖而言的，如果一個鎖是公平的，那么鎖的獲取順序就應該符合請求上的絕對時間順序，滿足FIFO。ReentrantLock的構造方法無參時是構造非公平鎖，源碼為：

public?ReentrantLock()?{
????sync?=?new?NonfairSync();}

另外還提供了另外一種方式，可傳入一個boolean值，true時為公平鎖，false時為非公平鎖，源碼為：

public?ReentrantLock(boolean?fair)?{
????sync?=?fair???new?FairSync()?:?new?NonfairSync();}

在上面非公平鎖獲取時（nonfairTryAcquire方法）只是簡單的獲取了一下當前狀態做了一些邏輯處理，并沒有考慮到當前同步隊列中線程等待的情況。我們來看看公平鎖的處理邏輯是怎樣的，核心方法為：

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;
??}}

這段代碼的邏輯與nonfairTryAcquire基本上一直，唯一的不同在于增加了hasQueuedPredecessors的邏輯判斷，方法名就可知道該方法用來判斷當前節點在同步隊列中是否有前驅節點的判斷，如果有前驅節點說明有線程比當前線程更早的請求資源，根據公平性，當前線程請求資源失敗。如果當前節點沒有前驅節點的話，再才有做后面的邏輯判斷的必要性。公平鎖每次都是從同步隊列中的第一個節點獲取到鎖，而非公平性鎖則不一定，有可能剛釋放鎖的線程能再次獲取到鎖。

公平鎖 VS 非公平鎖

1. 公平鎖每次獲取到鎖為同步隊列中的第一個節點，保證請求資源時間上的絕對順序，而非公平鎖有可能剛釋放鎖的線程下次繼續獲取該鎖，則有可能導致其他線程永遠無法獲取到鎖，造成“饑餓”現象。

2. 公平鎖為了保證時間上的絕對順序，需要頻繁的上下文切換，而非公平鎖會降低一定的上下文切換，降低性能開銷。因此，ReentrantLock默認選擇的是非公平鎖，則是為了減少一部分上下文切換，保證了系統更大的吞吐量。