java.util.concurrent.locks.ReadWriteLock 接口 源碼

相關類圖：

java.util.concurrent.locks.ReadWriteLock 源碼： 

package java.util.concurrent.locks;

public interface ReadWriteLock {
    
    Lock readLock();

    Lock writeLock();
}

接口 ReadWriteLock

全部已知實現類：
    ReentrantReadWriteLock
 

    ReadWriteLock 維護了一對相關的鎖，一個用於只讀操做，另外一個用於寫入操做。只要沒有 writer，讀取鎖 能夠由多個 reader 線程同時保持。寫入鎖 是獨佔的。成功獲取讀鎖的線程會看到寫入鎖以前版本所作的全部更新。

 

    與互斥鎖相比，讀-寫鎖 容許對共享數據進行更高級別的併發訪問。雖然一次只有一個線程（writer 線程）能夠修改共享數據，但在許多狀況下，任何數量的線程能夠同時讀取共享數據（reader 線程）。從理論上講，與互斥鎖相比，使用讀-寫鎖所容許的併發性加強將帶來更大的性能提升。

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

    例如，某個最初用數據填充而且以後不常常對其進行修改的 collection，由於常常對其進行搜索（好比搜索某種目錄），因此這樣的 collection 是使用讀-寫鎖的理想候選者。可是，若是數據更新變得頻繁，數據在大部分時間都被寫入鎖 獨佔，這時，就算存在併發性加強，也是微不足道的。更進一步地說，若是讀取操做所用時間過短，則讀-寫鎖實現（它自己就比互斥鎖複雜）的開銷將成爲主要的執行成本。最終，只有經過分析和測量，才能肯定應用程序是否適合使用讀-寫鎖。

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

• 在 writer 釋放寫入鎖時，reader 和 writer 都處於等待狀態，在這時要肯定是授予讀取鎖仍是授予寫入鎖。Writer 優先比較廣泛，由於預期寫入所需的時間較短而且不那麼頻繁。Reader 優先不太廣泛，由於若是 reader 正如預期的那樣頻繁和持久，那麼它將致使對於寫入操做來講較長的時延。公平或者「按次序」實現也是有可能的。
• 在 reader 處於活動狀態而 writer 處於等待狀態時，肯定是否向請求讀取鎖的 reader 授予讀取鎖。Reader 優先會無限期地延遲 writer，而 writer 優先會減小可能的併發。
• 肯定是否從新進入鎖：可使用帶有寫入鎖的線程從新獲取它嗎？能夠在保持寫入鎖的同時獲取讀取鎖嗎？能夠從新進入寫入鎖自己嗎？
• 能夠將寫入鎖在不容許其餘 writer 干涉的狀況降低級爲讀取鎖嗎？能夠優先於其餘等待的 reader 或 writer 將讀取鎖升級爲寫入鎖嗎？

 

方法摘要

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

 

readLock

Lock readLock()

返回：
用於讀取操做的鎖。
 

writeLock

 

Lock writeLock()

返回：
用於寫入操做的鎖。