Java 併發包中的讀寫鎖及其實現分析
Java 併發包中的讀寫鎖及其實現分析
1. 前言
在Java併發包中常用的鎖(如:ReentrantLock),基本上都是排他鎖,這些鎖在同一時刻只允許一個執行緒進行訪問,而讀寫鎖在同一時 刻可以允許多個讀執行緒訪問,但是在寫執行緒訪問時,所有的讀執行緒和其他寫執行緒均被阻塞。讀寫鎖維護了一對鎖,一個讀鎖和一個寫鎖,通過分離讀鎖和寫鎖,使得 併發性相比一般的排他鎖有了很大提升。
除了保證寫操作對讀操作的可見性以及併發性的提升之外,讀寫鎖能夠簡化讀寫互動場景的程式設計方式。假設在程式中定義一個共享的資料結構用作快取,它大部分時間提供讀服務(例如:查詢和搜尋),而寫操作佔有的時間很少,但是寫操作完成之後的更新需要對後續的讀服務可見。
在沒有讀寫鎖支援的(Java 5 之前)時候,如果需要完成上述工作就要使用Java的等待通知機制,就是當寫操作開始時,所有晚於寫操作的讀操作均會進入等待狀態,只有寫操作完成並進行 通知之後,所有等待的讀操作才能繼續執行(寫操作之間依靠synchronized關鍵字進行同步),這樣做的目的是使讀操作都能讀取到正確的資料,而不 會出現髒讀。改用讀寫鎖實現上述功能,只需要在讀操作時獲取讀鎖,而寫操作時獲取寫鎖即可,當寫鎖被獲取到時,後續(非當前寫操作執行緒)的讀寫操作都會被 阻塞,寫鎖釋放之後,所有操作繼續執行,程式設計方式相對於使用等待通知機制的實現方式而言,變得簡單明瞭。
一般情況下,讀寫鎖的效能都會比排它鎖要好,因為大多數場景讀是多於寫的。在讀多於寫的情況下,讀寫鎖能夠提供比排它鎖更好的併發性和吞吐量。Java併發包提供讀寫鎖的實現是ReentrantReadWriteLock,它提供的特性如表1所示。
表1. ReentrantReadWriteLock的特性
特性 |
說明 |
---|---|
公平性選擇 |
支援非公平(預設)和公平的鎖獲取方式,吞吐量還是非公平優於公平 |
重進入 |
該鎖支援重進入,以讀寫執行緒為例:讀執行緒在獲取了讀鎖之後,能夠再次獲取讀鎖。而寫執行緒在獲取了寫鎖之後能夠再次獲取寫鎖,同時也可以獲取讀鎖 |
鎖降級 |
遵循獲取寫鎖、獲取讀鎖再釋放寫鎖的次序,寫鎖能夠降級成為讀鎖 |
2. 讀寫鎖的介面與示例
ReadWriteLock僅定義了獲取讀鎖和寫鎖的兩個方法,即readLock()和writeLock()方法,而其實現— ReentrantReadWriteLock,除了介面方法之外,還提供了一些便於外界監控其內部工作狀態的方法,這些方法以及描述如表2所示。
表2. ReentrantReadWriteLock展示內部工作狀態的方法
方法名稱 |
描述 |
---|---|
int getReadLockCount() |
返回當前讀鎖被獲取的次數。該次數不等於獲取讀鎖的執行緒數,比如:僅一個執行緒,它連續獲取(重進入)了n次讀鎖,那麼佔據讀鎖的執行緒數是1,但該方法返回n |
int getReadHoldCount() |
返回當前執行緒獲取讀鎖的次數。該方法在Java 6 中加入到ReentrantReadWriteLock中,使用ThreadLocal儲存當前執行緒獲取的次數,這也使得Java 6 的實現變得更加複雜 |
boolean isWriteLocked() |
判斷寫鎖是否被獲取 |
int getWriteHoldCount() |
返回當前寫鎖被獲取的次數 |
接下來通過一個快取示例說明讀寫鎖的使用方式,示例程式碼如程式碼清單1所示。
程式碼清單1. Cache.java
public class Cache {
static Map<String, Object> map = new HashMap<String, Object>();
static ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
static Lock r = rwl.readLock();
static Lock w = rwl.writeLock();
// 獲取一個key對應的value
public static final Object get(String key) {
r.lock();
try {
return map.get(key);
} finally {
r.unlock();
}
}
// 設定key對應的value,並返回舊有的value
public static final Object put(String key, Object value) {
w.lock();
try {
return map.put(key, value);
} finally {
w.unlock();
}
}
// 清空所有的內容
public static final void clear() {
w.lock();
try {
map.clear();
} finally {
w.unlock();
}
}
}
上述示例中,Cache組合了一個非執行緒安全的HashMap作為快取的實現,同時使用讀寫鎖的讀鎖和寫鎖來保證Cache是執行緒安全的。在讀操作 get(String key)方法中,需要獲取讀鎖,這使得併發訪問該方法時不會被阻塞。寫操作put(String key, Object value)和clear()方法,在更新HashMap時必須提前獲取寫鎖,當寫鎖被獲取後,其他執行緒對於讀鎖和寫鎖的獲取均被阻塞,而只有寫鎖被釋放 之後,其他讀寫操作才能繼續。Cache使用讀寫鎖提升讀操作併發性,也保證每次寫操作對所有的讀寫操作的可見性,同時簡化了程式設計方式。
3. 讀寫鎖的實現分析
接下來將分析ReentrantReadWriteLock的實現,主要包括:讀寫狀態的設計、寫鎖的獲取與釋放、讀鎖的獲取與釋放以及鎖降級(以下沒有特別說明讀寫鎖均可認為是ReentrantReadWriteLock)。
3.1 讀寫狀態的設計
讀寫鎖同樣依賴自定義同步器來實現同步功能,而讀寫狀態就是其同步器的同步狀態。回想ReentrantLock中自定義同步器的實現,同步狀態 表示鎖被一個執行緒重複獲取的次數,而讀寫鎖的自定義同步器需要在同步狀態(一個整型變數)上維護多個讀執行緒和一個寫執行緒的狀態,使得該狀態的設計成為讀寫 鎖實現的關鍵。
如果在一個整型變數上維護多種狀態,就一定需要“按位切割使用”這個變數,讀寫鎖是將變數切分成了兩個部分,高16位表示讀,低16位表示寫,劃分方式如圖1所示。
圖1. 讀寫鎖狀態的劃分方式
如圖1所示,當前同步狀態表示一個執行緒已經獲取了寫鎖,且重進入了兩次,同時也連續獲取了兩次讀鎖。讀寫鎖是如何迅速的確定讀和寫各自的狀態呢? 答案是通過位運算。假設當前同步狀態值為S,寫狀態等於 S & 0x0000FFFF(將高16位全部抹去),讀狀態等於 S >>> 16(無符號補0右移16位)。當寫狀態增加1時,等於S + 1,當讀狀態增加1時,等於S + (1 << 16),也就是S + 0×00010000。
根據狀態的劃分能得出一個推論:S不等於0時,當寫狀態(S & 0x0000FFFF)等於0時,則讀狀態(S >>> 16)大於0,即讀鎖已被獲取。
3.2 寫鎖的獲取與釋放
寫鎖是一個支援重進入的排它鎖。如果當前執行緒已經獲取了寫鎖,則增加寫狀態。如果當前執行緒在獲取寫鎖時,讀鎖已經被獲取(讀狀態不為0)或者該執行緒不是已經獲取寫鎖的執行緒,則當前執行緒進入等待狀態,獲取寫鎖的程式碼如程式碼清單2所示。
程式碼清單2. ReentrantReadWriteLock的tryAcquire方法
protected final boolean tryAcquire(int acquires) {
Thread current = Thread.currentThread();
int c = getState();
int w = exclusiveCount(c);
if (c != 0) {
// 存在讀鎖或者當前獲取執行緒不是已經獲取寫鎖的執行緒
if (w == 0 || current != getExclusiveOwnerThread())
return false;
if (w + exclusiveCount(acquires) > MAX_COUNT)
throw new Error("Maximum lock count exceeded");
setState(c + acquires);
return true;
}
if (writerShouldBlock() || !compareAndSetState(c, c + acquires)) {
return false;
}
setExclusiveOwnerThread(current);
return true;
}
該方法除了重入條件(當前執行緒為獲取了寫鎖的執行緒)之外,增加了一個讀鎖是否存在的判斷。如果存在讀鎖,則寫鎖不能被獲取,原因在於:讀寫鎖要確保 寫鎖的操作對讀鎖可見,如果允許讀鎖在已被獲取的情況下對寫鎖的獲取,那麼正在執行的其他讀執行緒就無法感知到當前寫執行緒的操作。因此只有等待其他讀執行緒都 釋放了讀鎖,寫鎖才能被當前執行緒所獲取,而寫鎖一旦被獲取,則其他讀寫執行緒的後續訪問均被阻塞。
寫鎖的釋放與ReentrantLock的釋放過程基本類似,每次釋放均減少寫狀態,當寫狀態為0時表示寫鎖已被釋放,從而等待的讀寫執行緒能夠繼續訪問讀寫鎖,同時前次寫執行緒的修改對後續讀寫執行緒可見。
3.3 讀鎖的獲取與釋放
讀鎖是一個支援重進入的共享鎖,它能夠被多個執行緒同時獲取,在沒有其他寫執行緒訪問(或者寫狀態為0)時,讀鎖總會成功的被獲取,而所做的也只是 (執行緒安全的)增加讀狀態。如果當前執行緒已經獲取了讀鎖,則增加讀狀態。如果當前執行緒在獲取讀鎖時,寫鎖已被其他執行緒獲取,則進入等待狀態。獲取讀鎖的實 現從Java 5到Java 6變得複雜許多,主要原因是新增了一些功能,比如:getReadHoldCount()方法,返回當前執行緒獲取讀鎖的次數。讀狀態是所有執行緒獲取讀鎖次 數的總和,而每個執行緒各自獲取讀鎖的次數只能選擇儲存在ThreadLocal中,由執行緒自身維護,這使獲取讀鎖的實現變得複雜。因此,這裡將獲取讀鎖的 程式碼做了刪減,保留必要的部分,程式碼如程式碼清單3所示。
程式碼清單3. ReentrantReadWriteLock的tryAcquireShared方法
protected final int tryAcquireShared(int unused) {
for (;;) {
int c = getState();
int nextc = c + (1 << 16);
if (nextc < c)
throw new Error("Maximum lock count exceeded");
if (exclusiveCount(c) != 0 && owner != Thread.currentThread())
return -1;
if (compareAndSetState(c, nextc))
return 1;
}
}
在tryAcquireShared(int unused)方法中,如果其他執行緒已經獲取了寫鎖,則當前執行緒獲取讀鎖失敗,進入等待狀態。如果當前執行緒獲取了寫鎖或者寫鎖未被獲取,則當前執行緒(執行緒安全,依靠CAS保證)增加讀狀態,成功獲取讀鎖。
讀鎖的每次釋放均(執行緒安全的,可能有多個讀執行緒同時釋放讀鎖)減少讀狀態,減少的值是(1 << 16)。
3.4 鎖降級
鎖降級指的是寫鎖降級成為讀鎖。如果當前執行緒擁有寫鎖,然後將其釋放,最後再獲取讀鎖,這種分段完成的過程不能稱之為鎖降級。鎖降級是指把持住(當前擁有的)寫鎖,再獲取到讀鎖,隨後釋放(先前擁有的)寫鎖的過程。
接下來看一個鎖降級的示例:因為資料不常變化,所以多個執行緒可以併發的進行資料處理,當資料變更後,當前執行緒如果感知到資料變化,則進行資料的準備工作,同時其他處理執行緒被阻塞,直到當前執行緒完成資料的準備工作,示例程式碼如程式碼清單4所示。
程式碼清單4. processData方法
public void processData() {
readLock.lock();
if (!update) {
// 必須先釋放讀鎖
readLock.unlock();
// 鎖降級從寫鎖獲取到開始
writeLock.lock();
try {
if (!update) {
// 準備資料的流程(略)
update = true;
}
readLock.lock();
} finally {
writeLock.unlock();
}
// 鎖降級完成,寫鎖降級為讀鎖
}
try {
// 使用資料的流程(略)
} finally {
readLock.unlock();
}
}
上述示例中,當資料發生變更後,update變數(布林型別且Volatile修飾)被設定為false,此時所有訪問processData() 方法的執行緒都能夠感知到變化,但只有一個執行緒能夠獲取到寫鎖,而其他執行緒會被阻塞在讀鎖和寫鎖的lock()方法上。當前程獲取寫鎖完成資料準備之後,再 獲取讀鎖,隨後釋放寫鎖,完成鎖降級。
鎖降級中讀鎖的獲取是否必要呢?答案是必要的。主要原因是保證資料的可見性,如果當前執行緒不獲取讀鎖而是直接釋放寫鎖,假設此刻另一個執行緒(記作 執行緒T)獲取了寫鎖並修改了資料,則當前執行緒無法感知執行緒T的資料更新。如果當前執行緒獲取讀鎖,即遵循鎖降級的步驟,則執行緒T將會被阻塞,直到當前執行緒使 用資料並釋放讀鎖之後,執行緒T才能獲取寫鎖進行資料更新。
RentrantReadWriteLock不支援鎖升級(把持讀鎖、獲取寫鎖,最後釋放讀鎖的過程)。原因也是保證資料可見性,如果讀鎖已被多個執行緒獲取,其中任意執行緒成功獲取了寫鎖並更新了資料,則其更新對其他獲取到讀鎖的執行緒不可見。