33張圖剖析ReentrantReadWriteLock源碼

程序猿阿星 2021-08-15 12:21:33 阅读数:879

本文一共[544]字,预计阅读时长:1分钟~
剖析 reentrantreadwritelock

大家好,我是阿星,今天是一篇硬核文,請各比特讀者大大們系好安全帶,馬上要發車了。

圖片

暈車的朋友,可以先吃一顆阿星獨家秘制的暈車藥,童叟無欺,貨真價實,還免費,白嫖黨狂喜(16張圖揭開AQS)。

本文大綱如下

圖片

縱觀全局

我的英文名叫ReentrantReadWriteLock(後面簡稱RRW),大家喜歡叫我讀寫鎖,因為我常年混迹在讀多寫少的場景。

讀寫鎖規範

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

所以聲明了ReadWriteLock接口,作為讀寫鎖的基本規範。

圖片

之後都是圍繞著規範去實現讀鎖與寫鎖。

讀鎖與寫鎖

WriteLock與ReadLock就是讀鎖和寫鎖,它們是RRW實現ReadWriteLock接口的產物。

但讀鎖、寫鎖也要遵守鎖操作的基本規範。

所以WriteLock與ReadLock都實現了Lock接口。

圖片

那麼WriteLock與ReadLock對Lock接口具體是如何實現的呢?

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

AQS

眾所周知,要實現鎖的基本操作,必須要仰仗AQS老大哥了。

AQS(AbstractQueuedSynchronizer)抽象類定義了一套多線程訪問共享資源的同步模板,解决了實現同步器時涉及的大量細節問題,能够極大地减少實現工作,用大白話來說,AQS為加鎖和解鎖過程提供了統一的模板函數,只有少量細節由子類自己决定。

AQS簡化流程圖如下

圖片

如果讀者想深入AQS細節,可以看阿星的這篇文章:16張圖揭開AQS

Sync

AQS為加鎖和解鎖過程提供了統一的模板函數,只有少量細節由子類自己决定,但是WriteLock與ReadLock沒有直接去繼承AQS

因為WriteLock與ReadLock覺得,自己還要去繼承AQS實現一些兩者可以公用的抽象函數,不僅麻煩,還有重複勞動。

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

Sync繼承AQS實現了如下的核心抽象函數

  • tryAcquire
  • release
  • tryAcquireShared
  • tryReleaseShared
圖片

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

tryAcquireShared、tryReleaseShared是為ReadLock讀鎖准備的,這裏阿星後面會說。

上面說了Sync實現了一些AQS的核心抽象函數,但是Sync本身也有一些重要的內容,看看下面這段代碼

圖片

我們都知道AQS中維護了一個state狀態變量,正常來說,維護讀鎖與寫鎖狀態需要兩個變量,但是為了節約資源,使用高低比特切割實現state狀態變量維護兩種狀態,即高16比特錶示讀狀態,低16比特錶示寫狀態。

關於讀寫鎖狀態設計具體細節可以看阿星的文章:ReentrantReadWriteLock的比特運算

Sync中還定義了HoldCounter與ThreadLocalHoldCounter

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

圖片


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

公平與非公平策略

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

什麼是公平與非公平策略?

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

圖片

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

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

圖片

回到正題,為了支持公平與非公平策略,Sync擴展了FairSync、NonfairSync子類,兩個子類實現了readerShouldBlock、writerShouldBlock函數,即讀鎖與寫鎖是否阻塞

圖片

readerShouldBlock、writerShouldBlock函數在什麼地方使用阿星後面會說。

ReentrantReadWriteLock全局圖

最後阿星把前面講過的內容,全部組裝起來,構成下面這張圖。

圖片

有了全局觀後,後面就可以深入細節逐個擊破了。

深入細節

後面我們只要攻破5個細節就够了,分別是讀寫鎖的創建、獲取寫鎖、釋放寫鎖、獲取讀鎖、釋放讀鎖。

ReentrantReadWriteLock的創建

讀寫鎖的創建,會初始化化一系列類,代碼如下

圖片

ReentrantReadWriteLock默認是非公平策略,如果想用公平策略,可以直接調用有參構造器,傳入true即可。

但不管是創建FairSync還是NonfairSync,都會觸發Sync的無參構造器,因為Sync是它們的父類(本質上它們倆都是Sync)。

圖片

因為Sync需要提供給ReadLock與WriteLock使用,所以創建ReadLock與WriteLock時,會接收ReentrantReadWriteLock對象作為入參。

圖片

最後通過ReentrantReadWriteLock.syncSync交給了ReadLock與WriteLock。

獲取寫鎖

我們遵守ReadWriteLock接口規範,調用ReentrantReadWriteLock.writeLock函數獲取寫鎖對象。

圖片

獲取到寫鎖對象後,遵守Lock接口規範,調用lock函數獲取寫鎖。

WriteLock.lock函數是由Sync實現的(FairSync或NonfairSync)。

圖片

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

圖片

WriteLock.lock調用鏈如下圖

圖片

我們只關注tryAcquire函數,其他函數是AQS的獲取獨占式鎖失敗後的流程內容,不屬於本文範疇,tryAcquire函數代碼如下

圖片

為了易於理解,阿星把它轉成流程圖

圖片

通過流程圖,我們發現了一些要點

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

釋放寫鎖

獲取到寫鎖,臨界區執行完,要記得釋放寫鎖(如果重入多次要釋放對應的次數),不然會阻塞其他線程的讀寫操作,調用unlock函數釋放寫鎖(Lock接口規範)。

WriteLock.unlock函數也是由Sync實現的(FairSync或NonfairSync)。

圖片

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

圖片

WriteLock.unlock調用鏈如下圖

圖片

再來看看tryRelease函數,其他函數是AQS的釋放獨占式成功後的流程內容,不屬於本文範疇,tryRelease函數代碼如下

圖片

為了易於理解,阿星把它轉成流程圖

圖片

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

獲取讀鎖

我們遵守ReadWriteLock接口規範,調用ReentrantReadWriteLock.readLock函數獲取讀鎖對象。

圖片

獲取到讀鎖對象後,遵守Lock接口規範,調用lock函數獲取讀鎖。

ReadLock.lock函數是由Sync實現的(FairSync或NonfairSync)。

圖片

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

圖片

ReadLock.lock調用鏈如下圖

圖片

我們只關注tryAcquireShared函數,doAcquireShared函數是AQS的獲取共享式鎖失敗後的流程內容,不屬於本文範疇,tryAcquireShared函數代碼如下

圖片

代碼還挺多的,為了易於理解,阿星把它轉成流程圖

圖片

通過流程圖,我們發現了一些要點

  • 讀鎖共享,讀讀不互斥
  • 讀鎖可重入,每個獲取讀鎖的線程都會記錄對應的重入數
  • 讀寫互斥,鎖降級場景除外
  • 支持鎖降級,持有寫鎖的線程,可以獲取讀鎖,但是後續要記得把讀鎖和寫鎖讀釋放
  • readerShouldBlock讀鎖是否阻塞實現取决公平與非公平的策略(FairSync和NonfairSync)

釋放讀鎖

獲取到讀鎖,執行完臨界區後,要記得釋放讀鎖(如果重入多次要釋放對應的次數),不然會阻塞其他線程的寫操作,通過調用unlock函數釋放讀鎖(Lock接口規範)。

ReadLock.unlock函數也是由Sync實現的(FairSync或NonfairSync)。

圖片

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

圖片

ReadLock.unlock調用鏈如下圖

圖片

我們只關注tryReleaseShared函數,doReleaseShared函數是AQS的釋放共享式鎖成功後的流程內容,不屬於本文範疇,tryReleaseShared函數代碼如下

圖片

為了易於理解,阿星把它轉成流程圖

圖片

這裏有三點需要注意

  • 第一點:線程讀鎖的重入數與讀鎖數量是兩個概念,線程讀鎖的重入數是每個線程獲取同一個讀鎖的次數,讀鎖數量則是所有線程的讀鎖重入數總和。

  • 第二點:AQS的共享式釋放鎖流程模板中,只有全部的讀鎖被釋放了,才會去執行doReleaseShared函數

  • 第三點:因為使用的是AQS共享式流程模板,如果CLH隊列後面的線程節點都是因寫鎖阻塞的讀鎖線程節點,會傳播喚醒

小結

最後阿星做個小結,ReentrantReadWriteLock底層實現與ReentrantLock思路一致,它們都離不開AQS,都是聲明一個繼承AQSSync,並在Sync下擴展公平與非公平策略,後續的鎖相關操作都委托給公平與非公平策略執行。

我們還發現,在AQS中除了獨占式模板,還有共享式模板,它們在多線程訪問共享資源的流程會有所差异,就如ReentrantReadWriteLock中讀鎖使用共享式,寫鎖使用獨占式。

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

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

曆史好文推薦

關於我

阿星是一個熱愛技術的Java程序猿,公眾號  「程序猿阿星」 定期分享有趣有料的精品原創文章!

圖片

非常感謝各比特小哥哥小姐姐們能看到這裏,原創不易,文章有幫助可以關注、點個贊、分享與評論,都是支持(莫要白嫖)!

願你我都能奔赴在各自想去的路上,我們下篇文章見。

程序猿阿星
程序猿阿星
一起成長進階!專注技術原理、源碼,通過圖解方式輸出技術,這裏將會分享操作系統、計算機網絡、Java、分布式、數據庫等精品原創文章
24篇原創內容
公眾號


版权声明:本文为[程序猿阿星]所创,转载请带上原文链接,感谢。 https://gsmany.com/2021/08/20210815122111037Y.html