java.util.concurrent.locks
介面 ReadWriteLock

所有已知實作類別：

ReentrantReadWriteLock

public interface ReadWriteLock

ReadWriteLock 維護了一對相關的鎖，一個用於只讀操作，另一個用於寫入操作。只要沒有 writer，讀取鎖可以由多個 reader 執行緒同時保持。寫入鎖是獨佔的。

所有 ReadWriteLock 實作都必須保證 writeLock 操作的記憶體同步效果也要保持與相關 readLock 的聯繫。也就是說，成功獲取讀鎖的執行緒會看到寫入鎖之前版本所做的所有更新。

與互斥鎖相比，讀-寫鎖允許對共享資料進行更高層級別的共時存取。雖然一次只有一個執行緒（writer 執行緒）可以修改共享資料，但在許多情況下，任何數量的執行緒可以同時讀取共享資料（reader 執行緒），讀-寫鎖利用了這一點。從理論上講，與互斥鎖相比，使用讀-寫鎖所允許的共時性增強將帶來更大的性能提高。在實踐中，只有在多處理器上並且只在存取網要適用於共享資料時，才能完全實作共時性增強。

與互斥鎖相比，使用讀-寫鎖能否提升性能則取決於讀寫操作期間讀取資料相對於修改資料的頻率，以及資料的爭用——即在同一時間試圖對該資料執行讀取或寫入操作的執行緒數。例如，某個最初用資料填充並且之後不經常對其進行修改的 collection，因為經常對其進行搜尋（比如搜尋某種目錄），所以這樣的 collection 是使用讀-寫鎖的理想候選者。但是，如果資料更新變得頻繁，資料在大部分時間都被獨佔鎖，這時，就算存在共時性增強，也是微不足道的。更進一步地說，如果讀取操作所用時間太短，則讀-寫鎖實作（它本身就比互斥鎖複雜）的開銷將成為主要的執行成本，在許多讀-寫鎖實作仍然通過一小段程式碼將所有執行緒序列化時更是如此。最終，只有通過分析和測量，才能確定應用程序是否適合使用讀-寫鎖。

儘管讀-寫鎖的基本操作是直截了當的，但實作仍然必須作出許多決策，這些決策可能會影響給定應用程序中讀-寫鎖的效果。這些策略的例子包括：

• 在 writer 釋放寫入鎖時，reader 和 writer 都處於等待狀態，在這時要確定是授予讀取鎖還是授予寫入鎖。Writer 優先比較普遍，因為預期寫入所需的時間較短並且不那麼頻繁。Reader 優先不太普遍，因為如果 reader 正如預期的那樣頻繁和持久，那麼它將導致對於寫入操作來說較長的時延。公平或者“按次序”實作也是有可能的。
• 在 reader 處於活動狀態而 writer 處於等待狀態時，確定是否向請求讀取鎖的 reader 授予讀取鎖。Reader 優先會無限期地延遲 writer，而 writer 優先會減少可能的共時。
• 確定是否重新進入鎖：可以使用帶有寫入鎖的執行緒重新獲取它嗎？可以在保持寫入鎖的同時獲取讀取鎖嗎？可以重新進入寫入鎖本身嗎？
• 可以將寫入鎖在不允許其他 writer 干涉的情況下降級為讀取鎖嗎？可以優先於其他等待的 reader 或 writer 將讀取鎖升級為寫入鎖嗎？

當評估給定實作是否適合您的應用程序時，應該考慮所有這些情況。

從以下版本開始：

1.5

另請參見：

ReentrantReadWriteLock, Lock, ReentrantLock

方法摘要

Lock	readLock() 返回用於讀取操作的鎖。
Lock	writeLock() 返回用於寫入操作的鎖。

方法詳細資訊

readLock

Lock readLock()

返回用於讀取操作的鎖。

返回：

用於讀取操作的鎖。

writeLock

Lock writeLock()

返回用於寫入操作的鎖。

返回：

用於寫入操作的鎖。