Java 重入锁 ReentrantLock 原理分析
1.簡介
可重入鎖ReentrantLock自 JDK 1.5 被引入，功能上與synchronized關(guān)鍵字類似。所謂的可重入是指，線程可對同一把鎖進(jìn)行重復(fù)加鎖，而不會(huì)被阻塞住，這樣可避免死鎖的產(chǎn)生。ReentrantLock 的主要功能和 synchronized 關(guān)鍵字一致，均是用于多線程的同步。但除此之外，ReentrantLock 在功能上比 synchronized 更為豐富。比如 ReentrantLock 在加鎖期間，可響應(yīng)中斷，可設(shè)置超時(shí)等。
ReentrantLock 是我們?nèi)粘Ｊ褂煤茴l繁的一種鎖，所以在使用之余，我們也應(yīng)該去了解一下它的內(nèi)部實(shí)現(xiàn)原理。ReentrantLock 內(nèi)部是基于 AbstractQueuedSynchronizer（以下簡稱AQS）實(shí)現(xiàn)的。所以要想理解 ReentrantLock，應(yīng)先去 AQS 相關(guān)原理。我在之前的文章?AbstractQueuedSynchronizer 原理分析 - 獨(dú)占/共享模式中，已經(jīng)詳細(xì)分析過 AQS 原理，有興趣的朋友可以去看看。本文僅會(huì)在需要的時(shí)候?qū)?AQS 相關(guān)原理進(jìn)行簡要說明，更詳細(xì)的說明請參考我的其他文章。
?2.原理
本章將會(huì)簡單介紹重入鎖 ReentrantLock 中的一些概念和相關(guān)原理，包括可重入、公平和非公平鎖等原理。在介紹這些原理前，首先我會(huì)介紹 ReentrantLock 與 synchronized 關(guān)鍵字的相同和不同之處。在此之后才回去介紹重入、公平和非公平等原理。
?2.1 與 synchronized 的異同
ReentrantLock 和 synchronized 都是用于線程的同步控制，但它們在功能上來說差別還是很大的。對比下來 ReentrantLock 功能明顯要豐富的多。下面簡單列舉一下兩者之間的差異，如下：
| 可重入 | 是 | 是 | ? |
| 響應(yīng)中斷 | 否 | 是 | ? |
| 超時(shí)等待 | 否 | 是 | ? |
| 公平鎖 | 否 | 是 | ? |
| 非公平鎖 | 是 | 是 | ? |
| 是否可嘗試加鎖 | 否 | 是 | ? |
| 是否是Java內(nèi)置特性 | 是 | 否 | ? |
| 自動(dòng)獲取/釋放鎖 | 是 | 否 | ? |
| 對異常的處理 | 自動(dòng)釋放鎖 | 需手動(dòng)釋放鎖 | ? |
除此之外，ReentrantLock 提供了豐富的接口用于獲取鎖的狀態(tài)，比如可以通過isLocked()查詢 ReentrantLock 對象是否處于鎖定狀態(tài), 也可以通過getHoldCount()獲取 ReentrantLock 的加鎖次數(shù)，也就是重入次數(shù)等。而 synchronized 僅支持通過Thread.holdsLock查詢當(dāng)前線程是否持有鎖。另外，synchronized 使用的是對象或類進(jìn)行加鎖，而 ReentrantLock 內(nèi)部是通過 AQS 中的同步隊(duì)列進(jìn)行加鎖，這一點(diǎn)和 synchronized 也是不一樣的。
這里列舉了不少兩者的相同和不同之處，暫時(shí)這能想到這些。如果還有其他的區(qū)別，歡迎補(bǔ)充。
?2.2 可重入
可重入這個(gè)概念并不難理解，本節(jié)通過一個(gè)例子簡單說明一下。
現(xiàn)在有方法 m1 和 m2，兩個(gè)方法均使用了同一把鎖對方法進(jìn)行同步控制，同時(shí)方法 m1 會(huì)調(diào)用 m2。線程 t 進(jìn)入方法 m1 成功獲得了鎖，此時(shí)線程 t 要在沒有釋放鎖的情況下，調(diào)用 m2 方法。由于 m1 和 m2 使用的是同一把可重入鎖，所以線程 t 可以進(jìn)入方法 m2，并再次獲得鎖，而不會(huì)被阻塞住。示例代碼大致如下：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | void m1() {lock.lock();try {// 調(diào)用 m2，因?yàn)榭芍厝?#xff0c;所以并不會(huì)被阻塞m2();} finally {lock.unlock()} }void m2() {lock.lock();try {// do something} finally {lock.unlock()} } |
假如 lock 是不可重入鎖，那么上面的示例代碼必然會(huì)引起死鎖情況的發(fā)生。這里請大家思考一個(gè)問題，ReentrantLock 的可重入特性是怎樣實(shí)現(xiàn)的呢？簡單說一下，ReentrantLock 內(nèi)部是通過 AQS 實(shí)現(xiàn)同步控制的，AQS 有一個(gè)變量 state 用于記錄同步狀態(tài)。初始情況下，state = 0，表示 ReentrantLock 目前處于解鎖狀態(tài)。如果有線程調(diào)用 lock 方法進(jìn)行加鎖，state 就由0變?yōu)?，如果該線程再次調(diào)用 lock 方法加鎖，就讓其自增，即 state++。線程每調(diào)用一次 unlock 方法釋放鎖，會(huì)讓 state–。通過查詢 state 的數(shù)值，即可知道 ReentrantLock 被重入的次數(shù)了。這就是可重復(fù)特性的大致實(shí)現(xiàn)流程。
?2.3 公平與非公平
公平與非公平指的是線程獲取鎖的方式。公平模式下，線程在同步隊(duì)列中通過 FIFO 的方式獲取鎖，每個(gè)線程最終都能獲取鎖。在非公平模式下，線程會(huì)通過“插隊(duì)”的方式去搶占鎖，搶不到的則進(jìn)入同步隊(duì)列進(jìn)行排隊(duì)。默認(rèn)情況下，ReentrantLock 使用的是非公平模式獲取鎖，而不是公平模式。不過我們也可通過 ReentrantLock 構(gòu)造方法ReentrantLock(boolean fair)調(diào)整加鎖的模式。
既然既然有兩種不同的加鎖模式，那么他們有什么優(yōu)缺點(diǎn)呢？答案如下：
公平模式下，可保證每個(gè)線程最終都能獲得鎖，但效率相對比較較低。非公平模式下，效率比較高，但可能會(huì)導(dǎo)致線程出現(xiàn)饑餓的情況。即一些線程遲遲得不到鎖，每次即將到手的鎖都有可能被其他線程搶了。這里再提個(gè)問題，為啥非公平模式搶了其他線程獲取鎖的機(jī)會(huì)，而整個(gè)程序的運(yùn)行效率會(huì)更高呢？說實(shí)話，開始我也不明白。不過好在《Java并發(fā)編程實(shí)戰(zhàn)》在第13.3節(jié) 公平性（p232）說明了具體的原因，這里引用一下：
在激烈競爭的情況下，非公平鎖的性能高于公平鎖的性能的一個(gè)原因是：在恢復(fù)一個(gè)被掛起的線程與該線程真正開始運(yùn)行之間存在著嚴(yán)重的延遲。假設(shè)線程 A 持有一個(gè)鎖，并且線程 B 請求這個(gè)鎖。由于這個(gè)線程已經(jīng)被線程 A 持有，因此 B 將被掛起。當(dāng) A 釋放鎖時(shí)，B 將被喚醒，因此會(huì)再次嘗試獲取鎖。與此同時(shí)，如果 C 也請求這個(gè)鎖，那么 C 很有可能會(huì)在 B 被完全喚醒前獲得、使用以及釋放這個(gè)鎖。這樣的情況時(shí)一種“雙贏”的局面：B 獲得鎖的時(shí)刻并沒有推遲，C 更早的獲得了鎖，并且吞吐量也獲得了提高。
上面的原因大家看懂了嗎？下面配個(gè)圖輔助說明一下：
如上圖，線程 C 在線程 B 蘇醒階段內(nèi)獲取和使用鎖，并在線程 B 獲取鎖前釋放了鎖，所以線程 B 可以順利獲得鎖。線程 C 在搶占鎖的情況下，仍未影響線程 B 獲取鎖，因此是個(gè)“雙贏”的局面。
除了上面的原因外，《Java并發(fā)編程的藝術(shù)》在其5.3.2 公平與非公平鎖的區(qū)別（p137）分析了另一個(gè)可能的原因。即公平鎖線程切換次數(shù)要比非公平鎖線程切換次數(shù)多得多，因此效率上要低一些。更多的細(xì)節(jié)，可以參考作者的論述，這里不展開說明了。
本節(jié)最后說一下公平鎖和非公平鎖的使用場景。如果線程持鎖時(shí)間短，則應(yīng)使用非公平鎖，可通過“插隊(duì)”提升效率。如果線程持鎖時(shí)間長，“插隊(duì)”帶來的效率提升可能會(huì)比較小，此時(shí)應(yīng)使用公平鎖。
?3. 源碼分析
?3.1 代碼結(jié)構(gòu)
前面說到 ReentrantLock 是基于 AQS 實(shí)現(xiàn)的，AQS 很好的封裝了同步隊(duì)列的管理，線程的阻塞與喚醒等基礎(chǔ)操作。基于 AQS 的同步組件，推薦的使用方式是通過內(nèi)部非 public 靜態(tài)類繼承 AQS，并重寫部分抽象方法。其代碼結(jié)構(gòu)大致如下：
上圖中，Sync是一個(gè)靜態(tài)抽象類，繼承了 AbstractQueuedSynchronizer。公平和非公平鎖的實(shí)現(xiàn)類NonfairSync和FairSync則繼承自 Sync 。至于 ReentrantLock 中的其他一些方法，主要邏輯基本上都在幾個(gè)內(nèi)部類中實(shí)現(xiàn)的。
?3.2 獲取鎖
在分析 ReentrantLock 加鎖的代碼前，下來簡單介紹一下 AQS 同步隊(duì)列的一些知識。AQS 維護(hù)了一個(gè)基于雙向鏈表的同步隊(duì)列，線程在獲取同步狀態(tài)失敗的情況下，都會(huì)被封裝成節(jié)點(diǎn)，然后加入隊(duì)列中。同步隊(duì)列大致示意圖如下：
在同步隊(duì)列中，頭結(jié)點(diǎn)是獲取同步狀態(tài)的節(jié)點(diǎn)。其他節(jié)點(diǎn)在嘗試獲取同步狀態(tài)失敗后，會(huì)被阻塞住，暫停運(yùn)行。當(dāng)頭結(jié)點(diǎn)釋放同步狀態(tài)后，會(huì)喚醒其后繼節(jié)點(diǎn)。后繼節(jié)點(diǎn)會(huì)將自己設(shè)為頭節(jié)點(diǎn)，并將原頭節(jié)點(diǎn)從隊(duì)列中移除。大致示意圖如下：
介紹完 AQS 同步隊(duì)列，以及節(jié)點(diǎn)線程獲取同步狀態(tài)的過程。下面來分析一下 ReentrantLock 中獲取鎖方法的源碼，如下：
| 1 2 3 4 5 6 7 8 9 10 | public void lock() {sync.lock(); }abstract static class Sync extends AbstractQueuedSynchronizer {// 這里的 lock 是抽象方法，具體的實(shí)現(xiàn)在兩個(gè)子類中abstract void lock();// 省略其他無關(guān)代碼 } |
lock 方法的實(shí)現(xiàn)很簡單，不過這里的 lock 方法只是一個(gè)殼子而已。由于獲取鎖的方式有公平和非公平之分，所以具體的實(shí)現(xiàn)是在NonfairSync和FairSync兩個(gè)類中。那么我們繼續(xù)往下分析一下這兩個(gè)類的實(shí)現(xiàn)。
?3.2.1 公平鎖
公平鎖對應(yīng)的邏輯是 ReentrantLock 內(nèi)部靜態(tài)類 FairSync，我們沿著上面的 lock 方法往下分析，如下：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 | +--- ReentrantLock.FairSync.java final void lock() {// 調(diào)用 AQS acquire 獲取鎖acquire(1); }+--- AbstractQueuedSynchronizer.java /*** 該方法主要做了三件事情：* 1. 調(diào)用 tryAcquire 嘗試獲取鎖，該方法需由 AQS 的繼承類實(shí)現(xiàn)，獲取成功直接返回* 2. 若 tryAcquire 返回 false，則調(diào)用 addWaiter 方法，將當(dāng)前線程封裝成節(jié)點(diǎn)，* 并將節(jié)點(diǎn)放入同步隊(duì)列尾部* 3. 調(diào)用 acquireQueued 方法讓同步隊(duì)列中的節(jié)點(diǎn)循環(huán)嘗試獲取鎖*/ public final void acquire(int arg) {// acquireQueued 和 addWaiter 屬于 AQS 中的方法，這里不展開分析了if (!tryAcquire(arg) &&acquireQueued(addWaiter(Node.EXCLUSIVE), arg))selfInterrupt(); }+--- ReentrantLock.FairSync.java protected final boolean tryAcquire(int acquires) {final Thread current = Thread.currentThread();// 獲取同步狀態(tài)int c = getState();// 如果同步狀態(tài) c 為0，表示鎖暫時(shí)沒被其他線程獲取if (c == 0) {/** 判斷是否有其他線程等待的時(shí)間更長。如果有，應(yīng)該先讓等待時(shí)間更長的節(jié)點(diǎn)先獲取鎖。* 如果沒有，調(diào)用 compareAndSetState 嘗試設(shè)置同步狀態(tài)。*/ if (!hasQueuedPredecessors() &&compareAndSetState(0, acquires)) {// 將當(dāng)前線程設(shè)置為持有鎖的線程setExclusiveOwnerThread(current);return true;}}// 如果當(dāng)前線程為持有鎖的線程，則執(zhí)行重入邏輯else if (current == getExclusiveOwnerThread()) {// 計(jì)算重入后的同步狀態(tài)，acquires 一般為1int nextc = c + acquires;// 如果重入次數(shù)超過限制，這里會(huì)拋出異常if (nextc < 0)throw new Error("Maximum lock count exceeded");// 設(shè)置重入后的同步狀態(tài)setState(nextc);return true;}return false; }+--- AbstractQueuedSynchronizer.java /** 該方法用于判斷同步隊(duì)列中有比當(dāng)前線程等待時(shí)間更長的線程 */ public final boolean hasQueuedPredecessors() {Node t = tail;Node h = head;Node s;/** 在同步隊(duì)列中，頭結(jié)點(diǎn)是已經(jīng)獲取了鎖的節(jié)點(diǎn)，頭結(jié)點(diǎn)的后繼節(jié)點(diǎn)則是即將獲取鎖的節(jié)點(diǎn)。* 如果有節(jié)點(diǎn)對應(yīng)的線程等待的時(shí)間比當(dāng)前線程長，則返回 true，否則返回 false*/return h != t &&((s = h.next) == null || s.thread != Thread.currentThread()); } |
ReentrantLock 中獲取鎖的流程并不是很復(fù)雜，上面的代碼執(zhí)行流程如下：
?3.2.2 非公平鎖
分析完公平鎖相關(guān)代碼，下面再來看看非公平鎖的源碼分析，如下：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 | +--- ReentrantLock.NonfairSync final void lock() {/** 這里調(diào)用直接 CAS 設(shè)置 state 變量，如果設(shè)置成功，表明加鎖成功。這里并沒有像公平鎖* 那樣調(diào)用 acquire 方法讓線程進(jìn)入同步隊(duì)列進(jìn)行排隊(duì)，而是直接調(diào)用 CAS 搶占鎖。搶占失敗* 再調(diào)用 acquire 方法將線程置于隊(duì)列尾部排隊(duì)。*/if (compareAndSetState(0, 1))setExclusiveOwnerThread(Thread.currentThread());elseacquire(1); }+--- AbstractQueuedSynchronizer /** 參考上一節(jié)的分析 */ public final void acquire(int arg) {if (!tryAcquire(arg) &&acquireQueued(addWaiter(Node.EXCLUSIVE), arg))selfInterrupt(); }+--- ReentrantLock.NonfairSync protected final boolean tryAcquire(int acquires) {return nonfairTryAcquire(acquires); }+--- ReentrantLock.Sync final boolean nonfairTryAcquire(int acquires) {final Thread current = Thread.currentThread();// 獲取同步狀態(tài)int c = getState();// 如果同步狀態(tài) c = 0，表明鎖當(dāng)前沒有線程獲得，此時(shí)可加鎖。if (c == 0) {// 調(diào)用 CAS 加鎖，如果失敗，則說明有其他線程在競爭獲取鎖if (compareAndSetState(0, acquires)) {// 設(shè)置當(dāng)前線程為鎖的持有線程setExclusiveOwnerThread(current);return true;}}// 如果當(dāng)前線程已經(jīng)持有鎖，此處條件為 true，表明線程需再次獲取鎖，也就是重入else if (current == getExclusiveOwnerThread()) {// 計(jì)算重入后的同步狀態(tài)值，acquires 一般為1int nextc = c + acquires;if (nextc < 0) // overflowthrow new Error("Maximum lock count exceeded");// 設(shè)置新的同步狀態(tài)值setState(nextc);return true;}return false; } |
非公平鎖的實(shí)現(xiàn)也不是很復(fù)雜，其加鎖的步驟大致如下：
?3.2.3 公平和非公平細(xì)節(jié)對比
如果大家之前閱讀過公平鎖和非公平鎖的源碼，會(huì)發(fā)現(xiàn)兩者之間的差別不是很大。為了找出它們之間的差異，這里我將兩者的對比代碼放在一起，大家可以比較一下，如下：
從上面的源碼對比圖中，可以看出兩種的差異并不大。那么現(xiàn)在請大家思考一個(gè)問題：在代碼差異不大情況下，是什么差異導(dǎo)致了公平鎖和非公平鎖的產(chǎn)生呢？大家先思考一下，答案將會(huì)在下面展開說明。
在上面的源碼對比圖中，左邊是非公平鎖的實(shí)現(xiàn)，右邊是公平鎖的實(shí)現(xiàn)。從對比圖中可看出，兩者的 lock 方法有明顯區(qū)別。非公平鎖的 lock 方法會(huì)首先嘗試去搶占設(shè)置同步狀態(tài)，而不是直接調(diào)用 acquire 將線程放入同步隊(duì)列中等待獲取鎖。除此之外，tryAcquire 方法實(shí)現(xiàn)上也有差異。由于非公平鎖的 tryAcquire 邏輯主要封裝在 Sync 中的 nonfairTryAcquire 方法里，所以我們直接對比這個(gè)方法即可。由上圖可以看出，Sync 中的 nonfairTryAcquire 與公平鎖中的 tryAcquire 實(shí)現(xiàn)上差異并不大，唯一的差異在第18行，這里我用一條紅線標(biāo)注了出來。公平鎖的 tryAcquire 在第18行多出了一個(gè)條件，即!hasQueuedPredecessors()。這個(gè)方法的目的是判斷是否有其他線程比當(dāng)前線程在同步隊(duì)列中等待的時(shí)間更長。有的話，返回 true，否則返回 false。比如下圖：
node1 對應(yīng)的線程比 node2 對應(yīng)的線程在隊(duì)列中等待的時(shí)間更長，如果 node2 線程調(diào)用 hasQueuedPredecessors 方法，則會(huì)返回 true。如果 node1 調(diào)用此方法，則會(huì)返回 false。因?yàn)?node1 前面只有一個(gè)頭結(jié)點(diǎn)，但頭結(jié)點(diǎn)已經(jīng)獲取同步狀態(tài)，不處于等待狀態(tài)。所以在所有處于等待狀態(tài)的節(jié)點(diǎn)中，沒有節(jié)點(diǎn)比它等待的更長了。理解了 hasQueuedPredecessors 方法的用途后，那么現(xiàn)在請大家思考個(gè)問題，假如把條件去掉對公平鎖會(huì)有什么影響呢？答案在 lock 所調(diào)用的 acquire 方法中，再來看一遍 acquire 方法源碼：
| 1 2 3 4 5 | public final void acquire(int arg) {if (!tryAcquire(arg) &&acquireQueued(addWaiter(Node.EXCLUSIVE), arg))selfInterrupt(); } |
acquire 方法先調(diào)用子類實(shí)現(xiàn)的 tryAcquire 方法，用于嘗試獲取同步狀態(tài)，調(diào)用成功則直接返回。若調(diào)用失敗，則應(yīng)將線程插入到同步隊(duì)列尾部，按照 FIFO 原則獲取鎖。如果我們把 tryAcquire 中的條件!hasQueuedPredecessors()去掉，公平鎖將不再那么“謙讓”，它將會(huì)像非公平鎖那樣搶占獲取鎖，搶占失敗才會(huì)入隊(duì)。若如此，公平鎖將不再公平。
?3.3 釋放鎖
分析完了獲取鎖的相關(guān)邏輯，接下來再來分析一下釋放鎖的邏輯。與獲取鎖相比，釋放鎖的邏輯會(huì)簡單一些，因?yàn)獒尫沛i的過程沒有公平和非公平之分。好了，下面開始分析 unlock 的邏輯：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 | +--- ReentrantLock public void unlock() {// 調(diào)用 AQS 中的 release 方法sync.release(1); }+--- AbstractQueuedSynchronizer public final boolean release(int arg) {// 調(diào)用 ReentrantLock.Sync 中的 tryRelease 嘗試釋放鎖if (tryRelease(arg)) {Node h = head;/** 如果頭結(jié)點(diǎn)的等待狀態(tài)不為0，則應(yīng)該喚醒頭結(jié)點(diǎn)的后繼節(jié)點(diǎn)。* 這里簡單說個(gè)結(jié)論：* 頭結(jié)點(diǎn)的等待狀態(tài)為0，表示頭節(jié)點(diǎn)的后繼節(jié)點(diǎn)線程還是活躍的，無需喚醒*/if (h != null && h.waitStatus != 0)// 喚醒頭結(jié)點(diǎn)的后繼節(jié)點(diǎn)，該方法的分析請參考我寫的關(guān)于 AQS 的文章unparkSuccessor(h);return true;}return false; }+--- ReentrantLock.Sync protected final boolean tryRelease(int releases) {/** 用同步狀態(tài)量 state 減去釋放量 releases，得到本次釋放鎖后的同步狀態(tài)量。* 當(dāng)將 state 為 0，鎖才能被完全釋放*/ int c = getState() - releases;// 檢測當(dāng)前線程是否已經(jīng)持有鎖，僅允許持有鎖的線程執(zhí)行鎖釋放邏輯if (Thread.currentThread() != getExclusiveOwnerThread())throw new IllegalMonitorStateException();boolean free = false;// 如果 c 為0，則表示完全釋放鎖了，此時(shí)將持鎖線程設(shè)為 nullif (c == 0) {free = true;setExclusiveOwnerThread(null);}// 設(shè)置新的同步狀態(tài)setState(c);return free; } |
重入鎖的釋放邏輯并不復(fù)雜，這里就不多說了。
?4.總結(jié)
本文分析了可重入鎖 ReentrantLock 公平與非公平獲取鎖以及釋放鎖原理，并與 synchronized 關(guān)鍵字進(jìn)行了類比。總體來說，ReentrantLock 的原理在熟悉 AQS 原理的情況下，理解并不是很復(fù)雜。ReentrantLock 是大家經(jīng)常使用的一個(gè)同步組件，還是很有必要去弄懂它的原理的。
好了，本文到這里就結(jié)束了。謝謝大家的閱讀，再見。
?參考
- 《Java并發(fā)編程實(shí)戰(zhàn)》- Brian Goetz / Tim Peierls / Joshua Bloch / Joseph Bowbeer / David Holmes / Doug Lea
- 《Java并發(fā)編程的藝術(shù)》- 方騰飛 / 魏鵬 / 程曉明
- 本文鏈接：?https://www.tianxiaobo.com/2018/05/07/Java-重入鎖-ReentrantLock-原理分析/
from:?http://www.tianxiaobo.com/2018/05/07/Java-%E9%87%8D%E5%85%A5%E9%94%81-ReentrantLock-%E5%8E%9F%E7%90%86%E5%88%86%E6%9E%90/?
《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀總結(jié)
以上是生活随笔為你收集整理的Java 重入锁 ReentrantLock 原理分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： AbstractQueuedSynchr
- 下一篇： Java CAS 原理分析