轉：不可不說的Java“鎖”事

前言

Java提供了種類豐富的鎖，每種鎖因其特性的不同，在適當的場景下能夠展現出非常高的效率。本文旨在對鎖相關原始碼（本文中的原始碼來自JDK 8）、使用場景進行舉例，為讀者介紹主流鎖的知識點，以及不同的鎖的適用場景。

Java中往往是按照是否含有某一特性來定義鎖，我們通過特性將鎖進行分組歸類，再使用對比的方式進行介紹，幫助大家更快捷的理解相關知識。下面給出本文內容的總體分類目錄：

1. 樂觀鎖 VS 悲觀鎖

樂觀鎖與悲觀鎖是一種廣義上的概念，體現了看待執行緒同步的不同角度。在Java和資料庫中都有此概念對應的實際應用。

先說概念。對於同一個資料的併發操作，悲觀鎖認為自己在使用資料的時候一定有別的執行緒來修改資料，因此在獲取資料的時候會先加鎖，確保資料不會被別的執行緒修改。Java中，synchronized關鍵字和Lock的實現類都是悲觀鎖。

而樂觀鎖認為自己在使用資料時不會有別的執行緒修改資料，所以不會新增鎖，只是在更新資料的時候去判斷之前有沒有別的執行緒更新了這個資料。如果這個資料沒有被更新，當前執行緒將自己修改的資料成功寫入。如果資料已經被其他執行緒更新，則根據不同的實現方式執行不同的操作（例如報錯或者自動重試）。

樂觀鎖在Java中是通過使用無鎖程式設計來實現，最常採用的是CAS演算法，Java原子類中的遞增操作就通過CAS自旋實現的。

根據從上面的概念描述我們可以發現：

• 悲觀鎖適合寫操作多的場景，先加鎖可以保證寫操作時資料正確。
• 樂觀鎖適合讀操作多的場景，不加鎖的特點能夠使其讀操作的效能大幅提升。

光說概念有些抽象，我們來看下樂觀鎖和悲觀鎖的呼叫方式示例：

// ------------------------- 悲觀鎖的呼叫方式 -------------------------
// synchronized
public synchronized void testMethod() {
    // 操作同步資源
}
// ReentrantLock
private ReentrantLock lock = new ReentrantLock(); // 需要保證多個執行緒使用的是同一個鎖
public void modifyPublicResources() {
    lock.lock();
    // 操作同步資源
    lock.unlock();
}

// ------------------------- 樂觀鎖的呼叫方式 -------------------------
private AtomicInteger atomicInteger = new AtomicInteger();  // 需要保證多個執行緒使用的是同一個AtomicInteger
atomicInteger.incrementAndGet(); //執行自增1複製程式碼

通過呼叫方式示例，我們可以發現悲觀鎖基本都是在顯式的鎖定之後再操作同步資源，而樂觀鎖則直接去操作同步資源。那麼，為何樂觀鎖能夠做到不鎖定同步資源也可以正確的實現執行緒同步呢？我們通過介紹樂觀鎖的主要實現方式 “CAS” 的技術原理來為大家解惑。

CAS全稱 Compare And Swap（比較與交換），是一種無鎖演算法。在不使用鎖（沒有執行緒被阻塞）的情況下實現多執行緒之間的變數同步。java.util.concurrent包中的原子類就是通過CAS來實現了樂觀鎖。

CAS演算法涉及到三個運算元：

• 需要讀寫的記憶體值 V。
• 進行比較的值 A。
• 要寫入的新值 B。

當且僅當 V 的值等於 A 時，CAS通過原子方式用新值B來更新V的值（“比較+更新”整體是一個原子操作），否則不會執行任何操作。一般情況下，“更新”是一個不斷重試的操作。

之前提到java.util.concurrent包中的原子類，就是通過CAS來實現了樂觀鎖，那麼我們進入原子類AtomicInteger的原始碼，看一下AtomicInteger的定義：

根據定義我們可以看出各屬性的作用：

• unsafe： 獲取並操作記憶體的資料。
• valueOffset： 儲存value在AtomicInteger中的偏移量。
• value： 儲存AtomicInteger的int值，該屬性需要藉助volatile關鍵字保證其線上程間是可見的。

接下來，我們檢視AtomicInteger的自增函式incrementAndGet()的原始碼時，發現自增函式底層呼叫的是unsafe.getAndAddInt()。但是由於JDK本身只有Unsafe.class，只通過class檔案中的引數名，並不能很好的瞭解方法的作用，所以我們通過OpenJDK 8 來檢視Unsafe的原始碼：

// ------------------------- JDK 8 -------------------------
// AtomicInteger 自增方法
public final int incrementAndGet() {
  return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
}

// Unsafe.class
public final int getAndAddInt(Object var1, long var2, int var4) {
  int var5;
  do {
      var5 = this.getIntVolatile(var1, var2);
  } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));
  return var5;
}

// ------------------------- OpenJDK 8 -------------------------
// Unsafe.java
public final int getAndAddInt(Object o, long offset, int delta) {
   int v;
   do {
       v = getIntVolatile(o, offset);
   } while (!compareAndSwapInt(o, offset, v, v + delta));
   return v;
}複製程式碼

根據OpenJDK 8的原始碼我們可以看出，getAndAddInt()迴圈獲取給定物件o中的偏移量處的值v，然後判斷記憶體值是否等於v。如果相等則將記憶體值設定為 v + delta，否則返回false，繼續迴圈進行重試，直到設定成功才能退出迴圈，並且將舊值返回。整個“比較+更新”操作封裝在compareAndSwapInt()中，在JNI裡是藉助於一個CPU指令完成的，屬於原子操作，可以保證多個執行緒都能夠看到同一個變數的修改值。

後續JDK通過CPU的cmpxchg指令，去比較暫存器中的 A 和 記憶體中的值 V。如果相等，就把要寫入的新值 B 存入記憶體中。如果不相等，就將記憶體值 V 賦值給暫存器中的值 A。然後通過Java程式碼中的while迴圈再次呼叫cmpxchg指令進行重試，直到設定成功為止。

CAS雖然很高效，但是它也存在三大問題，這裡也簡單說一下：

1.ABA問題。CAS需要在操作值的時候檢查記憶體值是否發生變化，沒有發生變化才會更新記憶體值。但是如果記憶體值原來是A，後來變成了B，然後又變成了A，那麼CAS進行檢查時會發現值沒有發生變化，但是實際上是有變化的。ABA問題的解決思路就是在變數前面新增版本號，每次變數更新的時候都把版本號加一，這樣變化過程就從“A－B－A”變成了“1A－2B－3A”。

JDK從1.5開始提供了AtomicStampedReference類來解決ABA問題，具體操作封裝在compareAndSet()中。compareAndSet()首先檢查當前引用和當前標誌與預期引用和預期標誌是否相等，如果都相等，則以原子方式將引用值和標誌的值設定為給定的更新值。

2.迴圈時間長開銷大。CAS操作如果長時間不成功，會導致其一直自旋，給CPU帶來非常大的開銷。

3.只能保證一個共享變數的原子操作。對一個共享變數執行操作時，CAS能夠保證原子操作，但是對多個共享變數操作時，CAS是無法保證操作的原子性的。

Java從1.5開始JDK提供了AtomicReference類來保證引用物件之間的原子性，可以把多個變數放在一個物件裡來進行CAS操作。

2. 自旋鎖 VS 適應性自旋鎖

在介紹自旋鎖前，我們需要介紹一些前提知識來幫助大家明白自旋鎖的概念。

阻塞或喚醒一個Java執行緒需要作業系統切換CPU狀態來完成，這種狀態轉換需要耗費處理器時間。如果同步程式碼塊中的內容過於簡單，狀態轉換消耗的時間有可能比使用者程式碼執行的時間還要長。

在許多場景中，同步資源的鎖定時間很短，為了這一小段時間去切換執行緒，執行緒掛起和恢復現場的花費可能會讓系統得不償失。如果物理機器有多個處理器，能夠讓兩個或以上的執行緒同時並行執行，我們就可以讓後面那個請求鎖的執行緒不放棄CPU的執行時間，看看持有鎖的執行緒是否很快就會釋放鎖。

而為了讓當前執行緒“稍等一下”，我們需讓當前執行緒進行自旋，如果在自旋完成後前面鎖定同步資源的執行緒已經釋放了鎖，那麼當前執行緒就可以不必阻塞而是直接獲取同步資源，從而避免切換執行緒的開銷。這就是自旋鎖。

自旋鎖本身是有缺點的，它不能代替阻塞。自旋等待雖然避免了執行緒切換的開銷，但它要佔用處理器時間。如果鎖被佔用的時間很短，自旋等待的效果就會非常好。反之，如果鎖被佔用的時間很長，那麼自旋的執行緒只會白浪費處理器資源。所以，自旋等待的時間必須要有一定的限度，如果自旋超過了限定次數（預設是10次，可以使用-XX:PreBlockSpin來更改）沒有成功獲得鎖，就應當掛起執行緒。

自旋鎖的實現原理同樣也是CAS，AtomicInteger中呼叫unsafe進行自增操作的原始碼中的do-while迴圈就是一個自旋操作，如果修改數值失敗則通過迴圈來執行自旋，直至修改成功。

自旋鎖在JDK1.4.2中引入，使用-XX:+UseSpinning來開啟。JDK 6中變為預設開啟，並且引入了自適應的自旋鎖（適應性自旋鎖）。

自適應意味著自旋的時間（次數）不再固定，而是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態來決定。如果在同一個鎖物件上，自旋等待剛剛成功獲得過鎖，並且持有鎖的執行緒正在執行中，那麼虛擬機器就會認為這次自旋也是很有可能再次成功，進而它將允許自旋等待持續相對更長的時間。如果對於某個鎖，自旋很少成功獲得過，那在以後嘗試獲取這個鎖時將可能省略掉自旋過程，直接阻塞執行緒，避免浪費處理器資源。

在自旋鎖中 另有三種常見的鎖形式:TicketLock、CLHlock和MCSlock，本文中僅做名詞介紹，不做深入講解，感興趣的同學可以自行查閱相關資料。

3. 無鎖 VS 偏向鎖 VS 輕量級鎖 VS 重量級鎖

這四種鎖是指鎖的狀態，專門針對synchronized的。在介紹這四種鎖狀態之前還需要介紹一些額外的知識。

首先為什麼Synchronized能實現執行緒同步？

在回答這個問題之前我們需要了解兩個重要的概念：“Java物件頭”、“Monitor”。

Java物件頭

synchronized是悲觀鎖，在操作同步資源之前需要給同步資源先加鎖，這把鎖就是存在Java物件頭裡的，而Java物件頭又是什麼呢？

我們以Hotspot虛擬機器為例，Hotspot的物件頭主要包括兩部分資料：Mark Word（標記欄位）、Klass Pointer（型別指標）。

Mark Word：預設儲存物件的HashCode，分代年齡和鎖標誌位資訊。這些資訊都是與物件自身定義無關的資料，所以Mark Word被設計成一個非固定的資料結構以便在極小的空間記憶體儲存儘量多的資料。它會根據物件的狀態複用自己的儲存空間，也就是說在執行期間Mark Word裡儲存的資料會隨著鎖標誌位的變化而變化。

Klass Point：物件指向它的類後設資料的指標，虛擬機器通過這個指標來確定這個物件是哪個類的例項。

Monitor

Monitor可以理解為一個同步工具或一種同步機制，通常被描述為一個物件。每一個Java物件就有一把看不見的鎖，稱為內部鎖或者Monitor鎖。

Monitor是執行緒私有的資料結構，每一個執行緒都有一個可用monitor record列表，同時還有一個全域性的可用列表。每一個被鎖住的物件都會和一個monitor關聯，同時monitor中有一個Owner欄位存放擁有該鎖的執行緒的唯一標識，表示該鎖被這個執行緒佔用。

現在話題回到synchronized，synchronized通過Monitor來實現執行緒同步，Monitor是依賴於底層的作業系統的Mutex Lock（互斥鎖）來實現的執行緒同步。

如同我們在自旋鎖中提到的“阻塞或喚醒一個Java執行緒需要作業系統切換CPU狀態來完成，這種狀態轉換需要耗費處理器時間。如果同步程式碼塊中的內容過於簡單，狀態轉換消耗的時間有可能比使用者程式碼執行的時間還要長”。這種方式就是synchronized最初實現同步的方式，這就是JDK 6之前synchronized效率低的原因。這種依賴於作業系統Mutex Lock所實現的鎖我們稱之為“重量級鎖”，JDK 6中為了減少獲得鎖和釋放鎖帶來的效能消耗，引入了“偏向鎖”和“輕量級鎖”。

所以目前鎖一共有4種狀態，級別從低到高依次是：無鎖、偏向鎖、輕量級鎖和重量級鎖。鎖狀態只能升級不能降級。

通過上面的介紹，我們對synchronized的加鎖機制以及相關知識有了一個瞭解，那麼下面我們給出四種鎖狀態對應的的Mark Word內容，然後再分別講解四種鎖狀態的思路以及特點：

無鎖

無鎖沒有對資源進行鎖定，所有的執行緒都能訪問並修改同一個資源，但同時只有一個執行緒能修改成功。

無鎖的特點就是修改操作在迴圈內進行，執行緒會不斷的嘗試修改共享資源。如果沒有衝突就修改成功並退出，否則就會繼續迴圈嘗試。如果有多個執行緒修改同一個值，必定會有一個執行緒能修改成功，而其他修改失敗的執行緒會不斷重試直到修改成功。上面我們介紹的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操作和自旋來解決加鎖問題，避免執行緒阻塞和喚醒而影響效能。重量級鎖是將除了擁有鎖的執行緒以外的執行緒都阻塞。

4. 公平鎖 VS 非公平鎖

公平鎖是指多個執行緒按照申請鎖的順序來獲取鎖，執行緒直接進入佇列中排隊，佇列中的第一個執行緒才能獲得鎖。公平鎖的優點是等待鎖的執行緒不會餓死。缺點是整體吞吐效率相對非公平鎖要低，等待佇列中除第一個執行緒以外的所有執行緒都會阻塞，CPU喚醒阻塞執行緒的開銷比非公平鎖大。

非公平鎖是多個執行緒加鎖時直接嘗試獲取鎖，獲取不到才會到等待佇列的隊尾等待。但如果此時鎖剛好可用，那麼這個執行緒可以無需阻塞直接獲取到鎖，所以非公平鎖有可能出現後申請鎖的執行緒先獲取鎖的場景。非公平鎖的優點是可以減少喚起執行緒的開銷，整體的吞吐效率高，因為執行緒有機率不阻塞直接獲得鎖，CPU不必喚醒所有執行緒。缺點是處於等待佇列中的執行緒可能會餓死，或者等很久才會獲得鎖。

直接用語言描述可能有點抽象，這裡作者用從別處看到的一個例子來講述一下公平鎖和非公平鎖。

如上圖所示，假設有一口水井，有管理員看守，管理員有一把鎖，只有拿到鎖的人才能夠打水，打完水要把鎖還給管理員。每個過來打水的人都要管理員的允許並拿到鎖之後才能去打水，如果前面有人正在打水，那麼這個想要打水的人就必須排隊。管理員會檢視下一個要去打水的人是不是隊伍裡排最前面的人，如果是的話，才會給你鎖讓你去打水；如果你不是排第一的人，就必須去隊尾排隊，這就是公平鎖。

但是對於非公平鎖，管理員對打水的人沒有要求。即使等待隊伍裡有排隊等待的人，但如果在上一個人剛打完水把鎖還給管理員而且管理員還沒有允許等待隊伍裡下一個人去打水時，剛好來了一個插隊的人，這個插隊的人是可以直接從管理員那裡拿到鎖去打水，不需要排隊，原本排隊等待的人只能繼續等待。如下圖所示：

接下來我們通過ReentrantLock的原始碼來講解公平鎖和非公平鎖。

根據程式碼可知，ReentrantLock裡面有一個內部類Sync，Sync繼承AQS（AbstractQueuedSynchronizer），新增鎖和釋放鎖的大部分操作實際上都是在Sync中實現的。它有公平鎖FairSync和非公平鎖NonfairSync兩個子類。ReentrantLock預設使用非公平鎖，也可以通過構造器來顯示的指定使用公平鎖。

下面我們來看一下公平鎖與非公平鎖的加鎖方法的原始碼:

通過上圖中的原始碼對比，我們可以明顯的看出公平鎖與非公平鎖的lock()方法唯一的區別就在於公平鎖在獲取同步狀態時多了一個限制條件：hasQueuedPredecessors()。

再進入hasQueuedPredecessors()，可以看到該方法主要做一件事情：主要是判斷當前執行緒是否位於同步佇列中的第一個。如果是則返回true，否則返回false。

綜上，公平鎖就是通過同步佇列來實現多個執行緒按照申請鎖的順序來獲取鎖，從而實現公平的特性。非公平鎖加鎖時不考慮排隊等待問題，直接嘗試獲取鎖，所以存在後申請卻先獲得鎖的情況。

5. 可重入鎖 VS 非可重入鎖

可重入鎖又名遞迴鎖，是指在同一個執行緒在外層方法獲取鎖的時候，再進入該執行緒的內層方法會自動獲取鎖（前提鎖物件得是同一個物件或者class），不會因為之前已經獲取過還沒釋放而阻塞。Java中ReentrantLock和synchronized都是可重入鎖，可重入鎖的一個優點是可一定程度避免死鎖。下面用示例程式碼來進行分析：

public class Widget {
    public synchronized void doSomething() {
        System.out.println("方法1執行...");
        doOthers();
    }

    public synchronized void doOthers() {
        System.out.println("方法2執行...");
    }
}複製程式碼

在上面的程式碼中，類中的兩個方法都是被內建鎖synchronized修飾的，doSomething()方法中呼叫doOthers()方法。因為內建鎖是可重入的，所以同一個執行緒在呼叫doOthers()時可以直接獲得當前物件的鎖，進入doOthers()進行操作。

如果是一個不可重入鎖，那麼當前執行緒在呼叫doOthers()之前需要將執行doSomething()時獲取當前物件的鎖釋放掉，實際上該物件鎖已被當前執行緒所持有，且無法釋放。所以此時會出現死鎖。

而為什麼可重入鎖就可以在巢狀呼叫時可以自動獲得鎖呢？我們通過圖示和原始碼來分別解析一下。

還是打水的例子，有多個人在排隊打水，此時管理員允許鎖和同一個人的多個水桶繫結。這個人用多個水桶打水時，第一個水桶和鎖繫結並打完水之後，第二個水桶也可以直接和鎖繫結並開始打水，所有的水桶都打完水之後打水人才會將鎖還給管理員。這個人的所有打水流程都能夠成功執行，後續等待的人也能夠打到水。這就是可重入鎖。

但如果是非可重入鎖的話，此時管理員只允許鎖和同一個人的一個水桶繫結。第一個水桶和鎖繫結打完水之後並不會釋放鎖，導致第二個水桶不能和鎖繫結也無法打水。當前執行緒出現死鎖，整個等待佇列中的所有執行緒都無法被喚醒。

之前我們說過ReentrantLock和synchronized都是重入鎖，那麼我們通過重入鎖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，將鎖釋放。

6. 獨享鎖 VS 共享鎖

獨享鎖和共享鎖同樣是一種概念。我們先介紹一下具體的概念，然後通過ReentrantLock和ReentrantReadWriteLock的原始碼來介紹獨享鎖和共享鎖。

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

共享鎖是指該鎖可被多個執行緒所持有。如果執行緒T對資料A加上共享鎖後，則其他執行緒只能對A再加共享鎖，不能加排它鎖。獲得共享鎖的執行緒只能讀資料，不能修改資料。

獨享鎖與共享鎖也是通過AQS來實現的，通過實現不同的方法，來實現獨享或者共享。

下圖為ReentrantReadWriteLock的部分原始碼：

我們看到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位表示寫鎖狀態（寫鎖個數）。如下圖所示：

瞭解了概念之後我們再來看程式碼，先看寫鎖的加鎖原始碼：

protected final boolean tryAcquire(int acquires) {
    Thread current = Thread.currentThread();
    int c = getState(); // 取到當前鎖的個數
    int w = exclusiveCount(c); // 取寫鎖的個數w
    if (c != 0) { // 如果已經有執行緒持有了鎖(c!=0)
    // (Note: if c != 0 and w == 0 then shared count != 0)
        if (w == 0 || current != getExclusiveOwnerThread()) // 如果寫執行緒數（w）為0（換言之存在讀鎖） 或者持有鎖的執行緒不是當前執行緒就返回失敗
            return false;
        if (w + exclusiveCount(acquires) > MAX_COUNT)    // 如果寫入鎖的數量大於最大數（65535，2的16次方-1）就丟擲一個Error。
      throw new Error("Maximum lock count exceeded");
        // Reentrant acquire
    setState(c + acquires);
    return true;
  }
  if (writerShouldBlock() || !compareAndSetState(c, c + acquires)) // 如果當且寫執行緒數為0，並且當前執行緒需要阻塞那麼就返回失敗；或者如果通過CAS增加寫執行緒數失敗也返回失敗。
        return false;
    setExclusiveOwnerThread(current); // 如果c=0，w=0或者c>0，w>0（重入），則設定當前執行緒或鎖的擁有者
    return true;
}複製程式碼

• 這段程式碼首先取到當前鎖的個數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時表示寫鎖已被釋放，然後等待的讀寫執行緒才能夠繼續訪問讀寫鎖，同時前次寫執行緒的修改對後續的讀寫執行緒可見。

接著是讀鎖的程式碼：

protected final int tryAcquireShared(int unused) {
    Thread current = Thread.currentThread();
    int c = getState();
    if (exclusiveCount(c) != 0 &&
        getExclusiveOwnerThread() != current)
        return -1;                                   // 如果其他執行緒已經獲取了寫鎖，則當前執行緒獲取讀鎖失敗，進入等待狀態
    int r = sharedCount(c);
    if (!readerShouldBlock() &&
        r < MAX_COUNT &&
        compareAndSetState(c, c + SHARED_UNIT)) {
        if (r == 0) {
            firstReader = current;
            firstReaderHoldCount = 1;
        } else if (firstReader == current) {
            firstReaderHoldCount++;
        } else {
            HoldCounter rh = cachedHoldCounter;
            if (rh == null || rh.tid != getThreadId(current))
                cachedHoldCounter = rh = readHolds.get();
            else if (rh.count == 0)
                readHolds.set(rh);
            rh.count++;
        }
        return 1;
    }
    return fullTryAcquireShared(current);
}複製程式碼

可以看到在tryAcquireShared(int unused)方法中，如果其他執行緒已經獲取了寫鎖，則當前執行緒獲取讀鎖失敗，進入等待狀態。如果當前執行緒獲取了寫鎖或者寫鎖未被獲取，則當前執行緒（執行緒安全，依靠CAS保證）增加讀狀態，成功獲取讀鎖。讀鎖的每次釋放（執行緒安全的，可能有多個讀執行緒同時釋放讀鎖）均減少讀狀態，減少的值是“1<<16”。所以讀寫鎖才能實現讀讀的過程共享，而讀寫、寫讀、寫寫的過程互斥。

此時，我們再回頭看一下互斥鎖ReentrantLock中公平鎖和非公平鎖的加鎖原始碼：

我們發現在ReentrantLock雖然有公平鎖和非公平鎖兩種，但是它們新增的都是獨享鎖。根據原始碼所示，當某一個執行緒呼叫lock方法獲取鎖時，如果同步資源沒有被其他執行緒鎖住，那麼當前執行緒在使用CAS更新state成功後就會成功搶佔該資源。而如果公共資源被佔用且不是被當前執行緒佔用，那麼就會加鎖失敗。所以可以確定ReentrantLock無論讀操作還是寫操作，新增的鎖都是都是獨享鎖。

參考資料

1.《Java併發程式設計藝術》
2.Java中的鎖
3.Java CAS 原理剖析
4.Java併發——關鍵字synchronized解析
5.Java synchronized原理總結
6.聊聊併發（二）——Java SE1.6中的Synchronized
7.深入理解讀寫鎖—ReadWriteLock原始碼分析
8.【JUC】JDK1.8原始碼分析之ReentrantReadWriteLock
9.Java多執行緒（十）之ReentrantReadWriteLock深入分析
10.Java--讀寫鎖的實現原理

轉：https://segmentfault.com/a/1190000017037430