ReentrantLock可重入鎖原始碼原理詳解
背景介紹
? AbstractQueuedSynchronizer是Doug Lea在JDK1.5的時候加入的一個同步框架,也被簡稱為AQS,該框架主要維護了被競爭資源的狀態,和獲取到資源的執行緒(通過AbstractOwnableSynchronizer來維護)以及未獲取到資源的執行緒的管理,AQS主要通過volatile的記憶體可見性和CAS來實作,具體的競爭資源的方式(公平、非公平)由子類實作,Doug Lea在引入該框架時提供了一系列已經實作好的子類,比如:ReentrantLock、ReentrantReadWriteLock,為了對使用者透明具體實作細節降低使用門檻,這兩個鎖本身并不繼承AQS,而是由內部類Sync繼承AQS并通過組合的方式實作鎖,
ReentrantLock介紹
? AQS實作了共享方式和排它方式,而ReentrantLock只對外暴露出了AQS的排它方式,所以ReentrantLock也叫做排它鎖,在這個基礎上ReentrantLock又通過兩個內部類(FairSync、NonfairSync)間接繼承了AQS分別實作了公平鎖、非公平鎖,

ReentrantLock與synchronized對比
1. 競爭鎖標識
? synchronized: 執行緒通過獲取某個物件的Monitor的所有權
? ReentrantLock: 執行緒通過修改AQS中的被volatile修飾的int型別的state變數
2. 搶到鎖標識的執行緒以及未搶到鎖標識的執行緒維護
? synchronized: 不清楚具體實作(跟Monitor Record有關),不了解JVM是如何維護的,
? ReentrantLock: 通過AQS的基類AbstractOwnableSynchronizer中的一個成員變數來記錄獲取到資源的執行緒,并把為獲取到鎖標識的執行緒維護在一個FIFO的佇列中,
? Monitor Record內部結構:
| Monitor Record | |
|---|---|
| Owner | 初始時為NULL表示當前沒有任何執行緒擁有該monitor record,當執行緒成功擁有該鎖后保存執行緒唯一標識,當鎖被釋放時又設定為NULL; |
| EntryQ | 關聯一個系統互斥鎖(semaphore),阻塞所有試圖鎖住monitor record失敗的執行緒, |
| RcThis | 表示blocked或waiting在該monitor record上的所有執行緒的個數, |
| Nest | 用來實作重入鎖的計數, |
| HashCode | 保存從物件頭拷貝過來的HashCode值(可能還包含GC age), |
| Candidate | 用來避免不必要的阻塞或等待執行緒喚醒,因為每一次只有一個執行緒能夠成功擁有鎖,如果每次前一個釋放鎖的執行緒喚醒所有正在阻塞或等待的執行緒,會引起不必要的背景關系切換(從阻塞到就緒然后因為競爭鎖失敗又被阻塞)從而導致性能嚴重下降,Candidate只有兩種可能的值0表示沒有需要喚醒的執行緒1表示要喚醒一個繼任執行緒來競爭鎖, |
3. 執行緒通信
synchronized: 通過某個物件的wait()、notify()、notifyAll()方法來實作, 注: 該方法需要在synchronized 陳述句塊中呼叫否則會拋IllegalMonitorStateException例外,
ReentrantLock:通過await()、signal()、signalAll()方法來實作(區別于wait()、notify()、notifyAll()), 注: 該方法需要在ReentrantLock呼叫lock()方法后,unlock()方法前呼叫,否則會拋IllegalMonitorStateException例外,
4. 未搶到鎖標識的執行緒狀態
synchronized: 執行緒處于BLOCKED狀態,
ReentrantLock: 執行緒處于WAITING狀態,
下文證明
5.鎖型別
synchronized: 只有非公平鎖實作,
ReentrantLock: 既有非公平鎖又有公平鎖,默認為非公平鎖,
ReentrantLock(非公平鎖)實作原始碼
首先看一下ReentrantLock的建構式:
public ReentrantLock() {
sync = new NonfairSync();
}
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
1.獲取鎖(采用模板方法模式)
獲取鎖的程序主要采用模板方法模式,流程看起來感徑訓有點亂,
-
獲取鎖的入口是ReentrantLock類中的lock()方法,該方法會呼叫內部抽象類的lock()方法
public void lock() { sync.lock(); //sync為ReentrantLock的內部抽象類繼承AQS } -
內部抽象類Sync的lock()方法為抽象方法,該方法的具體實作由ReentrantLock的內部類NonfairSync實作
abstract void lock(); -
ReentrantLock的lock()方法最終實作是在NonfairSync的lock()方法,一進入該方法先去競爭鎖標識,這里也是非公平的原因之一,
final void lock() { if (compareAndSetState(0, 1)) setExclusiveOwnerThread(Thread.currentThread()); else acquire(1); }① 獲取鎖的時候先通過CAS競爭鎖標識,如果成功把AQS中的state成員變數從0修改為1就認為自己(當前執行緒)成功,(方法簡單不展開)
② 獲取到鎖標識并記錄到AbstractOwnableSynchronizer中的成員變數exclusiveOwnerThread中,執行緒繼續向下執行,(方法簡單不展開)
③ 如果①失敗表示該執行緒未獲取到鎖標識則進入AQS的acquire()方法,
-
AQS的acquire()方法
public final void acquire(int arg) { //該方法采用模板方法模式 if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt(); }該方法采用模板方法模式,其中tryAcquire()方法嘗試獲取鎖標識具體實作由子類實作,如果獲取鎖標識成功執行緒繼續向下執行,如果獲取失敗,執行緒將會進入等待狀態(不是阻塞狀態跟synchronized不同,如下圖),然后將該執行緒構建成一個獨占式的節點放到佇列中進行維護,
如圖(分析兩個執行緒通過ReentrantLock鎖成功和失敗的執行緒狀態):
示例代碼:
public static void main(String[] args) throws ExecutionException, InterruptedException { ReentrantLock reentrantLock = new ReentrantLock(); Thread t1 = new Thread(new Runnable() { @Override public void run() { try { reentrantLock.lock(); while (true) { } } finally { reentrantLock.unlock(); } } }, "T1"); t1.start(); Thread t2 = new Thread(new Runnable() { @Override public void run() { try { reentrantLock.lock(); while (true) { } } finally { reentrantLock.unlock(); } } }, "T2"); t2.start(); t1.join(); t2.join(); }上述事例代碼很簡單,兩個執行緒進行爭搶同一把鎖,然后通過jstack分析T1、T2執行緒所處的狀態:

可以清晰的看到T1執行緒獲取到了鎖標識處于RUNNABLE(JVM將作業系統的READY就緒狀態和RUNNING運行中狀態合并為RUNNABLE狀態)狀態,T2執行緒并未獲取到鎖標識處于WAITING狀態(并不是BLOCKED狀態原因是因為底層呼叫LockSupport.park()方法),
-
如果競爭鎖標識失敗將會進入addWaiter(Node.EXCLUSIVE)方法:
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; }該方法把當前執行緒構建成一個獨占式的Node節點放到FIFO佇列中,該方法先判斷隊尾是否為空,如果不為空通過CAS將該執行緒的節點放到隊尾然后回傳若CAS失敗則進入enq()方法,如果隊尾為空則證明該佇列尚未初始化,則進入enq()方法初始化佇列并將該節點放入佇列中,具體向下看enq()方法實作,
-
enq()方法分析:
private Node enq(final Node node) { for (;;) { Node t = tail; if (t == null) { // Must initialize if (compareAndSetHead(new Node())) tail = head; } else { node.prev = t; if (compareAndSetTail(t, node)) { t.next = node; return t; } } } }可以看到該方法是個死回圈(CAS的失敗重試),用來保證該執行緒節點放入隊尾,第一個判斷用來判斷該佇列是否已經初始化過,若尚未初始化則先進性初始化操作,然后在通過CAS失敗重試將該節點放入隊尾并回傳,
-
再繼續分析將該節點放入佇列中的后續操作,將會執行acquireQueued()方法:
final boolean acquireQueued(final Node node, int arg) { boolean failed = true; try { boolean interrupted = false; for (;;) { final Node p = node.predecessor(); //獲取該節點的父節點 if (p == head && tryAcquire(arg)) { setHead(node); p.next = null; // help GC failed = false; return interrupted; } if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) //主要呼叫LockSupport.park()方法阻塞當前執行緒,并在當前執行緒醒來時重 置該執行緒的中斷標志位 interrupted = true; } } finally { if (failed) cancelAcquire(node); } }
① 首先該方法將會進入一個死回圈,如果該節點的父節點是對頭(只有對頭的節點才持有鎖標識),如果該節點的父節點是頭結點則證明該節點可能(下文宏觀獲取鎖流程講解為什么是可能) 馬上就可以獲取到鎖標識了,進行tryAcquire()嘗試獲取鎖標識,如果獲取成功,把該節點設定為頭結點,并回傳false(主要是回傳一個暗號,不讓當前執行緒設定中斷標識[下文講解執行緒中斷]),
② 如果該節點的父節點不是頭結點(說明下一個獲取到鎖的執行緒一定不是他),或者是頭結點但是競爭鎖標識失敗了(下文宏觀獲取鎖流程講解為什么會失敗),將會進入shouldParkAfterFailedAcquire()方法,該方法主要判斷該節點是否可以安全的進行阻塞,還有其他處理邏輯,如果可以安全阻塞將會(觸發LockSupport.park()方法進入WAITING狀態)阻塞該執行緒,
③ 可以發現上述流程發生在一個死回圈中,一般情況會等到獲取到鎖標識后正常回傳,不過肯能存在幾種情況在為獲取到鎖之后就回傳了,不如執行緒取消,等待超時,將會進入cancelAcquire()方法(該方法還沒來得及好好看,好像主要是針對這些未正常獲取到鎖就回傳的執行緒的處理以及對存放執行緒Node節點的佇列的一些維護操作),
④ 正常回傳的情況下會回傳true或者false,如果回傳false證明該執行緒并沒有進入WAITING狀態,如果回傳true則說明該執行緒進入過WAITING狀態并在蘇醒時對執行緒的中斷標志位進行置位,后續操作會根據這個回傳結果對該執行緒的中斷標志位進行相應的設定,
注:執行緒中斷標志位好像在本流程中沒用,好像在其他流程中用到了,比如tryAcquireNanos()方法,該方法好像會相應執行緒中斷,
-
還有一個重要的方法就是tryAcquire()方法:
protected final boolean tryAcquire(int acquires) { return nonfairTryAcquire(acquires); }final boolean nonfairTryAcquire(int acquires) { final Thread current = Thread.currentThread(); int c = getState(); if (c == 0) { 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; }該方法很重要很多地方都用到了,但是也很簡單,
① 首先獲取當前執行緒,并且獲取鎖標識的值(0標識沒有執行緒持有鎖),
② 當鎖標識為0的時候標識沒有執行緒持有鎖,使用CAS競爭鎖標識,如果競爭成功則把當前執行緒記錄到AbstractOwnableSynchronizer的成員變數中,
③ 如果鎖標識不為0,則說明有執行緒持有該鎖,然后判斷持有鎖的執行緒是否是當前執行緒,如果是則將鎖標識位+1(這就是為什么說ReentrantLock是一把可重入鎖),
獲取鎖(非公平鎖)的流程結束,釋放鎖的流程很簡單,大家有興趣可以自己去看原始碼(實在是不想寫了)
執行緒中斷
個人理解:執行緒中斷是一種執行緒間進行通信的方式之一,他本身是執行緒的一個屬性,用來標識其他執行緒(也可以是他本身)給該執行緒(運行中)的中斷標識位設定值(好像是一個boolean值),相當于其他執行緒給該執行緒發送的一個訊息,
注:該執行緒必須處于運行中才能收到該執行緒的中斷訊息,比如該執行緒處于WAITING狀態無法收到中斷訊息,
宏觀獲取鎖流程
首先看一下公平鎖和非公平鎖表現的結果:
測驗代碼:
public class ReentrantLockTest {
//需要繼承ReentrantLock把getQueuedThreads()方法暴露出來
public class MyReentrantLock extends ReentrantLock{
public MyReentrantLock(boolean fair) {
super(fair);
}
@Override
public Collection<Thread> getQueuedThreads() {
List<Thread> list = new ArrayList<>(super.getQueuedThreads());
//由于是逆序輸出的所以進行翻轉,不信可以看輸入執行緒佇列的原始碼
Collections.reverse(list);
return list;
}
}
public static class Job extends Thread{
public MyReentrantLock reentrantLock;
public Job(MyReentrantLock reentrantLock){
this.reentrantLock = reentrantLock;
}
@Override
public void run() {
for (int i = 0; i < 2; i++){
reentrantLock.lock();
List<String> collect = reentrantLock.getQueuedThreads().stream().map(e -> {
return e.getName();
}).collect(Collectors.toList());
System.out.println("當前執行緒:"+Thread.currentThread().getName()+",阻塞佇列執行緒:"+collect);
try {
TimeUnit.MILLISECONDS.sleep(20);
}catch (Exception e){}
reentrantLock.unlock();
}
}
}
@Test //非公平鎖測驗
public void testNotFair() throws InterruptedException {
MyReentrantLock myReentrantLock = new MyReentrantLock(false);
for (int i=0;i<5;i++){
Job job = new Job(myReentrantLock);
job.setName(i+"");
job.start();
}
Thread.currentThread().join(2000);
}
@Test //公平鎖測驗
public void testFair() throws InterruptedException {
MyReentrantLock myReentrantLock = new MyReentrantLock(true);
for (int i=0;i<5;i++){
Job job = new Job(myReentrantLock);
job.setName(i+"");
job.start();
}
Thread.currentThread().join(2000);
}
}
結果:
非公平鎖testNotFair():

公平鎖testFair():

對比結果可以看到如下結果:
非公平鎖:每當一個執行緒搶到鎖之后,再來的其他執行緒將會進入到FIFO的佇列中進行排隊,當獲取到鎖的執行緒釋放鎖之后,本應該佇列中的下一個節點執行緒獲取鎖,但是如果有新執行緒(沒有在佇列中的執行緒)來搶鎖,那么新執行緒將會和佇列中的頭結點的下一個執行緒爭搶鎖標識,這就是表現出來的不公平的地方,但是仔細觀察結果會發現不公平中也存在的公平,只要執行緒進入佇列中之后,將會在佇列中按照先進先出的順序進行獲取鎖,
公平鎖:每當一個執行緒搶到鎖之后,再來的其他執行緒不會嘗試搶鎖,先回去判斷執行緒佇列中是否還有執行緒在進行排隊獲取鎖,如果有自己將會去佇列中排隊獲取鎖,從結果來看,執行緒0釋放鎖之后將會去佇列末尾排隊,執行緒1釋放鎖后同樣回去排隊,以此類推,
這就解決了上述的問題,如果本文章有什么不對或者不合理的地方,希望大佬指正,
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/94588.html
標籤:其他
