> 作者：幻好
> 
> 來源：[恆生LIGHT雲社群](https://developer.hs.net/thread/1264)

## -Java中鎖的概念

* 多執行緒訪問共享資源的時候，避免不了資源競爭而導致資料錯亂的問題，所以我們通常為了解決這一問題，都會在訪問共享資源之前加鎖。
* 加鎖的目的就是保證共享資源在任意時間裡，只有一個執行緒訪問，這樣就可以避免多執行緒導致共享資料錯亂的問題。

![](https://oscimg.oschina.net/oscnet/up-8c53ded11819fc7d8b1123718a4cb30016d.png)

### -鎖的型別

* 根據鎖的狀態、特性以及設計，可能會有多種區分：
  * 樂觀鎖/悲觀鎖、自旋鎖、分散式鎖、偏向鎖、輕量級鎖、重量級鎖等。

#### -樂觀鎖/悲觀鎖

> 執行緒是否需要鎖住同步資源

* 樂觀鎖與悲觀鎖是一種廣義上的概念，體現了看待執行緒同步的不同角度，在Java和資料庫中都有此概念對應的實際應用。
* 概念：
  * **悲觀鎖**認為對於同一個資料的併發操作，一定是會發生修改；悲觀的認為，不加鎖的併發操作一定會出問題。
    * 對於同一個資料的併發操作，悲觀鎖採取加鎖的形式。
    * Java中，`synchronized` 關鍵字和`Lock` 的實現類都是悲觀鎖。
  * **樂觀鎖**認為對於同一個資料的併發操作，是不會發生修改的；樂觀的認為，不加鎖的併發操作是沒有事情的。
    * 在更新資料的時候，會採用嘗試更新前判斷資料是否被別的執行緒更新。
    * 如果這個資料沒有被更新，當前執行緒將自己修改的資料成功寫入。
    * 如果資料已經被其他執行緒更新，則根據不同的實現方式執行不同的操作（例如報錯或者自動重試）。
    * Java中，透過使用無鎖程式設計來實現，最常採用的是CAS演算法，Java原子類中的遞增操作就透過CAS自旋實現的。
* ![](https://oscimg.oschina.net/oscnet/up-fdf729de77c1220b9bf15945d012970f2fc.png)
* 場景：
  * 悲觀鎖適合寫操作多的場景，先加鎖可以保證寫操作時資料正確。
  * 樂觀鎖適合讀操作多的場景，不加鎖的特點能夠使其讀操作的效能大幅提升。
* 使用示例：

*![](https://oscimg.oschina.net/oscnet/up-1c1403536e41593a95b719dcf7eb0b6a416.png)
  * 透過呼叫方式示例，可以發現悲觀鎖基本都是在顯式的鎖定之後再操作同步資源，而樂觀鎖則直接去操作同步資源。
  * 為何樂觀鎖能夠做到不鎖定同步資源也可以正確的實現執行緒同步呢？
    * 樂觀鎖的主要實現方式 “CAS” 的技術原理。
      * CAS全稱 Compare And Swap（比較與交換），是一種無鎖演算法。在不使用鎖（沒有執行緒被阻塞）的情況下實現多執行緒之間的變數同步。`java.util.concurrent` 包中的原子類就是透過CAS來實現了樂觀鎖。
  * 看下原子類AtomicInteger的原始碼，看一下`AtomicInteger` 的定義：
    * ![](https://oscimg.oschina.net/oscnet/up-f9bd36461a63359f0efa737b31516ab4b58.png)
    * 根據定義我們可以看出各屬性的作用：
      * `unsafe`： 獲取並操作記憶體的資料。
      * `valueOffset`： 儲存`value` 在`AtomicInteger` 中的偏移量。
      * `value`： 儲存`AtomicInteger` 的`int` 值，該屬性需要藉助`volatile` 關鍵字保證其線上程間是可見的。
    * 檢視`AtomicInteger` 的自增函式`incrementAndGet()` 的原始碼時，發現自增函式底層呼叫的是`unsafe.getAndAddInt()` 。
    * 透過OpenJDK 8 來檢視Unsafe的原始碼：
    * ![](https://oscimg.oschina.net/oscnet/up-aa57a8cb213a37af2d577df1ce4c360a98b.png)
    * 根據 OpenJDK 8 的原始碼我們可以看出，`getAndAddInt()` 迴圈獲取給定物件 o 中的偏移量處的值 v，然後判斷記憶體值是否等於 v 。如果相等則將記憶體值設定為 v + delta，否則返回 false，繼續迴圈進行重試，直到設定成功才能退出迴圈，並且將舊值返回。整個“比較+更新”操作封裝在`compareAndSwapInt()` 中，在 JNI 裡是藉助於一個CPU指令完成的，屬於原子操作，可以保證多個執行緒都能夠看到同一個變數的修改值。
    * JDK透過CPU的`cmpxchg` 指令，去比較暫存器中的 A 和 記憶體中的值 V。如果相等，就把要寫入的新值 B 存入記憶體中。如果不相等，就將記憶體值 V 賦值給暫存器中的值 A。然後透過Java程式碼中的while迴圈再次呼叫`cmpxchg` 指令進行重試，直到設定成功為止。
  * CAS雖然很高效，但也存在三大問題：
    * **ABA問題**
      * CAS需要在操作值的時候檢查記憶體值是否發生變化，沒有發生變化才會更新記憶體值。但是如果記憶體值原來是A，後來變成了B，然後又變成了A，那麼CAS進行檢查時會發現值沒有發生變化，但是實際上是有變化的。
      * ABA問題的**解決思路**就是在變數前面新增版本號，每次變數更新的時候都把版本號加一，這樣變化過程就從“A－B－A”變成了“1A－2B－3A”。
      * JDK從1.5開始提供了`AtomicStampedReference` 類來解決ABA問題，具體操作封裝在`compareAndSet()` 中。`compareAndSet()` 首先檢查當前引用和當前標誌與預期引用和預期標誌是否相等，如果都相等，則以原子方式將引用值和標誌的值設定為給定的更新值。
    * **迴圈時間長開銷大**
      * CAS操作如果長時間不成功，會導致其一直自旋，給CPU帶來非常大的開銷。
    * **只能保證一個共享變數的原子操作**
      * 對一個共享變數執行操作時，CAS能夠保證原子操作，但是對多個共享變數操作時，CAS是無法保證操作的原子性的。
      * Java從1.5開始JDK提供了`AtomicReference` 類來保證引用物件之間的原子性，可以把多個變數放在一個物件裡來進行CAS操作。

#### -阻塞鎖/自旋鎖/適應性自旋鎖

* 背景：
  * 阻塞或喚醒一個Java執行緒需要作業系統切換CPU狀態來完成，這種狀態轉換需要耗費處理器時間。如果同步程式碼塊中的內容過於簡單，狀態轉換消耗的時間有可能比使用者程式碼執行的時間還要長。
  * 在許多場景中，同步資源的鎖定時間很短，為了這一小段時間去切換執行緒，執行緒掛起和恢復現場的花費可能會讓系統得不償失。如果物理機器有多個處理器，能夠讓兩個或以上的執行緒同時並行執行，我們就可以讓後面那個請求鎖的執行緒不放棄CPU的執行時間，看看持有鎖的執行緒是否很快就會釋放鎖。
* **阻塞鎖**
  * 讓執行緒進入阻塞狀態進行等待，當獲得相應的訊號（喚醒，時間） 時，才可以進入執行緒的準備就緒狀態，準備就緒狀態的所有執行緒，透過競爭，進入執行狀態。
  * JAVA中，能夠進入\退出、阻塞狀態或包含阻塞鎖的方法有，`synchronized` 關鍵字（其中的重量鎖），`ReentrantLock` ，`Object.wait()\notify(),LockSupport.park()/unpart()`(j.u.c經常使用)
* **自旋鎖**
  * 在Java中，嘗試獲取鎖的執行緒不會立即阻塞，而是採用迴圈的方式去嘗試獲取鎖，這樣的好處是減少執行緒上下文切換的消耗，缺點是迴圈會消耗CPU效能。
  *![](https://oscimg.oschina.net/oscnet/up-66aa809b0e73ffb922574fba7851ff005c5.png)
  * 自旋鎖本身是有缺點的，它不能代替阻塞。自旋等待雖然避免了執行緒切換的開銷，但它要佔用處理器時間。如果鎖被佔用的時間很短，自旋等待的效果就會非常好。反之，如果鎖被佔用的時間很長，那麼自旋的執行緒只會白浪費處理器資源。
  * 自旋等待的時間必須要有一定的限度，如果自旋超過了限定次數（預設是10次，可以使用`-XX:PreBlockSpin` 來更改）沒有成功獲得鎖，就應當掛起執行緒。
  * 自旋鎖的實現原理同樣也是CAS，`AtomicInteger` 中呼叫`unsafe` 進行自增操作的原始碼中的do-while迴圈就是一個自旋操作，如果修改數值失敗則透過迴圈來執行自旋，直至修改成功。
  * 自旋鎖在JDK1.4.2中引入，使用`-XX:+UseSpinning` 來開啟。JDK 6中變為預設開啟，並且引入了自適應的自旋鎖（適應性自旋鎖）。
* **自適應自旋鎖**
  * 自適應意味著自旋的時間（次數）不再固定，而是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態來決定。
  * 如果在同一個鎖物件上，自旋等待剛剛成功獲得過鎖，並且持有鎖的執行緒正在執行中，那麼虛擬機器就會認為這次自旋也是很有可能再次成功，進而它將允許自旋等待持續相對更長的時間。
  * 如果對於某個鎖，自旋很少成功獲得過，那在以後嘗試獲取這個鎖時將可能省略掉自旋過程，直接阻塞執行緒，避免浪費處理器資源。
* 在自旋鎖中，另有三種常見的鎖形式：`TicketLock`、`CLHlock` 和`MCSlock`

#### -無鎖/偏向鎖/輕量級鎖/重量級鎖

* 背景：
  * 這四種鎖是指鎖的狀態，專門針對`synchronized` 的，鎖的升級是單向的，不可逆轉。
  * `synchronized` 是悲觀鎖，在操作同步資源之前需要給同步資源先加鎖，這把鎖就是存在Java物件頭裡的。
    * 以 Hotspot 虛擬機器為例，Hotspot 的物件頭主要包括兩部分資料：`Mark Word`（標記欄位）、`Klass Pointer`（型別指標）。
    * `Mark Word`：預設儲存物件的HashCode，分代年齡和鎖標誌位資訊。這些資訊都是與物件自身定義無關的資料，所以Mark Word被設計成一個非固定的資料結構以便在極小的空間記憶體儲存儘量多的資料。它會根據物件的狀態複用自己的儲存空間，也就是說在執行期間Mark Word裡儲存的資料會隨著鎖標誌位的變化而變化。
    * `Klass Point`：物件指向它的類後設資料的指標，虛擬機器透過這個指標來確定這個物件是哪個類的例項。
    * `Monitor` 可以理解為一個同步工具或一種同步機制，通常被描述為一個物件。每一個 Java 物件就有一把看不見的鎖，稱為內部鎖或者`Monitor` 鎖。
  * 在自旋鎖中提到的“阻塞或喚醒一個Java執行緒需要作業系統切換CPU狀態來完成，這種狀態轉換需要耗費處理器時間。如果同步程式碼塊中的內容過於簡單，狀態轉換消耗的時間有可能比使用者程式碼執行的時間還要長”。這種方式就是synchronized最初實現同步的方式，這就是JDK 6之前`synchronized` 效率低的原因。這種依賴於作業系統`Mutex Lock` 所實現的鎖我們稱之為“重量級鎖”，JDK 6中為了減少獲得鎖和釋放鎖帶來的效能消耗，引入了“偏向鎖”和“輕量級鎖”。
  * 目前鎖一共有4種狀態，級別從低到高依次是：無鎖、偏向鎖、輕量級鎖和重量級鎖。鎖狀態只能升級不能降級。
* **無鎖**
  * 無鎖沒有對資源進行鎖定，所有的執行緒都能訪問並修改同一個資源，但同時只有一個執行緒能修改成功。
  * 無鎖的特點就是修改操作在迴圈內進行，執行緒會不斷的嘗試修改共享資源。如果沒有衝突就修改成功並退出，否則就會繼續迴圈嘗試。如果有多個執行緒修改同一個值，必定會有一個執行緒能修改成功，而其他修改失敗的執行緒會不斷重試直到修改成功。
  * CAS原理及應用即是無鎖的實現。無鎖無法全面代替有鎖，但無鎖在某些場合下的效能是非常高的。
* **偏向鎖**
  * 指一段同步程式碼一直被一個執行緒所訪問，那麼該執行緒會自動獲取鎖。降低獲取鎖的代價。
  * 在大多數情況下，鎖總是由同一執行緒多次獲得，不存在多執行緒競爭，所以出現了偏向鎖。其目標就是在只有一個執行緒執行同步程式碼塊時能夠提高效能。
  * 當一個執行緒訪問同步程式碼塊並獲取鎖時，會在Mark Word裡儲存鎖偏向的執行緒ID。線上程進入和退出同步塊時不再透過CAS操作來加鎖和解鎖，而是檢測Mark Word裡是否儲存著指向當前執行緒的偏向鎖。引入偏向鎖是為了在無多執行緒競爭的情況下儘量減少不必要的輕量級鎖執行路徑，因為輕量級鎖的獲取及釋放依賴多次CAS原子指令，而偏向鎖只需要在置換ThreadID的時候依賴一次CAS原子指令即可。
  * 偏向鎖只有遇到其他執行緒嘗試競爭偏向鎖時，持有偏向鎖的執行緒才會釋放鎖，執行緒不會主動釋放偏向鎖。偏向鎖的撤銷，需要等待全域性安全點（在這個時間點上沒有位元組碼正在執行），它會首先暫停擁有偏向鎖的執行緒，判斷鎖物件是否處於被鎖定狀態。撤銷偏向鎖後恢復到無鎖（標誌位為“01”）或輕量級鎖（標誌位為“00”）的狀態。
  * 偏向鎖在JDK 6及以後的JVM裡是預設啟用的。可以透過JVM引數關閉偏向鎖：`-XX:-UseBiasedLocking=false`，關閉之後程式預設會進入輕量級鎖狀態。
* **輕量級鎖**
  * 指當鎖是偏向鎖的時候，被另一個執行緒所訪問，偏向鎖就會升級為輕量級鎖，其他執行緒會透過自旋的形式嘗試獲取鎖，不會阻塞，提高效能。
  * 產生過程：
    * 在程式碼進入同步塊的時候，如果同步物件鎖狀態為無鎖狀態（鎖標誌位為“01”狀態，是否為偏向鎖為“0”），虛擬機器首先將在當前執行緒的棧幀中建立一個名為鎖記錄（Lock Record）的空間，用於儲存鎖物件目前的`Mark Word` 的複製，然後複製物件頭中的`Mark Word` 複製到鎖記錄中。
    * 複製成功後，虛擬機器將使用CAS操作嘗試將物件的Mark Word更新為指向 Lock Record 的指標，並將 Lock Record 裡的 owner 指標指向物件的`Mark Word` 。
    * 如果這個更新動作成功了，那麼這個執行緒就擁有了該物件的鎖，並且物件`Mark Word` 的鎖標誌位設定為“00”，表示此物件處於輕量級鎖定狀態。
    * 如果輕量級鎖的更新操作失敗了，虛擬機器首先會檢查物件的`Mark Word` 是否指向當前執行緒的棧幀，如果是就說明當前執行緒已經擁有了這個物件的鎖，那就可以直接進入同步塊繼續執行，否則說明多個執行緒競爭鎖。
    * 若當前只有一個等待執行緒，則該執行緒透過自旋進行等待。但是當自旋超過一定的次數，或者一個執行緒在持有鎖，一個在自旋，又有第三個來訪時，輕量級鎖升級為重量級鎖。
* **重量級鎖**
  * 指當鎖為輕量級鎖的時候，另一個執行緒雖然是自旋，當自旋一定次數的時候，還沒有獲取到鎖，就會進入阻塞，該鎖膨脹為重量級鎖。重量級鎖會讓其他申請的執行緒進入阻塞，效能降低。
  * 升級為重量級鎖時，鎖標誌的狀態值變為“10”，此時Mark Word中儲存的是指向重量級鎖的指標，此時等待鎖的執行緒都會進入阻塞狀態。
* 綜上，偏向鎖透過對比`Mark Word` 解決加鎖問題，避免執行CAS操作。而輕量級鎖是透過用CAS操作和自旋來解決加鎖問題，避免執行緒阻塞和喚醒而影響效能。重量級鎖是將除了擁有鎖的執行緒以外的執行緒都阻塞。

#### -公平鎖/非公平鎖

* **公平鎖**
  * 指多個執行緒按照申請鎖的順序來獲取鎖，執行緒直接進入佇列中排隊，佇列中的第一個執行緒才能獲得鎖。
  * 優點是等待鎖的執行緒不會餓死。
  * 缺點是整體吞吐效率相對非公平鎖要低，等待佇列中除第一個執行緒以外的所有執行緒都會阻塞，CPU喚醒阻塞執行緒的開銷比非公平鎖大。
  * ![](https://oscimg.oschina.net/oscnet/up-afa5081a5b4852d2253b56cf504487915f5.png)
* **非公平鎖**
  * 指多個執行緒獲取鎖的順序並不是按照申請鎖的順序，獲取不到才會到等待佇列的隊尾等待，有可能後申請的執行緒比先申請的執行緒優先獲取鎖。（有可能，會造成優先順序反轉或者飢餓現象。）
  * 優點是可以減少喚起執行緒的開銷，整體的吞吐效率高，因為執行緒有機率不阻塞直接獲得鎖，CPU不必喚醒所有執行緒。
  * 缺點是處於等待佇列中的執行緒可能會餓死，或者等很久才會獲得鎖。
  
  ![](https://oscimg.oschina.net/oscnet/up-fbc58032c807ff60c8c31cb822b529a919f.png)
* 例項：
  * 對於Java 的`ReentrantLock` 而言，透過建構函式指定該鎖是否是公平鎖，預設是非公平鎖。非公平鎖的優點在於吞吐量比公平鎖大。
    ![](https://oscimg.oschina.net/oscnet/up-1837ce45bcc8c0838bf39fa6e0c83e53a27.png)
    * 根據程式碼可知，`ReentrantLock` 裡面有一個內部類`Sync` ，`Sync` 繼承AQS（`AbstractQueuedSynchronizer`），新增鎖和釋放鎖的大部分操作實際上都是在Sync中實現的。它有公平鎖`FairSync` 和非公平鎖`NonfairSync` 兩個子類。`ReentrantLock` 預設使用非公平鎖，也可以透過構造器來顯示的指定使用公平鎖。
    *![](https://oscimg.oschina.net/oscnet/up-ed81101c6181640cd9aef884bd340192c38.png)
    * 可以明顯的看出公平鎖與非公平鎖的`lock()` 方法唯一的區別就在於公平鎖在獲取同步狀態時多了一個限制條件：`hasQueuedPredecessors()` 。
      *![](https://oscimg.oschina.net/oscnet/up-65ba3e4ac4e4cd8ad557d3964284e0e7f60.png)
      * 進入`hasQueuedPredecessors()` ，可以看到該方法主要做一件事情：主要是判斷當前執行緒是否位於同步佇列中的第一個。如果是則返回true，否則返回false。
  * 對於`Synchronized` 而言，也是一種非公平鎖。由於其並不像`ReentrantLock` 是透過AQS的來實現執行緒排程，所以並沒有任何辦法使其變成公平鎖。
* 綜上，公平鎖就是透過同步佇列來實現多個執行緒按照申請鎖的順序來獲取鎖，從而實現公平的特性。非公平鎖加鎖時不考慮排隊等待問題，直接嘗試獲取鎖，所以存在後申請卻先獲得鎖的情況。

#### -可重入鎖/非可重入鎖

* **可重入鎖**
  * 又名遞迴鎖，是指在同一個執行緒在外層方法獲取鎖的時候，在進入內層方法會自動獲取鎖（前提鎖物件得是同一個物件或者class），不會因為之前已經獲取過還沒釋放而阻塞。
* Java中`ReentrantLock` 和`synchronized` 都是可重入鎖，可重入鎖的一個優點是可一定程度避免死鎖。
  ![](https://oscimg.oschina.net/oscnet/up-e32f6a2c6cbeef24f0d043656aace45b578.png)
  * 上面的程式碼中，類中的兩個方法都是被內建鎖`synchronized` 修飾的，`doSomething()` 方法中呼叫`doOthers()` 方法。因為內建鎖是可重入的，所以同一個執行緒在呼叫`doOthers()` 時可以直接獲得當前物件的鎖，進入`doOthers()` 進行操作。
  * 如果是一個不可重入鎖，那麼當前執行緒在呼叫`doOthers()` 之前需要將執行`doSomething()` 時獲取當前物件的鎖釋放掉，實際上該物件鎖已被當前執行緒所持有，且無法釋放，所以此時會出現死鎖。
* 非可重入鎖導致死鎖原因分析
  * 透過重入鎖`ReentrantLock` 以及非可重入鎖`NonReentrantLock` 的原始碼來對比分析一下為什麼非可重入鎖在重複呼叫同步資源時會出現死鎖。
  * 首先`ReentrantLock` 和`NonReentrantLock` 都繼承父類AQS，其父類AQS中維護了一個同步狀態`status` 來計數重入次數，status初始值為0。
  * 當執行緒嘗試獲取鎖時，可重入鎖先嚐試獲取並更新`status` 值，如果`status == 0` 表示沒有其他執行緒在執行同步程式碼，則把`status` 置為1，當前執行緒開始執行。如果`status != 0` ，則判斷當前執行緒是否是獲取到這個鎖的執行緒，如果是的話執行`status+1`，且當前執行緒可以再次獲取鎖。而非可重入鎖是直接去獲取並嘗試更新當前`status` 的值，如果`status != 0` 的話會導致其獲取鎖失敗，當前執行緒阻塞。
  * 釋放鎖時，可重入鎖同樣先獲取當前`status` 的值，在當前執行緒是持有鎖的執行緒的前提下。如果`status-1 == 0` ，則表示當前執行緒所有重複獲取鎖的操作都已經執行完畢，然後該執行緒才會真正釋放鎖。而非可重入鎖則是在確定當前執行緒是持有鎖的執行緒之後，直接將`status` 置為0，將鎖釋放。
  * ![](https://oscimg.oschina.net/oscnet/up-ef5755e5afd63e34d064f22ce761a55f55d.png)

#### -獨享鎖/共享鎖

* 獨享鎖和共享鎖同樣是一種概念。
* **獨享鎖**

* 也叫排他鎖，是指該鎖一次只能被一個執行緒所持有。
  * 如果執行緒T對資料A加上排它鎖後，則其他執行緒不能再對A加任何型別的鎖。
  * 獲得排它鎖的執行緒即能讀資料又能修改資料。JDK中的`synchronized` 和 JUC 中`Lock` 的實現類就是互斥鎖。
* **共享鎖**

* 指該鎖可被多個執行緒所持有。
  * 如果執行緒T對資料A加上共享鎖後，則其他執行緒只能對A再加共享鎖，不能加排它鎖。
  * 獲得共享鎖的執行緒只能讀資料，不能修改資料。
* 獨享鎖與共享鎖也是透過AQS來實現的，透過實現不同的方法，來實現獨享或者共享。透過 `ReentrantLock` 和 `ReentrantReadWriteLock` 的原始碼來介紹獨享鎖和共享鎖。

![](https://oscimg.oschina.net/oscnet/up-a70bbad0745dbeeda7838a424b163365447.png)
 ![](https://oscimg.oschina.net/oscnet/up-b188881fec7cfda9439ab14515575cbdb31.png)
 ![](https://oscimg.oschina.net/oscnet/up-3e879d276d206567f0b8413717c664a7704.png)
  * `ReentrantReadWriteLock` 有兩把鎖：`ReadLock` 和 `WriteLock` ，由詞知意，一個讀鎖一個寫鎖，合稱“讀寫鎖”。再進一步觀察可以發現 `ReadLock` 和 `WriteLock` 是靠內部類Sync實現的鎖。`Sync` 是AQS的一個子類，這種結構在 `CountDownLatch` 、`ReentrantLock` 、`Semaphore` 裡面也都存在。
  * 在 `ReentrantReadWriteLock` 裡面，讀鎖和寫鎖的鎖主體都是 `Sync` ，但讀鎖和寫鎖的加鎖方式不一樣。讀鎖是共享鎖，寫鎖是獨享鎖。讀鎖的共享鎖可保證併發讀非常高效，而讀寫、寫讀、寫寫的過程互斥，因為讀鎖和寫鎖是分離的。所以 `ReentrantReadWriteLock` 的併發性相比一般的互斥鎖有了很大提升。
  * 讀鎖和寫鎖的具體加鎖方式的區別：

* 最開始提及AQS的時候提到了`state` 欄位（int型別，32位），該欄位用來描述有多少執行緒獲持有鎖。
    * 在獨享鎖中這個值通常是0或者1（如果是重入鎖的話`state` 值就是重入的次數），在共享鎖中`state` 就是持有鎖的數量。
    * 但是在`ReentrantReadWriteLock` 中有讀、寫兩把鎖，所以需要在一個整型變數`state` 上分別描述讀鎖和寫鎖的數量（或者也可以叫狀態）。
    * 於是將state變數“按位切割”切分成了兩個部分，高16位表示讀鎖狀態（讀鎖個數），低16位表示寫鎖狀態（寫鎖個數）。
    ![](https://oscimg.oschina.net/oscnet/up-e4df7c4e14757ab0c41b0ea70f9a41ecabe.png)
  * 寫鎖的加鎖原始碼：

* ![](https://oscimg.oschina.net/oscnet/up-a6fe0f768501facab48ee79af9b86292dff.png)

* 這段程式碼首先取到當前鎖的個數c，然後再透過c來獲取寫鎖的個數w。因為寫鎖是低16位，所以取低16位的最大值與當前的c做與運算（`int w = exclusiveCount(c);` ），高16位和0與運算後是0，剩下的就是低位運算的值，同時也是持有寫鎖的執行緒數目。
      * 在取到寫鎖執行緒的數目後，首先判斷是否已經有執行緒持有了鎖。如果已經有執行緒持有了鎖（c!=0），則檢視當前寫鎖執行緒的數目，如果寫執行緒數為0（即此時存在讀鎖）或者持有鎖的執行緒不是當前執行緒就返回失敗（涉及到公平鎖和非公平鎖的實現）。
      * 如果寫入鎖的數量大於最大數（65535，2的16次方-1）就丟擲一個Error。
      * 如果當且寫執行緒數為0（那麼讀執行緒也應該為0，因為上面已經處理c!=0的情況），並且當前執行緒需要阻塞那麼就返回失敗；如果透過CAS增加寫執行緒數失敗也返回失敗。
      * 如果c=0，w=0或者c>0，w>0（重入），則設定當前執行緒或鎖的擁有者，返回成功！
    * `tryAcquire()` 除了重入條件（當前執行緒為獲取了寫鎖的執行緒）之外，增加了一個讀鎖是否存在的判斷。如果存在讀鎖，則寫鎖不能被獲取，原因在於：必須確保寫鎖的操作對讀鎖可見，如果允許讀鎖在已被獲取的情況下對寫鎖的獲取，那麼正在執行的其他讀執行緒就無法感知到當前寫執行緒的操作。
    * 因此，只有等待其他讀執行緒都釋放了讀鎖，寫鎖才能被當前執行緒獲取，而寫鎖一旦被獲取，則其他讀寫執行緒的後續訪問均被阻塞。寫鎖的釋放與 `ReentrantLock` 的釋放過程基本類似，每次釋放均減少寫狀態，當寫狀態為0時表示寫鎖已被釋放，然後等待的讀寫執行緒才能夠繼續訪問讀寫鎖，同時前次寫執行緒的修改對後續的讀寫執行緒可見。
  * 讀鎖的程式碼：

![](https://oscimg.oschina.net/oscnet/up-41fae7542d52d239f680c449bf53bcaa8e9.png)
    * 在`tryAcquireShared(int unused)` 方法中，如果其他執行緒已經獲取了寫鎖，則當前執行緒獲取讀鎖失敗，進入等待狀態。
    * 如果當前執行緒獲取了寫鎖或者寫鎖未被獲取，則當前執行緒（執行緒安全，依靠CAS保證）增加讀狀態，成功獲取讀鎖。
    * 讀鎖的每次釋放（執行緒安全的，可能有多個讀執行緒同時釋放讀鎖）均減少讀狀態，減少的值是“1<<16”。
    * 所以讀寫鎖才能實現讀讀的過程共享，而讀寫、寫讀、寫寫的過程互斥。
* 例項：

* 對於Java`ReentrantLock` 而言，其是獨享鎖。但是對於`Lock` 的另一個實現類`ReadWriteLock` ，其讀鎖是共享鎖，其寫鎖是獨享鎖。
  * 讀鎖的共享鎖可保證併發讀是非常高效的，讀寫，寫讀 ，寫寫的過程是互斥的。
  * 獨享鎖與共享鎖也是透過AQS來實現的，透過實現不同的方法，來實現獨享或者共享。
  * 對於`Synchronized` 而言，當然是獨享鎖。

#### -互斥鎖/讀寫鎖

* 上面講的獨享鎖/共享鎖就是一種廣義的說法，互斥鎖/讀寫鎖就是具體的實現。
* 例項：
  * 互斥鎖在Java中的具體實現就是`ReentrantLock`
  * 讀寫鎖在Java中的具體實現就是`ReadWriteLock`

#### -分段鎖

* 分段鎖其實是一種鎖的設計，並不是具體的一種鎖，對於`ConcurrentHashMap`而言，其併發的實現就是透過分段鎖的形式來實現高效的併發操作。
* 分段鎖的設計目的是細化鎖的粒度，當操作不需要更新整個陣列的時候，就僅僅針對陣列中的一項進行加鎖操作。
* 例項：
  * `ConcurrentHashMap`來說一下分段鎖的含義以及設計思想，`ConcurrentHashMap`中的分段鎖稱為 Segment，它即類似於`HashMap`（JDK7與JDK8中`HashMap` 的實現）的結構，即內部擁有一個`Entry` 陣列，陣列中的每個元素又是一個連結串列；同時又是一個`ReentrantLock`（Segment繼承了`ReentrantLock` )。

### -樂觀鎖與悲觀鎖的基本原理

* 悲觀鎖做事比較悲觀，它認為**多執行緒同時修改共享資源的機率比較高，於是很容易出現衝突，所以訪問共享資源前，先要上鎖**。
* 樂觀鎖做事比較樂觀，它假定衝突的機率很低，它的工作方式是：**先修改完共享資源，再驗證這段時間內有沒有發生衝突，如果沒有其他執行緒在修改資源，那麼操作完成，如果發現有其他執行緒已經修改過這個資源，就放棄本次操作**。

### -CAS的原理

* 在電腦科學中，比較和交換（Conmpare And Swap）是用於實現多執行緒同步的原子指令。
* 它將記憶體位置的內容與給定值進行比較，只有在相同的情況下，將該記憶體位置的內容修改為新的給定值，這是作為單個原子操作完成的。
* 原子性保證新值基於最新資訊計算；如果該值在同一時間被另一個執行緒更新，則寫入將失敗。

### -CAS的優缺點

* `ABA` 問題
  * 如果變數 V ，初次讀取時是 A 值，並且在準備賦值的時候，檢查到它仍然是 A 值，這樣能否說明它的值，沒有被其他執行緒修改過？答案是否定的，因為在這段時間內，它的值可能被更改為其他的值，然後又改回成了 A 值，那`CAS`操作就會誤認為它從來沒有被修改過。這個問題，被稱為`CAS`操作的`ABA` 問題。
  * `JDK1.5`以後的`AtomicStampedReference`類提供了這樣的功能，其中的`compareAndSet()` 方法，就是首先檢查當前引用是否等於預期引用，並且當前標誌是否等於預期標誌，如果全部相等，才會以原子的方式，將該引用和該標誌的值，設定為給定的更新值。
* 迴圈時間長，開銷大
  * 自旋`CAS`（也就是不成功就一直迴圈執行直到成功），如果長時間不成功，會給CPU帶來非常大的執行開銷。 如果`JVM`能支援處理器提供的 pause 指令，那麼效率會有一定的提升，`pause`指令有兩個作用，第一，它可以延遲流水線執行指令（`de-pipeline`）,使 CPU 不會消耗過多的執行資源，延遲的時間取決於具體實現的版本，在一些處理器上延遲時間是零；第二，它可以避免在退出迴圈的時候，因記憶體順序衝突（memory order violation），而引起 CPU 流水線被清空（`CPU pipeline flush`），從而提高 CPU 的執行效率。
* 只保證單個共享變數的原子操作
  * `CAS`只對單個共享變數有效，當操作涉及跨多個共享變數時，`CAS`操作無效。但是從`JDK1.5`開始，提供了`AtomicReference`類來保證引用物件之間的原子性，你可以把多個變數放在一個物件裡，來進行`CAS`操作。所以可以使用鎖，或者利用`AtomicReference`類，把多個共享變數合併成一個共享變數來操作。

### -鎖的消除，粗化，升級，降級

* **鎖的消除**
  * JIT編譯器（Just In Time編譯器）可以動態編譯同步程式碼時，適用於一種叫做逃逸分析的技術，來透過該項技術判別程式中所使用的鎖物件是否只被一個執行緒所使用，而沒有散佈到其他執行緒中；如果情況就是這樣的話，那麼JIT編譯器在編譯這個同步程式碼時就不會生成`synchronized` 關鍵字所標識的鎖的申請與釋放機器碼，從而消除了鎖的使用流程。
* **鎖的粗化**
  * JIt編譯器在執行動態編譯時，若發現前後相鄰的`synchronized` 塊使用的是同一個鎖物件，那麼它就會把這幾個`synchronized` 塊合併為一個較大的同步塊，這樣做的好處在於執行緒在執行這些程式碼時，就不用頻繁的申請和釋放鎖了，從而達到申請與釋放鎖一次，就可以執行完全部的同步程式碼塊，從而提升了效能。
* **鎖的升級和降級**
  * 鎖的升級和降級主要都是物件頭中透過`Mark Word` 中的鎖標誌位與是否是偏向鎖標誌位來實現的；

### -互斥鎖與自旋鎖的概念與區別？

* 當已經有一個執行緒加鎖後，其他執行緒加鎖則就會失敗，互斥鎖和自旋鎖對於加鎖失敗後的處理方式是不一樣的：
  * **互斥鎖**加鎖失敗後，執行緒會**釋放 CPU** ，給其他執行緒；
  * **自旋鎖**加鎖失敗後，執行緒會**忙等待**，直到它拿到鎖；
* 互斥鎖是一種「獨佔鎖」，比如當執行緒 A 加鎖成功後，此時互斥鎖已經被執行緒 A 獨佔了，只要執行緒 A 沒有釋放手中的鎖，執行緒 B 加鎖就會失敗，於是就會釋放 CPU 讓給其他執行緒，**既然執行緒 B 釋放掉了 CPU，自然執行緒 B 加鎖的程式碼就會被阻塞**。
  * **對於互斥鎖加鎖失敗而阻塞的現象，是由作業系統核心實現的**。當加鎖失敗時，核心會將執行緒置為「睡眠」狀態，等到鎖被釋放後，核心會在合適的時機喚醒執行緒，當這個執行緒成功獲取到鎖後，於是就可以繼續執行。
  * 所以，互斥鎖加鎖失敗時，會從使用者態陷入到核心態，讓核心幫我們切換執行緒，雖然簡化了使用鎖的難度，但是存在一定的效能開銷成本。
  * 那這個開銷成本是什麼呢？會有**兩次執行緒上下文切換的成本**：
    * 當執行緒加鎖失敗時，核心會把執行緒的狀態從「執行」狀態設定為「睡眠」狀態，然後把 CPU 切換給其他執行緒執行；
    * 接著，當鎖被釋放時，之前「睡眠」狀態的執行緒會變為「就緒」狀態，然後核心會在合適的時間，把 CPU 切換給該執行緒執行。
  * 所以，**如果你能確定被鎖住的程式碼執行時間很短，就不應該用互斥鎖，而應該選用自旋鎖，否則使用互斥鎖。**
* 自旋鎖是透過 CPU 提供的`CAS` 函式（*Compare And Swap*），在「使用者態」完成加鎖和解鎖操作，不會主動產生執行緒上下文切換，所以相比互斥鎖來說，會快一些，開銷也小一些。
  * 一般加鎖的過程，包含兩個步驟：
    * 第一步，檢視鎖的狀態，如果鎖是空閒的，則執行第二步；
    * 第二步，將鎖設定為當前執行緒持有；
  * 自旋鎖是最比較簡單的一種鎖，一直自旋，利用 CPU 週期，直到鎖可用。**需要注意，在單核 CPU 上，需要搶佔式的排程器（即不斷透過時鐘中斷一個執行緒，執行其他執行緒）。否則，自旋鎖在單 CPU 上無法使用，因為一個自旋的執行緒永遠不會放棄 CPU。**
* 自旋鎖與互斥鎖使用層面比較相似，但實現層面上完全不同：**當加鎖失敗時，互斥鎖用「執行緒切換」來應對，自旋鎖則用「忙等待」來應對**。

### -讀寫鎖的優先順序區分？

* 讀寫鎖從字面意思我們也可以知道，它由「讀鎖」和「寫鎖」兩部分構成，如果只讀取共享資源用「讀鎖」加鎖，如果要修改共享資源則用「寫鎖」加鎖。
* 讀寫鎖的工作原理是：
  * 當「寫鎖」沒有被執行緒持有時，多個執行緒能夠併發地持有讀鎖，這大大提高了共享資源的訪問效率，因為「讀鎖」是用於讀取共享資源的場景，所以多個執行緒同時持有讀鎖也不會破壞共享資源的資料。
  * 但是，一旦「寫鎖」被執行緒持有後，讀執行緒的獲取讀鎖的操作會被阻塞，而且其他寫執行緒的獲取寫鎖的操作也會被阻塞。
* 寫鎖是獨佔鎖，因為任何時刻只能有一個執行緒持有寫鎖，類似互斥鎖和自旋鎖，而讀鎖是共享鎖，因為讀鎖可以被多個執行緒同時持有。
* 讀優先鎖期望的是，讀鎖能被更多的執行緒持有，以便提高讀執行緒的併發性，它的工作方式是：當讀執行緒 A 先持有了讀鎖，寫執行緒 B 在獲取寫鎖的時候，會被阻塞，並且在阻塞過程中，後續來的讀執行緒 C 仍然可以成功獲取讀鎖，最後直到讀執行緒 A 和 C 釋放讀鎖後，寫執行緒 B 才可以成功獲取讀鎖。

## -死鎖的概念

* 死鎖是這樣一種情形：多個執行緒同時被阻塞，它們中的一個或者全部都在等待某個資源被釋放。由於執行緒被無限期地阻塞，因此程式不可能正常終止。
* Java 中死鎖產生的四個**必要條件**：
  * **互斥條件**，即當資源被一個執行緒使用(佔有)時，別的執行緒不能使用；
  * **不可搶佔**，資源請求者不能強制從資源佔有者手中奪取資源，資源只能由資源佔有者主動釋放；
  * **請求和保持**，即當資源請求者在請求其他的資源的同時保持對原有資源的佔有；
  * **迴圈等待**，即存在一個等待佇列：P1佔有P2的資源，P2佔有P3的資源，P3佔有P1的資源。這樣就形成了一個等待環路。
* 當上述四個條件都成立的時候，便形成死鎖。當然，死鎖的情況下如果打破上述任何一個條件，便可讓死鎖消失。

### -死鎖產生的場景

* 發生死鎖的場景有：
  * 順序加鎖時導致死鎖；
  * 相互協作物件呼叫導致死鎖；
  * 動態加鎖時導致死鎖；

### -死鎖的定位

* 在我們實際專案中，為了解決死鎖問題，前提是需要先定位到死鎖發生的具體位置。
* 死鎖例項程式碼：

```
public class Deadlock {
    public static String obj01 = "objA";
    public static String obj02 = "objB";

public static void main(String[] args) {
        LockA lockA = new LockA();
        LockB lockB = new LockB();
        new Thread(lockA).start();
        new Thread(lockB).start();
    }

public static class LockA implements Runnable {
        @Override
        public void run() {
            try {
                System.out.println(new Date().toString() + "LockA 開始執行");
                synchronized (Deadlock.obj01) {
                    System.out.println(new Date().toString() + "LockA 鎖住物件 objA");
                    Thread.sleep(1000);
                    synchronized (Deadlock.obj02){
                        System.out.println(new Date().toString() + "LockA 鎖住物件 objB");
                        Thread.sleep(60 * 1000); // 為測試，佔用了就不放
                    }
                    System.out.println(new Date().toString() + "LockA 釋放物件 objA");
                }
                System.out.println(new Date().toString() + "LockA 釋放物件 objB");
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }

public static class LockB implements Runnable {
        @Override
        public void run() {
            try {
                System.out.println(new Date().toString() + "LockB 開始執行");
                synchronized (Deadlock.obj02) {
                    System.out.println(new Date().toString() + "LockB 鎖住物件 objB");
                    Thread.sleep(1000);
                    synchronized (Deadlock.obj01){
                        System.out.println(new Date().toString() + "LockB 鎖住物件 objA");
                        Thread.sleep(60 * 1000); // 為測試，佔用了就不放
                    }
                    System.out.println(new Date().toString() + "LockA 釋放物件 objB");
                }
                System.out.println(new Date().toString() + "LockA 釋放物件 objA");
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }
}
```

* 執行以上例項程式碼，然後透過一下方法對死鎖進行定位：
  * 1. 使用命令`jstack -l [pid]` 進行定位

* 首先在專案控制檯輸入命令`jps` ，找到死鎖的執行緒pid

```
>jps
13136 Deadlock
15952 Launcher
18784 Launcher
9172 RemoteMavenServer36
20376 Jps
11996
```

```
- 然後發現 pid 為 13136 的執行緒，發生了死鎖
  - 然後輸入命令 `jstack -l 13136` ，列印出執行緒具體資訊
     - ![image.png](https://cdn.nlark.com/yuque/0/2021/png/3010199/1627740718472-84b9a835-a6b9-4799-998b-d0ce890e0058.png#align=left&display=inline&height=416&margin=%5Bobject%20Object%5D&name=image.png&originHeight=636&originWidth=987&size=59400&status=done&style=shadow&width=646)
  - 可以看到具體死鎖發生的方法和程式碼行數，方便我們解決死鎖問題。
```

* 2. 使用`JConsole` 圖形化工具，定位死鎖

* 在命令控制檯輸入`jconsole` ，執行工具
    ![](https://oscimg.oschina.net/oscnet/up-71353e02e693fcd91267813bccc6249fe53.png)
    * 選擇專案執行的程式連線
    * 進入圖形化監控介面後，進入執行緒介面，有個檢測死鎖的按鈕，會自動檢測死鎖執行緒
    * 工具找到具體死鎖的程式碼位置。

### -如何避免死鎖

* 系統中發生死鎖會導致多個任務無法執行，造成無盡的等待，嚴重時會導致系統的崩潰等重大事故。
* 為了避免死鎖，得先從死鎖的四個條件入手：
  * 1.互斥；2.不可剝奪；3.迴圈等待；4.請求保持；
* 具體方法：
  * 1. **避免使用多個鎖**， 且只有需要時才持有鎖，巢狀的`synchronized` 或者`lock` 非常容易出現問題。
  * 2. **固定加鎖的順序**，所有執行緒儘量以固定的順序來獲得鎖。
  * 3. **超時自動釋放鎖**，使用帶超時的方法，為程式帶來更多可控性。

* `Object.wait()` 或者`CountDownLatch.await()` ，都支援所謂的 timed wait，指定超時時間，併為無法得到鎖時準備退出邏輯。
    * 使用顯式Lock鎖，在獲取鎖時使用`tryLock()` 方法。當等待**超過時限**的時候，`tryLock()` 不會一直等待，而是返回錯誤資訊。

```
if(lock.tryLock() || lock.tryLock(timeout, unit)){
    // ...
}
```

Java開發工程師進階篇- 掃盲Java中的各種鎖，你學廢了嗎?

相關文章