輕松掌握java讀寫鎖(ReentrantReadWriteLock)的實現原理


公平讀寫鎖

ReentrantReadWriteLock的鎖策略有兩種,分為公平策略和非公平策略,兩者有些小區別,為便於理解,

本小節將以示例的形式來說明多線程下,使用公平策略的讀寫鎖是如何處理的。

首先看一下即將出場的伙伴們,我們一共會出場幾個線程,還有用於實現讀寫機制的AQS同步器隊列。

每個線程中的 R(0)W(0)表示當前線程占用了多少讀寫鎖。

接下來,我們一步步來看在公平策略下多線程並發的讀寫機制是怎樣的。

1.線程A請求一個讀鎖,此時無人競爭鎖,A獲取讀鎖1,即線程A重入次數為1,如下所示:

2.線程B請求一個讀鎖,由於AQS中沒有等待節點,當前處於讀鎖占有狀態(線程A占有1個讀鎖),所以B成功獲取讀鎖,如下所示:

3.這時候,線程C請求一個寫鎖,由於當前其他兩個線程擁有讀鎖,寫鎖獲取失敗,線程C入隊列,如下所示:

AQS初始化會創建一個空的頭節點,C入隊列,然后會休眠,等待其他線程釋放鎖喚醒。

4.線程D也來了,線程D想獲取一個讀鎖,雖然當於處於讀鎖占有階段,但是目前D不占有任何數量的讀鎖,

而且同步器隊列中已經有等待節點,這時候,由於公平策略,D不得已,一個字,等,如下圖所示:

5.這時候,線程A執行完了,釋放了讀鎖,由於B仍然占有讀鎖,所以釋放后讀鎖仍然沒有完全釋放,寫鎖仍然沒有機會執行,如下圖所示:

6.這次,B也執行完了,執行完后,讀鎖全部釋放,這時候會喚醒排在同步器隊頭的節點C,C成功獲取一個寫鎖,如下圖所示:

7.一旦任何一個線程獲取了寫鎖,除了該線程自己,其它線程都將無法獲取讀鎖和寫鎖,這時候,線程C再次請求一個讀鎖,這是允許的,

但反過來如果一個線程先獲取了讀鎖,再獲取寫法則是不行的。這時候的狀態如下圖所示:

8.這時候假設線程E也來了,E想獲取讀鎖,由於當前處於寫鎖狀態,直接入隊,如下所示:

9.這會C終於把活干完了,把讀鎖和寫鎖都給釋放了,然后線程D被喚醒,獲取了讀鎖,如下圖所示:

10.這時候,如果再來一個線程,比如A,也想獲取讀鎖,由於節點中還有線程E在等待,而且當前線程A沒有獲取任何讀鎖,不是重入狀態,所以只能置入隊尾,如下圖所示:

11.這時候,如果D再次調用了一次獲取讀鎖,由於D屬於可重入狀態,所以直接把讀鎖+1即可,如下圖所示:

12.由於D獲取的是讀鎖,同步隊列中的E等待的也是讀鎖,所以E會被喚醒,獲取讀鎖繼續執行,如下圖所示:

13.同樣的,由於線程A獲取的是讀鎖,在E執行后,會喚醒線程A,A也可以獲得讀鎖,並繼續執行,如下圖所示:

14.最后大家各自執行,悄然退場。

非公平讀寫鎖

接下來我們再來看一下非公平策略讀寫鎖機制又是如何的,為了更好的對比,我們沿用公平鎖的流程。

由於獲取讀鎖的邏輯比較復雜,我們在這里先簡單進行歸納:

a. 如果當前全局處於無鎖狀態,則當前線程獲取讀鎖

b. 如果當前全局處於讀鎖狀態,且隊列中沒有等待線程,則當前線程獲取讀鎖

c. 如果當前全局處於寫鎖占用狀態(並且不是當前線程占有),則當前線程入隊尾

d. 如果當前全局處於讀鎖狀態,且等待隊列中第一個等待線程想獲取寫鎖,那么當前線程能夠獲取到讀鎖的條件為:當前線程獲取了寫鎖,還未釋放;當前線程獲取了讀鎖,這一次只是重入讀鎖而已;其它情況當前線程入隊尾。之所以這樣處理一方面是為了效率,一方面是為了避免想獲取寫鎖的線程飢餓,老是得不到執行的機會

e. 如果當前全局處於讀鎖狀態,且等待隊列中第一個等待線程不是寫鎖,則當前線程可以搶占讀鎖

獲取寫鎖相對就比較簡單了,規則如下:

h. 如果當前處於無鎖狀態,則當前線程獲取寫鎖

i. 如果當前全局處於讀鎖狀態,當前線程入隊尾

j. 如果當前全局處於寫鎖狀態,除非是重入獲取寫鎖,否則入隊尾

接下來我們看一遍流程:

1.線程A請求一個讀鎖,全局處於無鎖狀態,根據規則a,線程A獲取了鎖,如下圖所示:

2.線程B請求一個讀鎖,根據規則b,線程B可以獲取到讀鎖

3.這時候,線程C請求一個寫鎖,由於當前其他兩個線程擁有讀鎖,寫鎖獲取失敗,線程C入隊列(根據規則i),如下所示:

AQS初始化會創建一個空的頭節點,C入隊列,然后會休眠,等待其他線程釋放鎖喚醒。

4.線程D也來了,線程D想獲取一個讀鎖,根據讀鎖規則d,隊列中第一個等待線程C請求的是寫鎖,為避免寫鎖遲遲獲取不到,並且線程D不是重入獲取讀鎖,所以線程D也入隊,如下圖所示:

5.這時候,線程A執行完了,釋放了讀鎖,由於B仍然占有讀鎖,所以釋放后讀鎖仍然沒有完全釋放,寫鎖仍然沒有機會執行,如下圖所示:

6.這次,B也執行完了,執行完后,讀鎖全部釋放,這時候會喚醒排在同步器隊頭的節點C,C成功獲取一個寫鎖,如下圖所示:

7.一旦任何一個線程獲取了寫鎖,除了該線程自己,其它線程都將無法獲取讀鎖和寫鎖,這時候,線程C再次請求一個讀鎖,這是允許的,

但反過來如果一個線程先獲取了讀鎖,再獲取寫鎖則是不行的。這時候的狀態如下圖所示:

 

8.這時候假設線程E也來了,E想獲取讀鎖,由於當前處於寫鎖狀態,直接入隊,如下所示:

9.這會C終於把活干完了,把讀鎖和寫鎖都給釋放了,然后線程D被喚醒,獲取了讀鎖,如下圖所示:

10.這時候,如果再來一個線程,比如A,也想獲取讀鎖,雖然等待隊列中,E線程剛好還沒被喚醒,

但A線程是可以搶占讀鎖的(這里假設搶占到了),這個跟公平鎖有明顯的區別,如下圖所示:

11.這時候,如果D再次調用了一次獲取讀鎖,由於D屬於可重入狀態,所以直接把讀鎖+1即可,如下圖所示:

12.由於當前狀態下處於讀鎖狀態,前面的線程D其實醒來后,是會同時喚醒線程E的,所以線程E也醒過來繼續干活了,如下圖所示:

13.同步隊列中沒有等待線程了,各個線程執行完后,一切相安無事了。

總結

考慮到業務的多樣化,java5中提供的並發包中的工具類大部分都同時提供了公平及非公平策略,這兩種策略下,一般而言,非公平鎖吞吐會比較大,所以默認情況下都是使用的非公平策略。

本篇試圖以盡量簡單的方式來闡明讀寫鎖的實現機制,為了直觀,我們只考慮簡單抽象的方式,實際在實現的時候,會使用CAS去競爭鎖。特別是在非公平策略中的第10個步驟,這種情況下有可能E先獲取了讀鎖。很多時候,我們在大致了解了實現步驟,流程之后,再去品味源碼,就會更加的輕松。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM