前言
- 上篇文章咱們基于兩個案例了解了ReentrantLock(公平鎖)的加鎖過程。接下來咱們繼續基于相同的案例來認識它的解鎖過程。
- 兩個案例
1.線程A單獨加鎖再解鎖
2.線程A正在持有鎖的過程中，線程t1來加鎖，線程t1阻塞后，線程A解鎖
一、案例1：線程A單獨加鎖再解鎖
- 還是使用相同的代碼：
public class SimpleThreadLock { static ReentrantLock lock = new ReentrantLock(true); public static void main(String[] args) throws InterruptedException { Thread a = new Thread(() -> { try { lock.lock(); System.out.println("Get lock"); } catch (Exception e) { e.printStackTrace(); } finally { lock.unlock(); } }, "線程a"); a.start(); a.join(); System.out.println("end"); } } - 還記得線程A單獨加鎖時的流程么？或者說單獨加鎖后的程序會定位到哪里？沒錯，在執行完tryAcquire方法后，它返回的是true，那么進而說明acquire方法后面的語句壓根不會執行。
這也間接說明了在單個線程加鎖時，只會操作aqs隊列中的state變量，其中隊列都不會產生。那么我們來做一個猜測：是不是解鎖時，只是單獨的將aqs中的state變量cas成0呢？ 我們帶著這個疑問來看unlock方法的源碼。public final void acquire(int arg) { if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt(); } - java.util.concurrent.locks.ReentrantLock#unlock源碼：
根據咱們的主題，公平鎖的解鎖過程，所以我們直接定位到public void unlock() { sync.release(1); }FairSync的release方法，但是它并沒有對父類AbstractQueuedSynchronizer的release方法進行重寫，那么此時調用的肯定是父類的release方法，我們直接粘貼源碼(父類AbstractQueuedSynchronizer release方法源碼)：public final boolean release(int arg) { // 嘗試去釋放鎖，與tryLock一樣，有可能會失敗 // tryRelease具體源碼分析將在下面給出 // 咱們先接著往下看，看完tryRelase再回過頭來看 // if內的邏輯 // ...... 下面的邏輯請先看完tryRelease來回過頭來接著看 // 在下面的tryRelease方法中有說到，只有線程對 // 鎖釋放成功了，這里返回的才是true，若 // 釋放鎖的次數 < 重入的次數，那么會返回false // 若解鎖的線程和當前持有state的線程不是同一個線程 // 則拋出異常。 if (tryRelease(arg)) { // 進入了if, 則表示線程釋放鎖成功 // 因為在本案例中，只有一個線程加鎖 // 所以aqs隊列都沒有初始化，head肯定為null // 因此不需要執行if內的邏輯，然后直接返回true即可 // 在本案例中，返回true也毫無意義，在最頂端的 // 方法調用鏈中并沒有接收這個返回值，因此 // 本案例的解鎖過程結束 Node h = head; if (h != null && h.waitStatus != 0) unparkSuccessor(h); return true; } return false; } - java.util.concurrent.locks.ReentrantLock.Sync#tryRelease源碼：
看完這部分源碼后記得返回看上述的release源碼。在release源碼中的注釋有說到，在此案例下，線程A的解鎖過程就結束了。因此在ReentrantLock中，單線程的執行或者多線程交替執行，并不會產生aqs隊列，就是對state變量的一個加、減操作。但需注意：ReentrantLock的重入特性以及解鎖的校驗，重入了多少次就要解鎖多少次，以及只能由當前持有state的線程才能unlock，否則拋異常。protected final boolean tryRelease(int releases) { // 在當前案例中，state的值為1, // 而傳入的release為1(由上述的調用鏈可知) // 所以此時做完操作后，c的值就等于0了 int c = getState() - releases; // 這里做了一個校驗，一定要當前持有state的 // 線程才能做解決操作，否則拋異常 if (Thread.currentThread() != getExclusiveOwnerThread()) throw new IllegalMonitorStateException(); // 能執行到這一步，就說明是當前持有 // state的線程執行的unlock方法， // 后續要做的操作就是： // 確認c是否等于0，如果等于0則表示鎖釋放 // 完畢，接著就是設置state的擁有者為null // 且設置state變量為0, // 若c不等于0，則表示當前這個線程持有的鎖 // 是一把重入鎖，重入多少次就要unlock多少次 // ===> 只有當前線程解鎖成功后，才返回true // 若解鎖的次數 < 重入的次數則返回false boolean free = false; if (c == 0) { free = true; setExclusiveOwnerThread(null); } setState(c); return free; }
二、案例2：線程A正在持有鎖的過程中，線程t1來加鎖，線程線程A解鎖
- 還是使用相同上篇文章相同的代碼：
還記得線程t1加鎖時是在哪里被阻塞的嗎？沒錯，就是在java.util.concurrent.locks.AbstractQueuedSynchronizer#acquireQueued方法public class TwoThreadLock { static ReentrantLock lock = new ReentrantLock(true); public static void main(String[] args) throws InterruptedException { new Thread(() -> { try { lock.lock(); System.out.println("Thread a get lock"); TimeUnit.SECONDS.sleep(60); } catch (Exception e) { e.printStackTrace(); } finally { lock.unlock(); } }, "線程a").start(); Thread t1 = new Thread(() -> { try { lock.lock(); System.out.println("Thread t1 get lock"); } catch (Exception e) { e.printStackTrace(); } finally { lock.unlock(); } }, "線程t1"); t1.start(); t1.join(); System.out.println("end"); } }
根據源碼中的注釋可知，線程t1在指定位置被阻塞了。按照當前案例來說，當線程t1阻塞時，線程a調用了unlock方法進行了解鎖，此時的解鎖過程和案例一的差不多，區別就在于release中的if代碼塊，詳見下述源碼解釋：final boolean acquireQueued(final Node node, int arg) { boolean failed = true; try { boolean interrupted = false; for (;;) { // 部分代碼省略..... // 在上篇博客的案例中，我們有說到 // 當線程t1在線程a持有鎖的過程中 // 來競爭鎖了，此時就會在這里被park // 也就是在這里被阻塞了。 if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) interrupted = true; } } finally { if (failed) cancelAcquire(node); } }public final boolean release(int arg) { // 嘗試去釋放鎖，與tryLock一樣，有可能會失敗 // tryRelease具體源碼分析將在下面給出 // 咱們先接著往下看，看完tryRelase再回過頭來看 // if內的邏輯 // ...... 下面的邏輯請先看完tryRelease來回過頭來接著看 // 在下面的tryRelease方法中有說到，只有線程對 // 鎖釋放成功了，這里返回的才是true，若 // 釋放鎖的次數 < 重入的次數，那么會返回false // 若解鎖的線程和當前持有state的線程不是同一個線程 // 則拋出異常。 if (tryRelease(arg)) { // 進入了if, 則表示線程釋放鎖成功 // 在本案例中，因為aqs隊列初始化了， // 所以head不為null，且它的waitStatus // 為0，于是會執行if內部的 // unparkSuccessor方法 // 看完下面對unparkSuccessor方法的源碼解析 // 再回過頭來繼續往下看?。。。?！ // ................... // 最終返回true， // 其實這個返回值在這個案例中也沒作用, // 因為在調用鏈中并沒有接收它的返回值 // 所以它線程a的解鎖流程算是完成了。 Node h = head; if (h != null && h.waitStatus != 0) // 此時傳入的為aqs隊列中的head節點 unparkSuccessor(h); return true; } return false; } - java.util.concurrent.locks.AbstractQueuedSynchronizer#unparkSuccessor源碼解析
private void unparkSuccessor(Node node) { // 在當前案例中，傳入的node為隊列中的head節點 // 此時它的ws為0 int ws = node.waitStatus; if (ws < 0) compareAndSetWaitStatus(node, ws, 0); /** 拿到head節點的下一個節點， 因為它的下一個節點不為null且waitStatus的值為-1( 在當前案例下，它的下一個節點 是處于park狀態，那么它的waitStatus肯定是-1) 于是不進if里面的邏輯 */ 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) s = t; } // 在當前案例下head節點的下一個節點不為null if (s != null) // 于是對s這個node中維護的線程做unpark操作 // 在本案例中，這個s節點內部維護的線程就是 // t1, 于是t1會被喚醒。 // 還記得線程t1是在哪里被阻塞的嗎？我們繼續往下看 LockSupport.unpark(s.thread); } - 再次回到java.util.concurrent.locks.AbstractQueuedSynchronizer#acquireQueued方法
final boolean acquireQueued(final Node node, int arg) { boolean failed = true; try { boolean interrupted = false; for (;;) { // ----------看完下面的start部分再回頭看 ------------ // 此時的node為t2線程對應的node // 此時獲取它的上一個節點， // 它的上一個節點是head節點， // 于是走后面的&& 邏輯 // 后面的&& 邏輯就是繼續去加鎖 // 此時因為只有線程t2在，所以肯定 // 會加鎖成功，最終返回true // 進而進入if的代碼塊中， // 在if代碼塊中主要做的時就是 // 修改head節點的引用，并回收 // 原來的head節點，最終獲取鎖 // 成功 // ----------看完下面的start部分再回頭看 ------------ final Node p = node.predecessor(); if (p == head && tryAcquire(arg)) { setHead(node); p.next = null; // help GC failed = false; return interrupted; } // ----------start部分------------ // start部分: 線程t1是在parkAndCheckInterrupt方法中被阻塞的， // ****************** // 先看下面的parkAndCheckInterrupt方法再回頭繼續往下看 // ****************** // 在parkAndCheckInterrupt方法中返回了true // 所以會繼續自旋， // ----------start部分------------ if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) interrupted = true; } } finally { if (failed) cancelAcquire(node); } } - java.util.concurrent.locks.AbstractQueuedSynchronizer#parkAndCheckInterrupt方法
通過上述的源碼注釋，應該對案例2的解鎖過程也了解了。其實也蠻簡單，就是上一個線程unlock，于是unpark head節點的后一個節點對應的線程。當然，這也只是針對于案例2的簡單，里面還有很多細節沒有提及到，因為是針對案例而言的嘛，咱們得以案例為中心進行總結。private final boolean parkAndCheckInterrupt() { // 所以當線程a調用unlock方法時，線程t2 // 會從此處開始繼續執行， LockSupport.park(this); // 會將當前線程標識為interrupt狀態， // 并且返回true return Thread.interrupted(); }
三、總結
- 還是那句話，解鎖過程也是基于兩個簡單的案例來總結的，其實ReentrantLock還有很多其他的情形，但是我們把最基本的加鎖、解鎖過程的流程給弄清楚后，后續的各種情形咱們
照單全收！絲毫不慌 - ReentrantLock加鎖流程涉及到每個方法的詳細步驟可查看在github中的總結：傳送門
- I am a slow walker, but I never walk backwards.
