深刻理解Lock

時間  2019-11-08
標籤 深刻 理解 lock 简体版
原文   原文鏈接

前文（深刻JVM鎖機制-synchronized）分析了JVM中的synchronized實現，本文繼續分析JVM中的另外一種鎖Lock的實現。與synchronized不一樣的是，Lock徹底用Java寫成，在java這個層面是無關JVM實現的。java

在java.util.concurrent.locks包中有不少Lock的實現類，經常使用的有ReentrantLock、ReadWriteLock（實現類ReentrantReadWriteLock），其實現都依賴java.util.concurrent.AbstractQueuedSynchronizer類，實現思路都大同小異，所以咱們以ReentrantLock做爲講解切入點。node

1. ReentrantLock的調用過程

通過觀察ReentrantLock把全部Lock接口的操做都委派到一個Sync類上，該類繼承了AbstractQueuedSynchronizer：算法

[java] view plain copy設計模式

  1. static abstract class Sync extends AbstractQueuedSynchronizer  數據結構

Sync又有兩個子類：併發

[java] view plain copyapp

  1. final static class NonfairSync extends Sync  函數

[java] view plain copy高併發

  1. final static class FairSync extends Sync  佈局

顯然是爲了支持公平鎖和非公平鎖而定義，默認狀況下爲非公平鎖。

先理一下Reentrant.lock()方法的調用過程（默認非公平鎖）：

這些討厭的Template模式致使很難直觀的看到整個調用過程，其實經過上面調用過程及AbstractQueuedSynchronizer的註釋能夠發現，AbstractQueuedSynchronizer中抽象了絕大多數Lock的功能，而只把tryAcquire方法延遲到子類中實現。tryAcquire方法的語義在於用具體子類判斷請求線程是否能夠得到鎖，不管成功與否AbstractQueuedSynchronizer都將處理後面的流程。

2. 鎖實現（加鎖）

簡單說來，AbstractQueuedSynchronizer會把全部的請求線程構成一個CLH隊列，當一個線程執行完畢（lock.unlock()）時會激活本身的後繼節點，但正在執行的線程並不在隊列中，而那些等待執行的線程所有處於阻塞狀態，通過調查線程的顯式阻塞是經過調用LockSupport.park()完成，而LockSupport.park()則調用sun.misc.Unsafe.park()本地方法，再進一步，HotSpot在Linux中中經過調用pthread_mutex_lock函數把線程交給系統內核進行阻塞。

該隊列如圖：

與synchronized相同的是，這也是一個虛擬隊列，不存在隊列實例，僅存在節點之間的先後關係。使人疑惑的是爲何採用CLH隊列呢？原生的CLH隊列是用於自旋鎖，但Doug Lea把其改造爲阻塞鎖。

當有線程競爭鎖時，該線程會首先嚐試得到鎖，這對於那些已經在隊列中排隊的線程來講顯得不公平，這也是非公平鎖的由來，與synchronized實現相似，這樣會極大提升吞吐量。

若是已經存在Running線程，則新的競爭線程會被追加到隊尾，具體是採用基於CAS的Lock-Free算法，由於線程併發對Tail調用CAS可能會致使其餘線程CAS失敗，解決辦法是循環CAS直至成功。AbstractQueuedSynchronizer的實現很是精巧，使人歎爲觀止，不入細節難以徹底領會其精髓，下面詳細說明實現過程：

2.1 Sync.nonfairTryAcquire

nonfairTryAcquire方法將是lock方法間接調用的第一個方法，每次請求鎖時都會首先調用該方法。

[java] view plain copy

  1. final boolean nonfairTryAcquire(int acquires) {  

  2.     final Thread current = Thread.currentThread();  

  3.     int c = getState();  

  4.     if (c == 0) {  

  5.         if (compareAndSetState(0, acquires)) {  

  6.             setExclusiveOwnerThread(current);  

  7.             return true;  

  8.         }  

  9.     }  

  10.     else if (current == getExclusiveOwnerThread()) {  

  11.         int nextc = c + acquires;  

  12.         if (nextc < 0) // overflow  

  13.             throw new Error("Maximum lock count exceeded");  

  14.         setState(nextc);  

  15.         return true;  

  16.     }  

  17.     return false;  

  18. }  

該方法會首先判斷當前狀態，若是c==0說明沒有線程正在競爭該鎖，若是不c !=0 說明有線程正擁有了該鎖。

若是發現c==0，則經過CAS設置該狀態值爲acquires,acquires的初始調用值爲1，每次線程重入該鎖都會+1，每次unlock都會-1，但爲0時釋放鎖。若是CAS設置成功，則能夠預計其餘任何線程調用CAS都不會再成功，也就認爲當前線程獲得了該鎖，也做爲Running線程，很顯然這個Running線程並未進入等待隊列。

若是c !=0 但發現本身已經擁有鎖，只是簡單地++acquires，並修改status值，但由於沒有競爭，因此經過setStatus修改，而非CAS，也就是說這段代碼實現了偏向鎖的功能，而且實現的很是漂亮。

2.2 AbstractQueuedSynchronizer.addWaiter

addWaiter方法負責把當前沒法得到鎖的線程包裝爲一個Node添加到隊尾：

[java] view plain copy

  1. private Node addWaiter(Node mode) {  

  2.     Node node = new Node(Thread.currentThread(), mode);  

  3.     // Try the fast path of enq; backup to full enq on failure  

  4.     Node pred = tail;  

  5.     if (pred != null) {  

  6.         node.prev = pred;  

  7.         if (compareAndSetTail(pred, node)) {  

  8.             pred.next = node;  

  9.             return node;  

  10.         }  

  11.     }  

  12.     enq(node);  

  13.     return node;  

  14. }  

其中參數mode是獨佔鎖仍是共享鎖，默認爲null，獨佔鎖。追加到隊尾的動做分兩步：

  1. 若是當前隊尾已經存在(tail!=null)，則使用CAS把當前線程更新爲Tail

  2. 若是當前Tail爲null或則線程調用CAS設置隊尾失敗，則經過enq方法繼續設置Tail

下面是enq方法：

[java] view plain copy

  1. private Node enq(final Node node) {  

  2.     for (;;) {  

  3.         Node t = tail;  

  4.         if (t == null) { // Must initialize  

  5.             Node h = new Node(); // Dummy header  

  6.             h.next = node;  

  7.             node.prev = h;  

  8.             if (compareAndSetHead(h)) {  

  9.                 tail = node;  

  10.                 return h;  

  11.             }  

  12.         }  

  13.         else {  

  14.             node.prev = t;  

  15.             if (compareAndSetTail(t, node)) {  

  16.                 t.next = node;  

  17.                 return t;  

  18.             }  

  19.         }  

  20.     }  

  21. }  


該方法就是循環調用CAS，即便有高併發的場景，無限循環將會最終成功把當前線程追加到隊尾（或設置隊頭）。總而言之，addWaiter的目的就是經過CAS把當前如今追加到隊尾，並返回包裝後的Node實例。

把線程要包裝爲Node對象的主要緣由，除了用Node構造供虛擬隊列外，還用Node包裝了各類線程狀態，這些狀態被精心設計爲一些數字值：

  • SIGNAL(-1) ：線程的後繼線程正/已被阻塞，當該線程release或cancel時要從新這個後繼線程(unpark)

  • CANCELLED(1)：由於超時或中斷，該線程已經被取消

  • CONDITION(-2)：代表該線程被處於條件隊列，就是由於調用了Condition.await而被阻塞

  • PROPAGATE(-3)：傳播共享鎖

  • 0：0表明無狀態

2.3 AbstractQueuedSynchronizer.acquireQueued

acquireQueued的主要做用是把已經追加到隊列的線程節點（addWaiter方法返回值）進行阻塞，但阻塞前又經過tryAccquire重試是否能得到鎖，若是重試成功能則無需阻塞，直接返回

[java] view plain copy

  1. final boolean acquireQueued(final Node node, int arg) {  

  2.     try {  

  3.         boolean interrupted = false;  

  4.         for (;;) {  

  5.             final Node p = node.predecessor();  

  6.             if (p == head && tryAcquire(arg)) {  

  7.                 setHead(node);  

  8.                 p.next = null; // help GC  

  9.                 return interrupted;  

  10.             }  

  11.             if (shouldParkAfterFailedAcquire(p, node) &&  

  12.                 parkAndCheckInterrupt())  

  13.                 interrupted = true;  

  14.         }  

  15.     } catch (RuntimeException ex) {  

  16.         cancelAcquire(node);  

  17.         throw ex;  

  18.     }  

  19. }  


仔細看看這個方法是個無限循環，感受若是p == head && tryAcquire(arg)條件不知足循環將永遠沒法結束，固然不會出現死循環，奧祕在於第12行的parkAndCheckInterrupt會把當前線程掛起，從而阻塞住線程的調用棧。

[java] view plain copy

  1. private final boolean parkAndCheckInterrupt() {  

  2.     LockSupport.park(this);  

  3.     return Thread.interrupted();  

  4. }  

如前面所述，LockSupport.park最終把線程交給系統（Linux）內核進行阻塞。固然也不是立刻把請求不到鎖的線程進行阻塞，還要檢查該線程的狀態，好比若是該線程處於Cancel狀態則沒有必要，具體的檢查在shouldParkAfterFailedAcquire中：

[java] view plain copy

  1.   private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {  

  2.       int ws = pred.waitStatus;  

  3.       if (ws == Node.SIGNAL)  

  4.           /* 

  5.            * This node has already set status asking a release 

  6.            * to signal it, so it can safely park 

  7.            */  

  8.           return true;  

  9.       if (ws > 0) {  

  10.           /* 

  11.            * Predecessor was cancelled. Skip over predecessors and 

  12.            * indicate retry. 

  13.            */  

  14.    do {  

  15. node.prev = pred = pred.prev;  

  16.    } while (pred.waitStatus > 0);  

  17.    pred.next = node;  

  18.       } else {  

  19.           /* 

  20.            * waitStatus must be 0 or PROPAGATE. Indicate that we 

  21.            * need a signal, but don't park yet. Caller will need to 

  22.            * retry to make sure it cannot acquire before parking.  

  23.            */  

  24.           compareAndSetWaitStatus(pred, ws, Node.SIGNAL);  

  25.       }   

  26.       return false;  

  27.   }  

檢查原則在於：

  • 規則1：若是前繼的節點狀態爲SIGNAL，代表當前節點須要unpark，則返回成功，此時acquireQueued方法的第12行（parkAndCheckInterrupt）將致使線程阻塞

  • 規則2：若是前繼節點狀態爲CANCELLED(ws>0)，說明前置節點已經被放棄，則回溯到一個非取消的前繼節點，返回false，acquireQueued方法的無限循環將遞歸調用該方法，直至規則1返回true，致使線程阻塞

  • 規則3：若是前繼節點狀態爲非SIGNAL、非CANCELLED，則設置前繼的狀態爲SIGNAL，返回false後進入acquireQueued的無限循環，與規則2同

整體看來，shouldParkAfterFailedAcquire就是靠前繼節點判斷當前線程是否應該被阻塞，若是前繼節點處於CANCELLED狀態，則順便刪除這些節點從新構造隊列。

至此，鎖住線程的邏輯已經完成，下面討論解鎖的過程。

3. 解鎖

請求鎖不成功的線程會被掛起在acquireQueued方法的第12行，12行之後的代碼必須等線程被解鎖鎖才能執行，假如被阻塞的線程獲得解鎖，則執行第13行，即設置interrupted = true，以後又進入無限循環。

從無限循環的代碼能夠看出，並非獲得解鎖的線程必定能得到鎖，必須在第6行中調用tryAccquire從新競爭，由於鎖是非公平的，有可能被新加入的線程得到，從而致使剛被喚醒的線程再次被阻塞，這個細節充分體現了「非公平」的精髓。經過以後將要介紹的解鎖機制會看到，第一個被解鎖的線程就是Head，所以p == head的判斷基本都會成功。

至此能夠看到，把tryAcquire方法延遲到子類中實現的作法很是精妙並具備極強的可擴展性，使人歎爲觀止！固然精妙的不是這個Templae設計模式，而是Doug Lea對鎖結構的精心佈局。

解鎖代碼相對簡單，主要體如今AbstractQueuedSynchronizer.release和Sync.tryRelease方法中：

class AbstractQueuedSynchronizer

[java] view plain copy

  1. public final boolean release(int arg) {  

  2.     if (tryRelease(arg)) {  

  3.         Node h = head;  

  4.         if (h != null && h.waitStatus != 0)  

  5.             unparkSuccessor(h);  

  6.         return true;  

  7.     }  

  8.     return false;  

  9. }  

class Sync

[java] view plain copy

  1. protected final boolean tryRelease(int releases) {  

  2.     int c = getState() - releases;  

  3.     if (Thread.currentThread() != getExclusiveOwnerThread())  

  4.         throw new IllegalMonitorStateException();  

  5.     boolean free = false;  

  6.     if (c == 0) {  

  7.         free = true;  

  8.         setExclusiveOwnerThread(null);  

  9.     }  

  10.     setState(c);  

  11.     return free;  

  12. }  


tryRelease與tryAcquire語義相同，把如何釋放的邏輯延遲到子類中。tryRelease語義很明確：若是線程屢次鎖定，則進行屢次釋放，直至status==0則真正釋放鎖，所謂釋放鎖即設置status爲0，由於無競爭因此沒有使用CAS。

release的語義在於：若是能夠釋放鎖，則喚醒隊列第一個線程（Head），具體喚醒代碼以下：

[java] view plain copy

  1. private void unparkSuccessor(Node node) {  

  2.     /* 

  3.      * If status is negative (i.e., possibly needing signal) try 

  4.      * to clear in anticipation of signalling. It is OK if this 

  5.      * fails or if status is changed by waiting thread. 

  6.      */  

  7.     int ws = node.waitStatus;  

  8.     if (ws < 0)  

  9.         compareAndSetWaitStatus(node, ws, 0);   

  10.   

  11.     /* 

  12.      * Thread to unpark is held in successor, which is normally 

  13.      * just the next node.  But if cancelled or apparently null, 

  14.      * traverse backwards from tail to find the actual 

  15.      * non-cancelled successor. 

  16.      */  

  17.     Node s = node.next;  

  18.     if (s == null || s.waitStatus > 0) {  

  19.         s = null;  

  20.         for (Node t = tail; t != null && t != node; t = t.prev)  

  21.             if (t.waitStatus <= 0)  

  22.                 s = t;  

  23.     }  

  24.     if (s != null)  

  25.         LockSupport.unpark(s.thread);  

  26. }  


這段代碼的意思在於找出第一個能夠unpark的線程，通常說來head.next == head，Head就是第一個線程，但Head.next可能被取消或被置爲null，所以比較穩妥的辦法是從後往前找第一個可用線程。貌似回溯會致使性能下降，其實這個發生的概率很小，因此不會有性能影響。以後即是通知系統內核繼續該線程，在Linux下是經過pthread_mutex_unlock完成。以後，被解鎖的線程進入上面所說的從新競爭狀態。

4. Lock VS Synchronized

AbstractQueuedSynchronizer經過構造一個基於阻塞的CLH隊列容納全部的阻塞線程，而對該隊列的操做均經過Lock-Free（CAS）操做，但對已經得到鎖的線程而言，ReentrantLock實現了偏向鎖的功能。

synchronized的底層也是一個基於CAS操做的等待隊列，但JVM實現的更精細，把等待隊列分爲ContentionList和EntryList，目的是爲了下降線程的出列速度；固然也實現了偏向鎖，從數據結構來講兩者設計沒有本質區別。但synchronized還實現了自旋鎖，並針對不一樣的系統和硬件體系進行了優化，而Lock則徹底依靠系統阻塞掛起等待線程。

固然Lock比synchronized更適合在應用層擴展，能夠繼承AbstractQueuedSynchronizer定義各類實現，好比實現讀寫鎖（ReadWriteLock），公平或不公平鎖；同時，Lock對應的Condition也比wait/notify要方便的多、靈活的多。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程