『壹』 java 鎖有幾種
樂觀鎖/悲觀鎖
樂觀鎖與悲觀鎖不是指具體的什麼類型的鎖，而是指看待並發同步的角度。
悲觀鎖認為對於同一個數據的並發操作，一定是會發生修改的，哪怕沒有修改，也會認為修改。因此對於同一個數據的並發操作，悲觀鎖採取加鎖的形式。悲觀的認為，不加鎖的並發操作一定會出問題。
樂觀鎖則認為對於同一個數據的並發操作，是不會發生修改的。在更新數據的時候，會採用嘗試更新，不斷重新的方式更新數據。樂觀的認為，不加鎖的並發操作是沒有事情的。
從上面的描述我們可以看出，悲觀鎖適合寫操作非常多的場景，樂觀鎖適合讀操作非常多的場景，不加鎖會帶來大量的性能提升。
公平鎖/非公平鎖
公平鎖是指多個線程按照申請鎖的順序來獲取鎖。
非公平鎖是指多個線程獲取鎖的順序並不是按照申請鎖的順序，有可能後申請的線程比先申請的線程優先獲取鎖。
優點：在於吞吐量比公平鎖大。
缺點：可能會造成優先順序反轉或者某些線程飢餓現象(一直拿不到鎖)。
對於Java ReentrantLock而言，通過構造函數指定該鎖是否是公平鎖，默認是非公平鎖。
對於Synchronized而言，也是一種非公平鎖。由於其並不像ReentrantLock是通過AQS的來實現線程調度，所以並沒有任何辦法使其變成公平鎖。
可重入鎖
可重入鎖的概念是自己可以再次獲取自己的內部鎖。
舉個例子，比如一條線程獲得了某個對象的鎖，此時這個對象鎖還沒有釋放，當其再次想要獲取這個對象的鎖的時候還是可以獲取的（如果不可重入的鎖的話，此刻會造成死鎖）。說的更高深一點可重入鎖是一種遞歸無阻塞的同步機制。
對於Java ReentrantLock而言, 他的名字就可以看出是一個可重入鎖，其名字是Re entrant Lock重新進入鎖。
對於Synchronized而言,也是一個可重入鎖。可重入鎖的一個好處是可一定程度避免死鎖。
獨享鎖/共享鎖
獨享鎖是指該鎖一次只能被一個線程所持有。
共享鎖是指該鎖可被多個線程所持有。
對於Java ReentrantLock（互斥鎖）而言，其是獨享鎖。
但是對於Lock的另一個實現類ReadWriteLock（讀寫鎖），其讀鎖是共享鎖，其寫鎖是獨享鎖。讀鎖的共享鎖可保證並發讀是非常高效的，讀寫，寫讀 ，寫寫的過程是互斥的。
對於Synchronized而言，當然是獨享鎖。
分段鎖
分段鎖其實是一種鎖的設計，並不是具體的一種鎖。對於ConcurrentHashMap而言，其並發的實現就是通過分段鎖的形式來實現高效的並發操作。
我們以ConcurrentHashMap來說一下分段鎖的含義以及設計思想，ConcurrentHashMap中的分段鎖稱為Segment，它即類似於HashMap（JDK7與JDK8中HashMap的實現）的結構，即內部擁有一個Entry數組，數組中的每個元素又是一個鏈表；同時又是一個ReentrantLock（Segment繼承了ReentrantLock)。
當需要put元素的時候，並不是對整個hashmap進行加鎖，而是先通過hashcode來知道他要放在那一個分段中，然後對這個分段進行加鎖，所以當多線程put的時候，只要不是放在一個分段中，就實現了真正的並行的插入。
但是，在統計size的時候，可就是獲取hashmap全局信息的時候，就需要獲取所有的分段鎖才能統計。
分段鎖的設計目的是細化鎖的粒度，當操作不需要更新整個數組的時候，就僅僅針對數組中的一項進行加鎖操作。
互斥鎖：
無法獲取瑣時，進線程立刻放棄剩餘的時間片並進入阻塞（或者說掛起）狀態，同時保存寄存器和程序計數器的內容（保存現場，上下文切換的前半部分），當可以獲取鎖時，進線程激活，等待被調度進CPU並恢復現場（上下文切換下半部分）
上下文切換會帶來數十微秒的開銷，不要在性能敏感的地方用互斥鎖
讀寫鎖：
1）多個讀者可以同時進行讀
2）寫者必須互斥（只允許一個寫者寫，也不能讀者寫者同時進行）
3）寫者優先於讀者（一旦有寫者，則後續讀者必須等待，喚醒時優先考慮寫者）
自旋鎖：
自旋鎖是指嘗試獲取鎖的線程不會立即阻塞，而是採用循環的方式去嘗試獲取鎖，這樣的好處是減少線程上下文切換的消耗，缺點是循環會消耗CPU。
『貳』 JAVA程序設計，多線程且避免死鎖
JAVA中幾種常見死鎖及對策：解決死鎖沒有簡單的方法，這是因為線程產生死鎖都各有各的原因，而且往往具有很高的負載。大多數軟體測試產生不了足夠多的負載，所以不可能暴露所有的線程錯誤。在這里中，下面將討論開發過程常見的4類典型的死鎖和解決對策。(1)資料庫死鎖在資料庫中，如果一個連接佔用了另一個連接所需的資料庫鎖，則它可以阻塞另一個連接。如果兩個或兩個以上的連接相互阻塞，則它們都不能繼續執行，這種情況稱為資料庫死鎖。資料庫死鎖問題不易處理，通常數據行進行更新時，需要鎖定該數據行，執行更新，然後在提交或回滾封閉事務時釋放鎖。由於資料庫平台、配置的隔離級以及查詢提示的不同，獲取的鎖可能是細粒度或粗粒度的，它會阻塞（或不阻塞）其他對同一數據行、表或資料庫的查詢。基於資料庫模式，讀寫操作會要求遍歷或更新多個索引、驗證約束、執行觸發器等。每個要求都會引入鎖。此外，其他應用程序還可能正在訪問同一資料庫模式中的某些對象，並獲取不同應用程序所具有的鎖。所有這些因素綜合在一起，資料庫死鎖幾乎不可能被消除了。值得慶幸的是，資料庫死鎖通常是可恢復的：當資料庫發現死鎖時，它會強制銷毀一個連接（通常是使用最少的連接），並回滾其事務。這將釋放所有與已經結束的事務相關聯的鎖，至少允許其他連接中有一個可以獲取它們正在被阻塞的鎖。由於資料庫具有這種典型的死鎖處理行為，所以當出現資料庫死鎖問題時，資料庫常常只能重試整個事務。當資料庫連接被銷毀時，會拋出可被應用程序捕獲的異常，並標識為資料庫死鎖。如果允許死鎖異常傳播到初始化該事務的代碼層之外，則該代碼層可以啟動一個新事務並重做先前所有工作。當出現問題就重試，由於資料庫可以自由地獲取鎖，所以幾乎不可能保證兩個或兩個以上的線程不發生資料庫死鎖。此方法至少能保證在出現某些資料庫死鎖情況時，應用程序能正常運行。(2)資源池耗盡死鎖客戶端的增加導致資源池耗盡死鎖是由於負載而造成的，即資源池太小，而每個線程需要的資源超過了池中的可用資源。假設連接池最多有10個連接，同時有10個對外部並發調用。這些線程中每一個都需要一個資料庫連接用來清空池。現在，每個線程都執行嵌套的調用。則所有線程都不能繼續，但又都不放棄自己的第一個資料庫連接。這樣，10個線程都將被死鎖。研究此類死鎖，會發現線程存儲中有大量等待獲取資源的線程，以及同等數量的空閑且未阻塞的活動資料庫連接。當應用程序死鎖時，如果可以在運行時檢測連接池，就能確認連接池實際上已空。修復此類死鎖的方法包括：增加連接池的大小或者重構代碼，以便單個線程不需要同時使用很多資料庫連接。或者可以設置內部調用使用不同的連接池，即使外部調用的連接池為空，內部調用也能使用自己的連接池繼續。(3)單線程、多沖突資料庫連接死鎖對同一線程執行嵌套的調用有時出現死鎖，此情形即使在非高負載系統中通常也會發生。當第一個（外部）連接已獲取第二個（內部）連接所需要的資料庫鎖，則第二個連接將永久阻塞第一個連接，並等待第一個連接被提交或回滾，這就出現了死鎖情形。因為資料庫沒有注意到兩個連接之間的關系，所以資料庫不會將此情形檢測為死鎖。這樣即使不存在並發，此代碼也將導致死鎖。此情形有多種具體的變種，可以涉及多個線程和兩個以上的資料庫連接。(4)Java虛擬機鎖與資料庫鎖沖突這種情形發生在資料庫鎖與Java虛擬機鎖並存的時候。在這種情況下，一個線程佔有一個資料庫鎖並嘗試獲取Java虛擬機鎖。同時，另一個線程佔有Java虛擬機鎖並嘗試獲取資料庫鎖。此時，資料庫發現一個連接阻塞了另一個連接，但由於無法阻止連接繼續，所以不會檢測到死鎖。Java虛擬機發現同步的鎖中有一個線程，並有另一個嘗試進入的線程，所以即使Java虛擬機能檢測到死鎖並對它們進行處理，它還是不會檢測到這種情況。總而言之，JAVA應用程序中的死鎖是一個大問題——它能導致整個應用程序慢慢終止，還很難被分離和修復，尤其是當開發人員不熟悉如何分析死鎖環境的時候。五.死鎖的經驗法則筆者在開發中總結以下死鎖問題的經驗。(1)對大多數的Java程序員來說最簡單的防止死鎖的方法是對競爭的資源引入序號,如果一個線程需要幾個資源,那麼它必須先得到小序號的資源,再申請大序號的資源。可以在Java代碼中增加同步關鍵字的使用，這樣可以減少死鎖，但這樣做也會影響性能。如果負載過重，資料庫內部也有可能發生死鎖。(2)了解資料庫鎖的發生行為。假定任何資料庫訪問都有可能陷入資料庫死鎖狀況，但是都能正確進行重試。例如了解如何從應用伺服器獲取完整的線程轉儲以及從資料庫獲取資料庫連接列表（包括互相阻塞的連接），知道每個資料庫連接與哪個Java線程相關聯。了解Java線程和資料庫連接之間映射的最簡單方法是向連接池訪問模式添加日誌記錄功能。(3)當進行嵌套的調用時，了解哪些調用使用了與其它調用同樣的資料庫連接。即使嵌套調用運行在同一個全局事務中，它仍將使用不同的資料庫連接，而不會導致嵌套死鎖。(4)確保在峰值並發時有足夠大的資源池。(5)避免執行資料庫調用或在佔有Java虛擬機鎖時，執行其他與Java虛擬機無關的操作。最重要的是，多線程設計雖然是困難的，但在開始編程之前詳細設計系統能夠幫助你避免難以發現死鎖的問題。死鎖在語言層面上不能解決，就需要一個良好設計來避免死鎖。
『叄』 源碼分析： Java中鎖的種類與特性詳解
在Java中存在多種鎖，包括ReentrantLock、Synchronized等，它們根據特性與使用場景可劃分為多種類型，如樂觀鎖與悲觀鎖、可重入鎖與不可重入鎖等。本文將結合源碼深入分析這些鎖的設計思想與應用場景。
鎖存在的意義在於保護資源，防止多線程訪問同步資源時出現預期之外的錯誤。舉例來說，當張三操作同一張銀行卡進行轉賬，如果銀行不鎖定賬戶余額，可能會導致兩筆轉賬同時成功，違背用戶意圖。因此，在多線程環境下，鎖機制是必要的。
樂觀鎖認為訪問資源時不會立即加鎖，僅在獲取失敗時重試，通常適用於競爭頻率不高的場景。樂觀鎖可能影響系統性能，故在競爭激烈的場景下不建議使用。Java中的樂觀鎖實現方式多基於CAS（比較並交換）操作，如AQS的鎖、ReentrantLock、CountDownLatch、Semaphore等。CAS類實現不能完全保證線程安全，使用時需注意版本號管理等潛在問題。
悲觀鎖則始終在訪問同步資源前加鎖，確保無其他線程干預。ReentrantLock、Synchronized等都是典型的悲觀鎖實現。
自旋鎖與自適應自旋鎖是另一種鎖機制。自旋鎖在獲取鎖失敗時採用循環等待策略，避免阻塞線程。自適應自旋鎖則根據前一次自旋結果動態調整等待時間，提高效率。
無鎖、偏向鎖、輕量級鎖與重量級鎖是Synchronized的鎖狀態，從無鎖到重量級鎖，鎖的競爭程度與性能逐漸增加。Java對象頭包含了Mark Word與Klass Pointer，Mark Word存儲對象狀態信息，而Klass Pointer指向類元數據。
Monitor是實現線程同步的關鍵，與底層操作系統的Mutex Lock相互依賴。Synchronized通過Monitor實現，其效率在JDK 6前較低，但JDK 6引入了偏向鎖與輕量級鎖優化性能。
公平鎖與非公平鎖決定了鎖的分配順序。公平鎖遵循申請順序，非公平鎖則允許插隊，提高鎖獲取效率。
可重入鎖允許線程在獲取鎖的同一節點多次獲取鎖，而不可重入鎖不允許。共享鎖與獨占鎖是另一種鎖分類，前者允許多個線程共享資源，後者則確保資源的獨占性。
本文通過源碼分析，詳細介紹了Java鎖的種類與特性，以及它們在不同場景下的應用。了解這些機制對於多線程編程至關重要。此外，還有多種機制如volatile關鍵字、原子類以及線程安全的集合類等，需要根據具體場景逐步掌握。
『肆』 JAVA鎖有哪些種類，以及區別
常見的Java鎖有下面這些：
公平鎖/非公平鎖
可重入鎖
獨享鎖/共享鎖
互斥鎖/讀寫鎖
樂觀鎖/悲觀鎖
分段鎖
偏向鎖/輕量級鎖/重量級鎖
自旋鎖
這些分類並不是全是指鎖的狀態，有的指鎖的特性，有的指鎖的設計，下面總結的內容是對每個鎖的名詞進行一定的解釋。
公平鎖/非公平鎖
公平鎖是指多個線程按照申請鎖的順序來獲取鎖。
非公平鎖是指多個線程獲取鎖的順序並不是按照申請鎖的順序，有可能後申請的線程比先申請的線程優先獲取鎖。有可能，會造成優先順序反轉或者飢餓現象。
對於JavaReentrantLock而言，通過構造函數指定該鎖是否是公平鎖，默認是非公平鎖。非公平鎖的優點在於吞吐量比公平鎖大。
對於Synchronized而言，也是一種非公平鎖。由於其並不像ReentrantLock是通過AQS的來實現線程調度，所以並沒有任何辦法使其變成公平鎖。
可重入鎖
可重入鎖又名遞歸鎖，是指在同一個線程在外層方法獲取鎖的時候，在進入內層方法會自動獲取鎖。說的有點抽象，下面會有一個代碼的示例。
對於JavaReentrantLock而言, 他的名字就可以看出是一個可重入鎖，其名字是Re entrant Lock重新進入鎖。
對於Synchronized而言,也是一個可重入鎖。可重入鎖的一個好處是可一定程度避免死鎖。
上面的代碼就是一個可重入鎖的一個特點，如果不是可重入鎖的話，setB可能不會被當前線程執行，可能造成死鎖。
獨享鎖/共享鎖
獨享鎖是指該鎖一次只能被一個線程所持有。
共享鎖是指該鎖可被多個線程所持有。
對於JavaReentrantLock而言，其是獨享鎖。但是對於Lock的另一個實現類ReadWriteLock，其讀鎖是共享鎖，其寫鎖是獨享鎖。
讀鎖的共享鎖可保證並發讀是非常高效的，讀寫，寫讀 ，寫寫的過程是互斥的。
獨享鎖與共享鎖也是通過AQS來實現的，通過實現不同的方法，來實現獨享或者共享。
對於Synchronized而言，當然是獨享鎖。
互斥鎖/讀寫鎖
上面講的獨享鎖/共享鎖就是一種廣義的說法，互斥鎖/讀寫鎖就是具體的實現。
互斥鎖在Java中的具體實現就是ReentrantLock
讀寫鎖在Java中的具體實現就是ReadWriteLock
樂觀鎖/悲觀鎖
樂觀鎖與悲觀鎖不是指具體的什麼類型的鎖，而是指看待並發同步的角度。
悲觀鎖認為對於同一個數據的並發操作，一定是會發生修改的，哪怕沒有修改，也會認為修改。因此對於同一個數據的並發操作，悲觀鎖採取加鎖的形式。悲觀的認為，不加鎖的並發操作一定會出問題。
樂觀鎖則認為對於同一個數據的並發操作，是不會發生修改的。在更新數據的時候，會採用嘗試更新，不斷重新的方式更新數據。樂觀的認為，不加鎖的並發操作是沒有事情的。
從上面的描述我們可以看出，悲觀鎖適合寫操作非常多的場景，樂觀鎖適合讀操作非常多的場景，不加鎖會帶來大量的性能提升。
悲觀鎖在Java中的使用，就是利用各種鎖。
樂觀鎖在Java中的使用，是無鎖編程，常常採用的是CAS演算法，典型的例子就是原子類，通過CAS自旋實現原子操作的更新。
分段鎖
分段鎖其實是一種鎖的設計，並不是具體的一種鎖，對於ConcurrentHashMap而言，其並發的實現就是通過分段鎖的形式來實現高效的並發操作。
我們以ConcurrentHashMap來說一下分段鎖的含義以及設計思想，ConcurrentHashMap中的分段鎖稱為Segment，它即類似於HashMap（JDK7與JDK8中HashMap的實現）的結構，即內部擁有一個Entry數組，數組中的每個元素又是一個鏈表；同時又是一個ReentrantLock（Segment繼承了ReentrantLock)。
當需要put元素的時候，並不是對整個hashmap進行加鎖，而是先通過hashcode來知道他要放在那一個分段中，然後對這個分段進行加鎖，所以當多線程put的時候，只要不是放在一個分段中，就實現了真正的並行的插入。
但是，在統計size的時候，可就是獲取hashmap全局信息的時候，就需要獲取所有的分段鎖才能統計。
分段鎖的設計目的是細化鎖的粒度，當操作不需要更新整個數組的時候，就僅僅針對數組中的一項進行加鎖操作。
偏向鎖/輕量級鎖/重量級鎖
這三種鎖是指鎖的狀態，並且是針對Synchronized。在Java 5通過引入鎖升級的機制來實現高效Synchronized。這三種鎖的狀態是通過對象監視器在對象頭中的欄位來表明的。
偏向鎖是指一段同步代碼一直被一個線程所訪問，那麼該線程會自動獲取鎖。降低獲取鎖的代價。
輕量級鎖是指當鎖是偏向鎖的時候，被另一個線程所訪問，偏向鎖就會升級為輕量級鎖，其他線程會通過自旋的形式嘗試獲取鎖，不會阻塞，提高性能。
重量級鎖是指當鎖為輕量級鎖的時候，另一個線程雖然是自旋，但自旋不會一直持續下去，當自旋一定次數的時候，還沒有獲取到鎖，就會進入阻塞，該鎖膨脹為重量級鎖。重量級鎖會讓其他申請的線程進入阻塞，性能降低。
自旋鎖
在Java中，自旋鎖是指嘗試獲取鎖的線程不會立即阻塞，而是採用循環的方式去嘗試獲取鎖，這樣的好處是減少線程上下文切換的消耗，缺點是循環會消耗CPU。
『伍』 說說java鎖有哪些種類，以及區別
鎖作為並發共享數據，保證一致性的工具，在JAVA平台有多種實現(如 synchronized 和 ReentrantLock等等 ) 。這些已經寫好提供的鎖為我們開發提供了便利，但是鎖的具體性質以及類型卻很少被提及。本系列文章將分析JAVA下常見的鎖名稱以及特性，為大家答疑解惑。
1、自旋鎖
自旋鎖是採用讓當前線程不停地的在循環體內執行實現的，當循環的條件被其他線程改變時 才能進入臨界區。如下
01 public class SpinLock {
02
03 private AtomicReference<Thread> sign =newAtomicReference<>();
04
05 public void lock(){
06 Thread current = Thread.currentThread();
07 while(!sign .compareAndSet(null, current)){
08 }
09 }
10
11 public void unlock (){
12 Thread current = Thread.currentThread();
13 sign .compareAndSet(current, null);
14 }
15 }
使用了CAS原子操作，lock函數將owner設置為當前線程，並且預測原來的值為空。unlock函數將owner設置為null，並且預測值為當前線程。
當有第二個線程調用lock操作時由於owner值不為空，導致循環一直被執行，直至第一個線程調用unlock函數將owner設置為null，第二個線程才能進入臨界區。
由於自旋鎖只是將當前線程不停地執行循環體，不進行線程狀態的改變，所以響應速度更快。但當線程數不停增加時，性能下降明顯，因為每個線程都需要執行，佔用CPU時間。如果線程競爭不激烈，並且保持鎖的時間段。適合使用自旋鎖。
註：該例子為非公平鎖，獲得鎖的先後順序，不會按照進入lock的先後順序進行。
Java鎖的種類以及辨析（二）：自旋鎖的其他種類
鎖作為並發共享數據，保證一致性的工具，在JAVA平台有多種實現(如 synchronized 和 ReentrantLock等等 ) 。這些已經寫好提供的鎖為我們開發提供了便利，但是鎖的具體性質以及類型卻很少被提及。本系列文章將分析JAVA下常見的鎖名稱以及特性，為大家答疑解惑。
2.自旋鎖的其他種類
上篇我們講到了自旋鎖，在自旋鎖中 另有三種常見的鎖形式:TicketLock ，CLHlock 和MCSlock
Ticket鎖主要解決的是訪問順序的問題，主要的問題是在多核cpu上
01 package com.alipay.titan.dcc.dal.entity;
02
03 import java.util.concurrent.atomic.AtomicInteger;
04
05 public class TicketLock {
06 private AtomicInteger serviceNum = new AtomicInteger();
07 private AtomicInteger ticketNum = new AtomicInteger();
08 private static final ThreadLocal<Integer> LOCAL = new ThreadLocal<Integer>();
09
10 public void lock() {
11 int myticket = ticketNum.getAndIncrement();
12 LOCAL.set(myticket);
13 while (myticket != serviceNum.get()) {
14 }
15
16 }
17
18 public void unlock() {
19 int myticket = LOCAL.get();
20 serviceNum.compareAndSet(myticket, myticket + 1);
21 }
22 }
每次都要查詢一個serviceNum 服務號，影響性能（必須要到主內存讀取，並阻止其他cpu修改）。
CLHLock 和MCSLock 則是兩種類型相似的公平鎖，採用鏈表的形式進行排序，
01 importjava.util.concurrent.atomic.AtomicReferenceFieldUpdater;
02
03 public class CLHLock {
04 public static class CLHNode {
05 private volatile boolean isLocked = true;
06 }
07
08 @SuppressWarnings("unused")
09 private volatileCLHNode tail;
10 private static finalThreadLocal<CLHNode> LOCAL = new ThreadLocal<CLHNode>();
11 private static <CLHLock, CLHNode> UPDATER = AtomicReferenceFieldUpdater.newUpdater(CLHLock.class,
12 CLHNode.class,"tail");
13
14 public void lock() {
15 CLHNode node = new CLHNode();
16 LOCAL.set(node);
17 CLHNode preNode = UPDATER.getAndSet(this, node);
18 if (preNode != null) {
19 while (preNode.isLocked) {
20 }
21 preNode = null;
22 LOCAL.set(node);
23 }
24 }
25
26 public void unlock() {
27 CLHNode node = LOCAL.get();
28 if (!UPDATER.compareAndSet(this, node,null)) {
29 node.isLocked = false;
30 }
31 node = null;
32 }
33 }
CLHlock是不停的查詢前驅變數， 導致不適合在NUMA 架構下使用（在這種結構下，每個線程分布在不同的物理內存區域）
MCSLock則是對本地變數的節點進行循環。不存在CLHlock 的問題。
01 importjava.util.concurrent.atomic.AtomicReferenceFieldUpdater;
02
03 public class MCSLock {
04 public static class MCSNode {
05 volatile MCSNode next;
06 volatile boolean isLocked = true;
07 }
08
09 private static finalThreadLocal<MCSNode> NODE = new ThreadLocal<MCSNode>();
10 @SuppressWarnings("unused")
11 private volatileMCSNode queue;
12 private static <MCSLock, MCSNode> UPDATER = AtomicReferenceFieldUpdater.newUpdater(MCSLock.class,
13 MCSNode.class,"queue");
14
15 public void lock() {
16 MCSNode currentNode = new MCSNode();
17 NODE.set(currentNode);
18 MCSNode preNode = UPDATER.getAndSet(this, currentNode);
19 if (preNode != null) {
20 preNode.next = currentNode;
21 while (currentNode.isLocked) {
22
23 }
24 }
25 }
26
27 public void unlock() {
28 MCSNode currentNode = NODE.get();
29 if (currentNode.next == null) {
30 if (UPDATER.compareAndSet(this, currentNode, null)) {
31
32 } else {
33 while (currentNode.next == null) {
34 }
35 }
36 } else {
37 currentNode.next.isLocked = false;
38 currentNode.next = null;
39 }
40 }
41 }