前面我們已經分析過JUC包里面的Lock鎖，ReentrantLock鎖和semaphore信號量機制。Lock鎖實現了比synchronized更靈活的鎖機制，Reentrantlock是Lock的實現類，是一種可重入鎖，都是每次只有一次線程對資源進行處理；semaphore實現了多個線程同時對一個資源的訪問；今天我們要講的ReadWriteLock鎖將實現另外一種很重要的功能：讀寫分離鎖。

假設你的程序中涉及到對一些共享資源的讀和寫操作，且寫操作沒有讀操作那么頻繁。在沒有寫操作的時候，兩個線程同時讀一個資源沒有任何問題，所以應該允許多個線程能在同時讀取共享資源。但是如果有一個線程想去寫這些共享資源，就不應該再有其它線程對該資源進行讀或寫，也就是說：讀-讀能共存，讀-寫不能共存，寫-寫不能共存。這就需要一個讀/寫鎖來解決這個問題。

ReadWriteLock簡介

我們在JUC包可以看到ReadWriteLock是一個接口，他有一個實現類：ReentrantReadWriteLock，先讓我們對讀寫訪問資源的條件做個概述：

- 讀取： 沒有線程正在做寫操作，且沒有線程在請求寫操作。 - 寫入： 沒有線程正在做讀寫操作。

如果某個線程想要讀取資源，只要沒有線程正在對該資源進行寫操作且沒有線程請求對該資源的寫操作即可。同樣當有線程想要寫資源，但是此刻有線程正在讀取資源，那么此刻寫資源的操作是不能繼續下去的。

我們來看一個例子:

public class ReadWriteLockTest2 { public static void main(String[] args) { final int threadCount = 2; final ExecutorService exService = Executors.newFixedThreadPool(threadCount); final ScoreBoard scoreBoard = new ScoreBoard(); exService.execute(new ScoreUpdateThread(scoreBoard)); exService.execute(new ScoreHealthThread(scoreBoard)); exService.shutdown(); } } class ScoreBoard { private boolean scoreUpdated = false; private int score = 0; String health = '不可用'; final ReentrantReadWriteLock rrwl = new ReentrantReadWriteLock(); public String getMatchHealth() { rrwl.readLock().lock(); if (scoreUpdated) {rrwl.readLock().unlock();rrwl.writeLock().lock();try { if (scoreUpdated) { score = fetchScore(); scoreUpdated = false; } rrwl.readLock().lock();} finally { rrwl.writeLock().unlock();} } try {if (score % 2 == 0) { health = 'Bad Score';} else { health = 'Good Score';} } finally {rrwl.readLock().unlock(); } return health; } public void updateScore() { try {rrwl.writeLock().lock();scoreUpdated = true; } finally {rrwl.writeLock().unlock(); } } private int fetchScore() { Calendar calender = Calendar.getInstance(); return calender.get(Calendar.MILLISECOND); } } class ScoreHealthThread implements Runnable { private ScoreBoard scoreBoard; public ScoreHealthThread(ScoreBoard scoreTable) { this.scoreBoard = scoreTable; } @Override public void run() { for(int i= 0; i< 5; i++) {System.out.println('Match Health: '+ scoreBoard.getMatchHealth());try { Thread.sleep(2000);} catch (InterruptedException e) { e.printStackTrace();} } } } class ScoreUpdateThread implements Runnable { private ScoreBoard scoreBoard; public ScoreUpdateThread(ScoreBoard scoreTable) { this.scoreBoard = scoreTable; } @Override public void run() { for(int i= 0; i < 5; i++) {System.out.println('Score Updated.');scoreBoard.updateScore();try { Thread.sleep(2000);} catch (InterruptedException e) { e.printStackTrace();} } } }

打印結果：

Score Updated.Match Health: Good ScoreScore Updated.Match Health: Good ScoreScore Updated.Match Health: Good ScoreScore Updated.Match Health: Good ScoreScore Updated.Match Health: Good Score

基本用法見上例，讀寫分離鎖很好的控制了多個線程對同一個資源的訪問。

ReentrantReadWriteLock

由名字我們可以看到讀寫鎖也有可重入的實現類。ReentrantReadWriteLock具有關聯的讀取和寫入鎖定，可以重新獲取鎖定。它可表現為公平和不公平的模式兩者。 默認行為是不公平的。 非公平鎖的性能更好，雖然有可能讀寫器或寫入器鎖可以被推遲許多次，并且持續地嘗試鎖定。 在公平鎖定的情況下，鎖定請求按照最長等待的單個寫入器鎖或讀取鎖定組請求的順序來完成，無論誰具有最長等待時間將獲得對共享資源的鎖定。 在重入ReentrantReadWriteLock可以寫入鎖定降級讀鎖。 這意味著如果線程已經獲得寫鎖定，它可以將其鎖從寫降級到讀鎖。 順序將是首先獲得寫鎖定，執行寫操作，然后獲取讀鎖，然后解鎖寫鎖，并且在讀操作后最終解鎖讀鎖。

ReentrantReadWriteLock 也是基于 AbstractQueuedSynchronizer 實現的，它具有下面這些屬性：

獲取順序

此類不會將讀取者優先或寫入者優先強加給鎖訪問的排序。但是，它確實支持可選的公平 策略。

1.非公平模式（默認）

當非公平地（默認）構造時，未指定進入讀寫鎖的順序，受到 reentrancy 約束的限制。連續競爭的非公平鎖可能無限期地推遲一個或多個 reader 或 writer 線程，但吞吐量通常要高于公平鎖。

2.公平模式

當公平地構造線程時，線程利用一個近似到達順序的策略來爭奪進入。當釋放當前保持的鎖時，可以為等待時間最長的單個 writer 線程分配寫入鎖，如果有一組等待時間大于所有正在等待的 writer 線程 的 reader 線程，將為該組分配寫入鎖。

如果保持寫入鎖，或者有一個等待的 writer 線程，則試圖獲得公平讀取鎖（非重入地）的線程將會阻塞。直到當前最舊的等待 writer 線程已獲得并釋放了寫入鎖之后，該線程才會獲得讀取鎖。當然，如果等待 writer 放棄其等待，而保留一個或更多 reader 線程為隊列中帶有寫入鎖自由的時間最長的 waiter，則將為那些 reader 分配讀取鎖。

試圖獲得公平寫入鎖的（非重入地）的線程將會阻塞，除非讀取鎖和寫入鎖都自由（這意味著沒有等待線程）。（注意，非阻塞 ReentrantReadWriteLock.ReadLock.tryLock() 和 ReentrantReadWriteLock.WriteLock.tryLock() 方法不會遵守此公平設置，并將獲得鎖（如果可能），不考慮等待線程）。

重入

此鎖允許 reader 和 writer 按照 ReentrantLock 的樣式重新獲取讀取鎖或寫入鎖。在寫入線程保持的所有寫入鎖都已經釋放后，才允許重入 reader 使用它們。

此外，writer 可以獲取讀取鎖，但反過來則不成立。在其他應用程序中，當在調用或回調那些在讀取鎖狀態下執行讀取操作的方法期間保持寫入鎖時，重入很有用。如果 reader 試圖獲取寫入鎖，那么將永遠不會獲得成功。

鎖降級

重入還允許從寫入鎖降級為讀取鎖，其實現方式是：先獲取寫入鎖，然后獲取讀取鎖，最后釋放寫入鎖。但是，從讀取鎖升級到寫入鎖是不可能的。

鎖獲取的中斷

讀取鎖和寫入鎖都支持鎖獲取期間的中斷。

Condition 支持

寫入鎖提供了一個 Condition 實現，對于寫入鎖來說，該實現的行為與 ReentrantLock.newCondition() 提供的 Condition 實現對 ReentrantLock 所做的行為相同。當然，此 Condition 只能用于寫入鎖。讀取鎖不支持 Condition，readLock().newCondition() 會拋出 UnsupportedOperationException。

監測

此類支持一些確定是保持鎖還是爭用鎖的方法。這些方法設計用于監視系統狀態，而不是同步控制。

此類行為的序列化方式與內置鎖的相同：反序列化的鎖處于解除鎖狀態，無論序列化該鎖時其狀態如何。

下面的代碼展示了如何利用重入來執行升級緩存后的鎖降級（為簡單起見，省略了異常處理）：

class CachedData { Object data; volatile boolean cacheValid; ReentrantReadWriteLock rwl = new ReentrantReadWriteLock(); void processCachedData() { rwl.readLock().lock(); if (!cacheValid) {// 在獲得寫鎖之前必須釋放讀鎖rwl.readLock().unlock();rwl.writeLock().lock();// Recheck state because another thread might have acquired// write lock and changed state before we did.if (!cacheValid) { data = ... cacheValid = true;}//通過在釋放寫鎖之前獲得讀鎖來降級rwl.readLock().lock();rwl.writeLock().unlock(); // 解鎖寫鎖，但是任然持有讀鎖 } use(data); rwl.readLock().unlock(); } }

與互斥鎖對比

互斥鎖一次只允許一個線程訪問共享數據，哪怕進行的是只讀操作；讀寫鎖允許對共享數據進行更高級別的并發訪問：對于寫操作，一次只有一個線程（write線程）可以修改共享數據，對于讀操作，允許任意數量的線程同時進行讀取。

與互斥鎖相比，使用讀寫鎖能否提升性能則取決于讀寫操作期間讀取數據相對于修改數據的頻率，以及數據的爭用——即在同一時間試圖對該數據執行讀取或寫入操作的線程數。

以上就是java并發編程專題（七）----（JUC）ReadWriteLock的用法的詳細內容，更多關于JAVA （JUC）ReadWriteLock的資料請關注好吧啦網其它相關文章！