本文大綱如下

縱觀全局

我的英文名叫ReentrantReadWriteLock（后面簡稱RRW），大家喜歡叫我讀寫鎖，因為我常年混跡在讀多寫少的場景。

讀寫鎖規(guī)范

作為合格的讀寫鎖，先要有讀鎖與寫鎖才行。

所以聲明了ReadWriteLock接口，作為讀寫鎖的基本規(guī)范。

之后都是圍繞著規(guī)范去實現(xiàn)讀鎖與寫鎖。

讀鎖與寫鎖

WriteLock與ReadLock就是讀鎖和寫鎖，它們是RRW實現(xiàn)ReadWriteLock接口的產(chǎn)物。

但讀鎖、寫鎖也要遵守鎖操作的基本規(guī)范。

所以WriteLock與ReadLock都實現(xiàn)了Lock接口。

那么WriteLock與ReadLock對Lock接口具體是如何實現(xiàn)的呢？

自然是少不了我們的老朋友AQS了。

AQS

眾所周知，要實現(xiàn)鎖的基本操作，必須要仰仗AQS老大哥了。

AQS（AbstractQueuedSynchronizer）抽象類定義了一套多線程訪問共享資源的同步模板，解決了實現(xiàn)同步器時涉及的大量細節(jié)問題，能夠極大地減少實現(xiàn)工作，用大白話來說，AQS為加鎖和解鎖過程提供了統(tǒng)一的模板函數(shù)，只有少量細節(jié)由子類自己決定。

AQS簡化流程圖如下

如果讀者想深入AQS細節(jié)，可以看阿星的這篇文章：16張圖揭開AQS

Sync

AQS為加鎖和解鎖過程提供了統(tǒng)一的模板函數(shù)，只有少量細節(jié)由子類自己決定，但是WriteLock與ReadLock沒有直接去繼承AQS。

因為WriteLock與ReadLock覺得，自己還要去繼承AQS實現(xiàn)一些兩者可以公用的抽象函數(shù)，不僅麻煩，還有重復勞動。

所以干脆單獨提供一個對鎖操作的類，由WriteLock與ReadLock持有使用，這個類叫Sync。

Sync繼承AQS實現(xiàn)了如下的核心抽象函數(shù)

• tryAcquire
• release
• tryAcquireShared
• tryReleaseShared

其中tryAcquire、release是為WriteLock寫鎖準備的。

tryAcquireShared、tryReleaseShared是為ReadLock讀鎖準備的，這里阿星后面會說。

上面說了Sync實現(xiàn)了一些AQS的核心抽象函數(shù)，但是Sync本身也有一些重要的內(nèi)容，看看下面這段代碼

我們都知道AQS中維護了一個state狀態(tài)變量，正常來說，維護讀鎖與寫鎖狀態(tài)需要兩個變量，但是為了節(jié)約資源，使用高低位切割實現(xiàn)state狀態(tài)變量維護兩種狀態(tài)，即高16位表示讀狀態(tài)，低16位表示寫狀態(tài)。

關(guān)于讀寫鎖狀態(tài)設(shè)計具體細節(jié)可以看阿星的文章：ReentrantReadWriteLock的位運算

Sync中還定義了HoldCounter與ThreadLocalHoldCounter

• HoldCounter是用來記錄讀鎖重入數(shù)的對象
• ThreadLocalHoldCounter是ThreadLocal變量，用來存放第一個獲取讀鎖線程外的其他線程的讀鎖重入數(shù)對象

如果讀者對ThreadLocal不太熟悉，可以去看阿星的文章: 保姆級教學，22張圖揭開ThreadLocal

公平與非公平策略

你看，人家ReentrantLock都有公平與非公平策略，所以ReentrantReadWriteLock也要有。

什么是公平與非公平策略？

因為在AQS流程中，獲取鎖失敗的線程，會被構(gòu)建成節(jié)點入隊到CLH隊列，其他線程釋放鎖會喚醒CLH隊列的線程重新競爭鎖，如下圖所示（簡化流程）。

非公平策略是指，非CLH隊列的線程與CLH隊列的線程競爭鎖，大家各憑本事，不會因為你是CLH隊列的線程，排了很久的隊，就把鎖讓給你。

公平策略是指，嚴格按照CLH隊列順序獲取鎖，一定會讓CLH隊列線程競爭成功，如果非CLH隊列線程一直占用時間片，那就一直失敗，直到時間片輪到CLH隊列線程為止，所以公平策略的性能會更差。

回到正題，為了支持公平與非公平策略，Sync擴展了FairSync、NonfairSync子類，兩個子類實現(xiàn)了readerShouldBlock、writerShouldBlock函數(shù)，即讀鎖與寫鎖是否阻塞。

readerShouldBlock、writerShouldBlock函數(shù)在什么地方使用阿星后面會說。

ReentrantReadWriteLock全局圖

最后阿星把前面講過的內(nèi)容，全部組裝起來，構(gòu)成下面這張圖。

有了全局觀后，后面就可以深入細節(jié)逐個擊破了。

深入細節(jié)

后面我們只要攻破5個細節(jié)就夠了，分別是讀寫鎖的創(chuàng)建、獲取寫鎖、釋放寫鎖、獲取讀鎖、釋放讀鎖。

ReentrantReadWriteLock的創(chuàng)建

讀寫鎖的創(chuàng)建，會初始化化一系列類，代碼如下

ReentrantReadWriteLock默認是非公平策略，如果想用公平策略，可以直接調(diào)用有參構(gòu)造器，傳入true即可。

但不管是創(chuàng)建FairSync還是NonfairSync，都會觸發(fā)Sync的無參構(gòu)造器，因為Sync是它們的父類（本質(zhì)上它們倆都是Sync）。

因為Sync需要提供給ReadLock與WriteLock使用，所以創(chuàng)建ReadLock與WriteLock時，會接收ReentrantReadWriteLock對象作為入?yún)ⅰ?/p>

最后通過ReentrantReadWriteLock.sync把Sync交給了ReadLock與WriteLock。

獲取寫鎖

我們遵守ReadWriteLock接口規(guī)范，調(diào)用ReentrantReadWriteLock.writeLock函數(shù)獲取寫鎖對象。

獲取到寫鎖對象后，遵守Lock接口規(guī)范，調(diào)用lock函數(shù)獲取寫鎖。

WriteLock.lock函數(shù)是由Sync實現(xiàn)的（FairSync或NonfairSync）。

sync.acquire(1)函數(shù)是AQS中的獨占式獲取鎖流程模板（Sync繼承自AQS）。

WriteLock.lock調(diào)用鏈如下圖

我們只關(guān)注tryAcquire函數(shù)，其他函數(shù)是AQS的獲取獨占式鎖失敗后的流程內(nèi)容，不屬于本文范疇，tryAcquire函數(shù)代碼如下

為了易于理解，阿星把它轉(zhuǎn)成流程圖

通過流程圖，我們發(fā)現(xiàn)了一些要點

• 讀寫互斥
• 寫寫互斥
• 寫鎖支持同一個線程重入
• writerShouldBlock寫鎖是否阻塞實現(xiàn)取決公平與非公平的策略（FairSync和NonfairSync）

釋放寫鎖

獲取到寫鎖，臨界區(qū)執(zhí)行完，要記得釋放寫鎖（如果重入多次要釋放對應(yīng)的次數(shù)），不然會阻塞其他線程的讀寫操作，調(diào)用unlock函數(shù)釋放寫鎖（Lock接口規(guī)范）。

WriteLock.unlock函數(shù)也是由Sync實現(xiàn)的（FairSync或NonfairSync）。

sync.release(1)執(zhí)行的是AQS中的獨占式釋放鎖流程模板（Sync繼承自AQS）。

WriteLock.unlock調(diào)用鏈如下圖

再來看看tryRelease函數(shù)，其他函數(shù)是AQS的釋放獨占式成功后的流程內(nèi)容，不屬于本文范疇，tryRelease函數(shù)代碼如下

為了易于理解，阿星把它轉(zhuǎn)成流程圖

因為同一個線程可以對相同的寫鎖重入多次，所以也要釋放的相同的次數(shù)。

獲取讀鎖

我們遵守ReadWriteLock接口規(guī)范，調(diào)用ReentrantReadWriteLock.readLock函數(shù)獲取讀鎖對象。

獲取到讀鎖對象后，遵守Lock接口規(guī)范，調(diào)用lock函數(shù)獲取讀鎖。

ReadLock.lock函數(shù)是由Sync實現(xiàn)的（FairSync或NonfairSync）。

sync.acquireShared(1)函數(shù)執(zhí)行的是AQS中的共享式獲取鎖流程模板（Sync繼承自AQS）。

ReadLock.lock調(diào)用鏈如下圖

我們只關(guān)注tryAcquireShared函數(shù)，doAcquireShared函數(shù)是AQS的獲取共享式鎖失敗后的流程內(nèi)容，不屬于本文范疇，tryAcquireShared函數(shù)代碼如下

代碼還挺多的，為了易于理解，阿星把它轉(zhuǎn)成流程圖

通過流程圖，我們發(fā)現(xiàn)了一些要點

• 讀鎖共享，讀讀不互斥
• 讀鎖可重入，每個獲取讀鎖的線程都會記錄對應(yīng)的重入數(shù)
• 讀寫互斥，鎖降級場景除外
• 支持鎖降級，持有寫鎖的線程，可以獲取讀鎖，但是后續(xù)要記得把讀鎖和寫鎖讀釋放
• readerShouldBlock讀鎖是否阻塞實現(xiàn)取決公平與非公平的策略（FairSync和NonfairSync）

釋放讀鎖

獲取到讀鎖，執(zhí)行完臨界區(qū)后，要記得釋放讀鎖（如果重入多次要釋放對應(yīng)的次數(shù)），不然會阻塞其他線程的寫操作，通過調(diào)用unlock函數(shù)釋放讀鎖（Lock接口規(guī)范）。

ReadLock.unlock函數(shù)也是由Sync實現(xiàn)的（FairSync或NonfairSync）。

sync.releaseShared(1)函數(shù)執(zhí)行的是AQS中的共享式釋放鎖流程模板（Sync繼承自AQS）。

ReadLock.unlock調(diào)用鏈如下圖

我們只關(guān)注tryReleaseShared函數(shù)，doReleaseShared函數(shù)是AQS的釋放共享式鎖成功后的流程內(nèi)容，不屬于本文范疇，tryReleaseShared函數(shù)代碼如下

為了易于理解，阿星把它轉(zhuǎn)成流程圖

這里有三點需要注意

• 第一點：線程讀鎖的重入數(shù)與讀鎖數(shù)量是兩個概念，線程讀鎖的重入數(shù)是每個線程獲取同一個讀鎖的次數(shù)，讀鎖數(shù)量則是所有線程的讀鎖重入數(shù)總和。

• 第二點：AQS的共享式釋放鎖流程模板中，只有全部的讀鎖被釋放了，才會去執(zhí)行doReleaseShared函數(shù)

• 第三點：因為使用的是AQS共享式流程模板，如果CLH隊列后面的線程節(jié)點都是因?qū)戞i阻塞的讀鎖線程節(jié)點，會傳播喚醒

小結(jié)

最后阿星做個小結(jié)，ReentrantReadWriteLock底層實現(xiàn)與ReentrantLock思路一致，它們都離不開AQS，都是聲明一個繼承AQS的Sync，并在Sync下擴展公平與非公平策略，后續(xù)的鎖相關(guān)操作都委托給公平與非公平策略執(zhí)行。

我們還發(fā)現(xiàn)，在AQS中除了獨占式模板，還有共享式模板，它們在多線程訪問共享資源的流程會有所差異，就如ReentrantReadWriteLock中讀鎖使用共享式，寫鎖使用獨占式。

最后再捋一捋寫鎖與讀鎖的邏輯

1. 讀讀不阻塞
2. 寫鎖阻塞寫之后的讀寫鎖，但是不阻塞寫鎖之前的讀鎖線程
3. 寫鎖會被寫之前的讀寫鎖阻塞
4. 讀鎖節(jié)點喚醒會無條件傳播喚醒CLH隊列后面的讀鎖節(jié)點
5. 寫鎖可以降級為讀鎖，防止更新丟失
6. 讀鎖、寫鎖都支持重入