Java編程進階——Java 讀寫鎖 ReentrantReadWriteLock 源碼分析

本文內容：讀寫鎖 ReentrantReadWriteLock 的源碼分析，基於 Java7/Java8。

閱讀建議：雖然我這裡會介紹一些 AQS 的知識，不過如果你完全不瞭解 AQS，看本文就有點吃力了。

目錄

• 使用示例
• ReentrantReadWriteLock 總覽
• 源碼分析
• 讀鎖獲取
• 讀鎖釋放
• 寫鎖獲取
• 寫鎖釋放
• 鎖降級
• 總結

使用示例

下面這個例子非常實用，我是 javadoc 的搬運工：

1. 
   
2. // 這是一個關於緩存操作的故事
3. class CachedData {
4. Object data;
5. volatile boolean cacheValid;
6. // 讀寫鎖實例
7. final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
9. void processCachedData() {
10. // 獲取讀鎖
11. rwl.readLock().lock();
12. if (!cacheValid) { // 如果緩存過期了，或者為 null
13. // 釋放掉讀鎖，然後獲取寫鎖 (後面會看到，沒釋放掉讀鎖就獲取寫鎖，會發生死鎖情況)
14. rwl.readLock().unlock();
15. rwl.writeLock().lock();
17. try {
18. if (!cacheValid) { // 重新判斷，因為在等待寫鎖的過程中，可能前面有其他寫線程執行過了
19. data = ...
20. cacheValid = true;
21. }
22. // 獲取讀鎖 (持有寫鎖的情況下，是允許獲取讀鎖的，稱為 “鎖降級”，反之不行。)
23. rwl.readLock().lock();
24. } finally {
25. // 釋放寫鎖，此時還剩一個讀鎖
26. rwl.writeLock().unlock(); // Unlock write, still hold read
27. }
28. }
30. try {
31. use(data);
32. } finally {
33. // 釋放讀鎖
34. rwl.readLock().unlock();
35. }
36. }
37. }

ReentrantReadWriteLock 分為讀鎖和寫鎖兩個實例，讀鎖是共享鎖，可被多個線程同時使用，寫鎖是獨佔鎖。持有寫鎖的線程可以繼續獲取讀鎖，反之不行。

ReentrantReadWriteLock 總覽

這一節比較重要，我們要先看清楚 ReentrantReadWriteLock 的大框架，然後再到源碼細節。

首先，我們來看下 ReentrantReadWriteLock 的結構，它有好些嵌套類：

大家先仔細看看這張圖中的信息。然後我們把 ReadLock 和 WriteLock 的代碼提出來一起看，清晰一些：

很清楚了，ReadLock 和 WriteLock 中的方法都是通過 Sync 這個類來實現的。Sync 是 AQS 的子類，然後再派生了公平模式和不公平模式。

從它們調用的 Sync 方法，我們可以看到： ReadLock 使用了共享模式，WriteLock 使用了獨佔模式。

等等，同一個 AQS 實例怎麼可以同時使用共享模式和獨佔模式？？？

這裡給大家回顧下 AQS，我們橫向對比下 AQS 的共享模式和獨佔模式：

AQS 的精髓在於內部的屬性 state：

1. 對於獨佔模式來說，通常就是 0 代表可獲取鎖，1 代表鎖被別人獲取了，重入例外
2. 而共享模式下，每個線程都可以對 state 進行加減操作

也就是說，獨佔模式和共享模式對於 state 的操作完全不一樣，那讀寫鎖 ReentrantReadWriteLock 中是怎麼使用 state 的呢？答案是將 state 這個 32 位的 int 值分為高 16 位和低 16位，分別用於共享模式和獨佔模式。

源碼分析

有了前面的概念，大家心裡應該都有數了吧，下面就不再那麼囉嗦了，直接代碼分析。

源代碼加註釋 1500 行，並不算難，我們要看的代碼量不大。如果你前面一節都理解了，那麼直接從頭開始一行一行往下看就是了，還是比較簡單的。

ReentrantReadWriteLock 的前面幾行很簡單，我們往下滑到 Sync 類，先來看下它的所有的屬性：

1. 
   
2. abstract static class Sync extends AbstractQueuedSynchronizer {
3. // 下面這塊說的就是將 state 一分為二，高 16 位用於共享模式，低16位用於獨佔模式
4. static final int SHARED_SHIFT = 16;
5. static final int SHARED_UNIT = (1 << SHARED_SHIFT);
6. static final int MAX_COUNT = (1 << SHARED_SHIFT) - 1;
7. static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;
8. // 取 c 的高 16 位值，代表讀鎖的獲取次數(包括重入)
9. static int sharedCount(int c) { return c >>> SHARED_SHIFT; }
10. // 取 c 的低 16 位值，代表寫鎖的重入次數，因為寫鎖是獨佔模式
11. static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }
13. // 這個嵌套類的實例用來記錄每個線程持有的讀鎖數量(讀鎖重入)
14. static final class HoldCounter {
15. // 持有的讀鎖數
16. int count = 0;
17. // 線程 id
18. final long tid = getThreadId(Thread.currentThread());
19. }
21. // ThreadLocal 的子類
22. static final class ThreadLocalHoldCounter
23. extends ThreadLocal {
24. public HoldCounter initialValue() {
25. return new HoldCounter();
26. }
27. }
28. /**
29. * 組合使用上面兩個類，用一個 ThreadLocal 來記錄當前線程持有的讀鎖數量
30. */
31. private transient ThreadLocalHoldCounter readHolds;
33. // 用於緩存，記錄"最後一個獲取讀鎖的線程"的讀鎖重入次數，
34. // 所以不管哪個線程獲取到讀鎖後，就把這個值佔為已用，這樣就不用到 ThreadLocal 中查詢 map 了
35. // 算不上理論的依據：通常讀鎖的獲取很快就會伴隨著釋放，
36. // 顯然，在 獲取->釋放 讀鎖這段時間，如果沒有其他線程獲取讀鎖的話，此緩存就能幫助提高性能
37. private transient HoldCounter cachedHoldCounter;
39. // 第一個獲取讀鎖的線程(並且其未釋放讀鎖)，以及它持有的讀鎖數量
40. private transient Thread firstReader = null;
41. private transient int firstReaderHoldCount;
43. Sync() {
44. // 初始化 readHolds 這個 ThreadLocal 屬性
45. readHolds = new ThreadLocalHoldCounter();
46. // 為了保證 readHolds 的內存可見性
47. setState(getState()); // ensures visibility of readHolds
48. }
49. ...
50. }
51. state 的高 16 位代表讀鎖的獲取次數，包括重入次數，獲取到讀鎖一次加 1，釋放掉讀鎖一次減 1
52. state 的低 16 位代表寫鎖的獲取次數，因為寫鎖是獨佔鎖，同時只能被一個線程獲得，所以它代表重入次數
53. 每個線程都需要維護自己的 HoldCounter，記錄該線程獲取的讀鎖次數，這樣才能知道到底是不是讀鎖重入，用 ThreadLocal 屬性
    readHolds 維護
54. cachedHoldCounter 有什麼用？其實沒什麼用，但能提示性能。將最後一次獲取讀鎖的線程的 HoldCounter 緩存到這裡，這樣比使用 ThreadLocal 性能要好一些，因為 ThreadLocal 內部是基於 map 來查詢的。但是 cachedHoldCounter 這一個屬性畢竟只能緩存一個線程，所以它要起提升性能作用的依據就是：通常讀鎖的獲取緊隨著就是該讀鎖的釋放。我這裡可能表達不太好，但是大家應該是懂的吧。
55. firstReader 和 firstReaderHoldCount 有什麼用？其實也沒什麼用，但是它也能提示性能。將"第一個"獲取讀鎖的線程記錄在 firstReader 屬性中，這裡的第一個不是全局的概念，等這個 firstReader 當前代表的線程釋放掉讀鎖以後，會有後來的線程佔用這個屬性的。firstReader 和 firstReaderHoldCount 使得在讀鎖不產生競爭的情況下，記錄讀鎖重入次數非常方便快速
56. 如果一個線程使用了 firstReader，那麼它就不需要佔用 cachedHoldCounter
57. 個人認為，讀寫鎖源碼中最讓初學者頭疼的就是這幾個用於提升性能的屬性了，使得大家看得雲裡霧裡的。主要是因為 ThreadLocal 內部是通過一個 ThreadLocalMap 來操作的，會增加檢索時間。而很多場景下，執行 unlock 的線程往往就是剛剛最後一次執行 lock 的線程，中間可能沒有其他線程進行 lock。還有就是很多不怎麼會發生讀鎖競爭的場景。

上面說了這麼多，是希望能幫大家降低後面閱讀源碼的壓力，大家也可以先看看後面的，然後再慢慢體會。

前面我們好像都只說讀鎖，完全沒提到寫鎖，主要是因為寫鎖真的是簡單很多，我也特地將寫鎖的源碼放到了後面，我們先啃下最難的讀鎖先。

讀鎖獲取

下面我就不一行一行按源碼順序說了，我們按照使用來說。

我們來看下讀鎖 ReadLock 的 lock 流程：

1. 
   
2. // ReadLock
3. public void lock() {
4. sync.acquireShared(1);
5. }
6. // AQS
7. public final void acquireShared(int arg) {
8. if (tryAcquireShared(arg) < 0)
9. doAcquireShared(arg);
10. }

然後我們就會進到 Sync 類的 tryAcquireShared 方法：

在 AQS 中，如果 tryAcquireShared(arg) 方法返回值小於 0 代表沒有獲取到共享鎖(讀鎖)，大於 0 代表獲取到

回顧 AQS 共享模式：tryAcquireShared 方法不僅僅在 acquireShared 的最開始被使用，這裡是 try，也就可能會失敗，如果失敗的話，執行後面的 doAcquireShared，進入到阻塞隊列，然後等待前驅節點喚醒。喚醒以後，還是會調用 tryAcquireShared 進行獲取共享鎖的。當然，喚醒以後再 try 是很容易獲得鎖的，因為這個節點已經排了很久的隊了，組織是會照顧它的。

所以，你在看下面這段代碼的時候，要想象到兩種獲取讀鎖的場景，一種是新來的，一種是排隊排到它的。

1. 
   
2. protected final int tryAcquireShared(int unused) {
4. Thread current = Thread.currentThread();
5. int c = getState();
7. // exclusiveCount(c) 不等於 0，說明有線程持有寫鎖，
8. // 而且不是當前線程持有寫鎖，那麼當前線程獲取讀鎖失敗
9. // （另，如果持有寫鎖的是當前線程，是可以繼續獲取讀鎖的）
10. if (exclusiveCount(c) != 0 &&
11. getExclusiveOwnerThread() != current)
12. return -1;
14. // 讀鎖的獲取次數
15. int r = sharedCount(c);
17. // 讀鎖獲取是否需要被阻塞，稍後細說。為了進去下面的分支，假設這裡不阻塞就好了
18. if (!readerShouldBlock() &&
19. // 判斷是否會溢出 (2^16-1，沒那麼容易溢出的)
20. r < MAX_COUNT &&
21. // 下面這行 CAS 是將 state 屬性的高 16 位加 1，低 16 位不變，如果成功就代表獲取到了讀鎖
22. compareAndSetState(c, c + SHARED_UNIT)) {
24. // =======================
25. // 進到這裡就是獲取到了讀鎖
26. // =======================
28. if (r == 0) {
29. // r == 0 說明此線程是第一個獲取讀鎖的，或者說在它前面獲取讀鎖的都走光光了，它也算是第一個吧
30. // 記錄 firstReader 為當前線程，及其持有的讀鎖數量：1
31. firstReader = current;
32. firstReaderHoldCount = 1;
33. } else if (firstReader == current) {
34. // 進來這裡，說明是 firstReader 重入獲取讀鎖（這非常簡單，count 加 1 結束）
35. firstReaderHoldCount++;
36. } else {
37. // 前面我們說了 cachedHoldCounter 用於緩存最後一個獲取讀鎖的線程
38. // 如果 cachedHoldCounter 緩存的不是當前線程，設置為緩存當前線程的 HoldCounter
39. HoldCounter rh = cachedHoldCounter;
40. if (rh == null || rh.tid != getThreadId(current))
41. cachedHoldCounter = rh = readHolds.get();
42. else if (rh.count == 0)
43. // 到這裡，那麼就是 cachedHoldCounter 緩存的是當前線程，但是 count 為 0，
44. // 大家可以思考一下：這裡為什麼要 set ThreadLocal 呢？(當然，答案肯定不在這塊代碼中)
45. // 既然 cachedHoldCounter 緩存的是當前線程，
46. // 當前線程肯定調用過 readHolds.get() 進行初始化 ThreadLocal
47. readHolds.set(rh);
49. // count 加 1
50. rh.count++;
51. }
52. // return 大於 0 的數，代表獲取到了共享鎖
53. return 1;
54. }
55. // 往下看
56. return fullTryAcquireShared(current);
57. }

上面的代碼中，要進入 if 分支，需要滿足：readerShouldBlock() 返回 false，並且 CAS 要成功（我們先不要糾結 MAX_COUNT 溢出）。

那我們反向推，怎麼樣進入到最後的 fullTryAcquireShared：

• readerShouldBlock() 返回 true，2 種情況：
• 在 FairSync 中說的是 hasQueuedPredecessors()，即阻塞隊列中有其他元素在等待鎖。

也就是說，公平模式下，有人在排隊呢，你新來的不能直接獲取鎖

• 在 NonFairSync 中說的是 apparentlyFirstQueuedIsExclusive()，即判斷阻塞隊列中 head 的第一個後繼節點是否是來獲取寫鎖的，如果是的話，讓這個寫鎖先來，避免寫鎖飢餓。

作者給寫鎖定義了更高的優先級，所以如果碰上獲取寫鎖的線程馬上就要獲取到鎖了，獲取讀鎖的線程不應該和它搶。

如果 head.next 不是來獲取寫鎖的，那麼可以隨便搶，因為是非公平模式，大家比比 CAS 速度

• compareAndSetState(c, c + SHARED_UNIT) 這裡 CAS 失敗，存在競爭。可能是和另一個讀鎖獲取競爭，當然也可能是和另一個寫鎖獲取操作競爭。

然後就會來到 fullTryAcquireShared 中再次嘗試：

1. 
   
2. /**
3. * 1. 剛剛我們說了可能是因為 CAS 失敗，如果就此返回，那麼就要進入到阻塞隊列了，
4. * 想想有點不甘心，因為都已經滿足了 !readerShouldBlock()，也就是說本來可以不用到阻塞隊列的，
5. * 所以進到這個方法其實是增加 CAS 成功的機會
6. * 2. 在 NonFairSync 情況下，雖然 head.next 是獲取寫鎖的，我知道它等待很久了，我沒想和它搶，
7. * 可是如果我是來重入讀鎖的，那麼只能表示對不起了
8. */
9. final int fullTryAcquireShared(Thread current) {
10. HoldCounter rh = null;
11. // 別忘了這外層有個 for 循環
12. for (;;) {
13. int c = getState();
14. // 如果其他線程持有了寫鎖，自然這次是獲取不到讀鎖了，乖乖到阻塞隊列排隊吧
15. if (exclusiveCount(c) != 0) {
16. if (getExclusiveOwnerThread() != current)
17. return -1;
18. // else we hold the exclusive lock; blocking here
19. // would cause deadlock.
20. } else if (readerShouldBlock()) {
21. /**
22. * 進來這裡，說明：
23. * 1. exclusiveCount(c) == 0：寫鎖沒有被佔用
24. * 2. readerShouldBlock() 為 true，說明阻塞隊列中有其他線程在等待
25. *
26. * 既然 should block，那進來這裡是幹什麼的呢？
27. * 答案：是進來處理讀鎖重入的！
28. *
29. */
31. // firstReader 線程重入讀鎖，直接到下面的 CAS
32. if (firstReader == current) {
33. // assert firstReaderHoldCount > 0;
34. } else {
35. if (rh == null) {
36. rh = cachedHoldCounter;
37. if (rh == null || rh.tid != getThreadId(current)) {
38. // cachedHoldCounter 緩存的不是當前線程
39. // 那麼到 ThreadLocal 中獲取當前線程的 HoldCounter
40. // 如果當前線程從來沒有初始化過 ThreadLocal 中的值，get() 會執行初始化
41. rh = readHolds.get();
42. // 如果發現 count == 0，也就是說，純屬上一行代碼初始化的，那麼執行 remove
43. // 然後往下兩三行，乖乖排隊去
44. if (rh.count == 0)
45. readHolds.remove();
46. }
47. }
48. if (rh.count == 0)
49. // 排隊去。
50. return -1;
51. }
52. /**
53. * 這塊代碼我看了蠻久才把握好它是幹嘛的，原來只需要知道，它是處理重入的就可以了。
54. * 就是為了確保讀鎖重入操作能成功，而不是被塞到阻塞隊列中等待
55. *
56. * 另一個信息就是，這裡對於 ThreadLocal 變量 readHolds 的處理：
57. * 如果 get() 後發現 count == 0，居然會做 remove() 操作，
58. * 這行代碼對於理解其他代碼是有幫助的
59. */
60. }
62. if (sharedCount(c) == MAX_COUNT)
63. throw new Error("Maximum lock count exceeded");
65. if (compareAndSetState(c, c + SHARED_UNIT)) {
66. // 這裡 CAS 成功，那麼就意味著成功獲取讀鎖了
67. // 下面需要做的是設置 firstReader 或 cachedHoldCounter
69. if (sharedCount(c) == 0) {
70. // 如果發現 sharedCount(c) 等於 0，就將當前線程設置為 firstReader
71. firstReader = current;
72. firstReaderHoldCount = 1;
73. } else if (firstReader == current) {
74. firstReaderHoldCount++;
75. } else {
76. // 下面這幾行，就是將 cachedHoldCounter 設置為當前線程
77. if (rh == null)
78. rh = cachedHoldCounter;
79. if (rh == null || rh.tid != getThreadId(current))
80. rh = readHolds.get();
81. else if (rh.count == 0)
82. readHolds.set(rh);
83. rh.count++;
84. cachedHoldCounter = rh;
85. }
86. // 返回大於 0 的數，代表獲取到了讀鎖
87. return 1;
88. }
89. }
90. }

firstReader 是每次將讀鎖獲取次數從 0 變為 1 的那個線程。

能緩存到 firstReader 中就不要緩存到 cachedHoldCounter 中。

上面的源碼分析應該說得非常詳細了，如果到這裡你不太能看懂上面的有些地方的註釋，那麼可以先往後看，然後再多看幾遍。

讀鎖釋放

下面我們看看讀鎖釋放的流程：

1. 
   
2. // ReadLock
3. public void unlock() {
4. sync.releaseShared(1);
5. }
6. // Sync
7. public final boolean releaseShared(int arg) {
8. if (tryReleaseShared(arg)) {
9. doReleaseShared(); // 這句代碼其實喚醒 獲取寫鎖的線程，往下看就知道了
10. return true;
11. }
12. return false;
13. }
15. // Sync
16. protected final boolean tryReleaseShared(int unused) {
17. Thread current = Thread.currentThread();
18. if (firstReader == current) {
19. if (firstReaderHoldCount == 1)
20. // 如果等於 1，那麼這次解鎖後就不再持有鎖了，把 firstReader 置為 null，給後來的線程用
21. // 為什麼不順便設置 firstReaderHoldCount = 0？因為沒必要，其他線程使用的時候自己會設值
22. firstReader = null;
23. else
24. firstReaderHoldCount--;
25. } else {
26. // 判斷 cachedHoldCounter 是否緩存的是當前線程，不是的話要到 ThreadLocal 中取
27. HoldCounter rh = cachedHoldCounter;
28. if (rh == null || rh.tid != getThreadId(current))
29. rh = readHolds.get();
31. int count = rh.count;
32. if (count <= 1) {
34. // 這一步將 ThreadLocal remove 掉，防止內存洩漏。因為已經不再持有讀鎖了
35. readHolds.remove();
37. if (count <= 0)
38. // 就是那種，lock() 一次，unlock() 好幾次的逗比
39. throw unmatchedUnlockException();
40. }
41. // count 減 1
42. --rh.count;
43. }
45. for (;;) {
46. int c = getState();
47. // nextc 是 state 高 16 位減 1 後的值
48. int nextc = c - SHARED_UNIT;
49. if (compareAndSetState(c, nextc))
50. // 如果 nextc == 0，那就是 state 全部 32 位都為 0，也就是讀鎖和寫鎖都空了
51. // 此時這裡返回 true 的話，其實是幫助喚醒後繼節點中的獲取寫鎖的線程
52. return nextc == 0;
53. }
54. }

讀鎖釋放的過程還是比較簡單的，主要就是將 hold count 減 1，如果減到 0 的話，還要將 ThreadLocal 中的 remove 掉。

然後是在 for 循環中將 state 的高 16 位減 1，如果發現讀鎖和寫鎖都釋放光了，那麼喚醒後繼的獲取寫鎖的線程。

寫鎖獲取

1. 寫鎖是獨佔鎖。
2. 如果有讀鎖被佔用，寫鎖獲取是要進入到阻塞隊列中等待的。
3. // WriteLock
4. public void lock() {
5. sync.acquire(1);
6. }
7. // AQS
8. public final void acquire(int arg) {
9. if (!tryAcquire(arg) &&
10. // 如果 tryAcquire 失敗，那麼進入到阻塞隊列等待
11. acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
12. selfInterrupt();
13. }
15. // Sync
16. protected final boolean tryAcquire(int acquires) {
18. Thread current = Thread.currentThread();
19. int c = getState();
20. int w = exclusiveCount(c);
21. if (c != 0) {
23. // 看下這裡返回 false 的情況：
24. // c != 0 && w == 0: 寫鎖可用，但是有線程持有讀鎖(也可能是自己持有)
25. // c != 0 && w !=0 && current != getExclusiveOwnerThread(): 其他線程持有寫鎖
26. // 也就是說，只要有讀鎖或寫鎖被佔用，這次就不能獲取到寫鎖
27. if (w == 0 || current != getExclusiveOwnerThread())
28. return false;
30. if (w + exclusiveCount(acquires) > MAX_COUNT)
31. throw new Error("Maximum lock count exceeded");
33. // 這裡不需要 CAS，仔細看就知道了，能到這裡的，只可能是寫鎖重入，不然在上面的 if 就攔截了
34. setState(c + acquires);
35. return true;
36. }
38. // 如果寫鎖獲取不需要 block，那麼進行 CAS，成功就代表獲取到了寫鎖
39. if (writerShouldBlock() ||
40. !compareAndSetState(c, c + acquires))
41. return false;
42. setExclusiveOwnerThread(current);
43. return true;
44. }

下面看一眼 writerShouldBlock() 的判定，然後你再回去看一篇寫鎖獲取過程。

1. 
   
2. static final class NonfairSync extends Sync {
3. // 如果是非公平模式，那麼 lock 的時候就可以直接用 CAS 去搶鎖，搶不到再排隊
4. final boolean writerShouldBlock() {
5. return false; // writers can always barge
6. }
7. ...
8. }
9. static final class FairSync extends Sync {
10. final boolean writerShouldBlock() {
11. // 如果是公平模式，那麼如果阻塞隊列有線程等待的話，就乖乖去排隊
12. return hasQueuedPredecessors();
13. }
14. ...
15. }

寫鎖釋放

1. 
   
2. // WriteLock
3. public void unlock() {
4. sync.release(1);
5. }
7. // AQS
8. public final boolean release(int arg) {
9. // 1. 釋放鎖
10. if (tryRelease(arg)) {
11. // 2. 如果獨佔鎖釋放"完全"，喚醒後繼節點
12. Node h = head;
13. if (h != null && h.waitStatus != 0)
14. unparkSuccessor(h);
15. return true;
16. }
17. return false;
18. }
20. // Sync
21. // 釋放鎖，是線程安全的，因為寫鎖是獨佔鎖，具有排他性
22. // 實現很簡單，state 減 1 就是了
23. protected final boolean tryRelease(int releases) {
24. if (!isHeldExclusively())
25. throw new IllegalMonitorStateException();
26. int nextc = getState() - releases;
27. boolean free = exclusiveCount(nextc) == 0;
28. if (free)
29. setExclusiveOwnerThread(null);
30. setState(nextc);
31. // 如果 exclusiveCount(nextc) == 0，也就是說包括重入的，所有的寫鎖都釋放了，
32. // 那麼返回 true，這樣會進行喚醒後繼節點的操作。
33. return free;
34. }

看到這裡，是不是發現寫鎖相對於讀鎖來說要簡單很多。

鎖降級

Doug Lea 沒有說寫鎖更高級，如果有線程持有讀鎖，那麼寫鎖獲取也需要等待。

不過從源碼中也可以看出，確實會給寫鎖一些特殊照顧，如非公平模式下，為了提高吞吐量，lock 的時候會先 CAS 競爭一下，能成功就代表讀鎖獲取成功了，但是如果發現 head.next 是獲取寫鎖的線程，就不會去做 CAS 操作。

Doug Lea 將持有寫鎖的線程，去獲取讀鎖的過程稱為鎖降級（Lock downgrading）。這樣，此線程就既持有寫鎖又持有讀鎖。

但是，鎖升級是不可以的。線程持有讀鎖的話，在沒釋放的情況下不能去獲取寫鎖，因為會發生死鎖。

回去看下寫鎖獲取的源碼：

1. 
   
2. protected final boolean tryAcquire(int acquires) {
4. Thread current = Thread.currentThread();
5. int c = getState();
6. int w = exclusiveCount(c);
7. if (c != 0) {
8. // 看下這裡返回 false 的情況：
9. // c != 0 && w == 0: 寫鎖可用，但是有線程持有讀鎖(也可能是自己持有)
10. // c != 0 && w !=0 && current != getExclusiveOwnerThread(): 其他線程持有寫鎖
11. // 也就是說，只要有讀鎖或寫鎖被佔用，這次就不能獲取到寫鎖
12. if (w == 0 || current != getExclusiveOwnerThread())
13. return false;
14. ...
15. }
16. ...
17. }

仔細想想，如果線程 a 先獲取了讀鎖，然後獲取寫鎖，那麼線程 a 就到阻塞隊列休眠了，自己把自己弄休眠了，而且可能之後就沒人去喚醒它了。

總結

關注筆者，私信回覆‘資料’獲取。

閱讀更多 JavaSpring高級進階 的文章

關鍵字: 讀鎖 編程語言 技術