Java併發（8）- 讀寫鎖中的效能之王：StampedLock

摘要： 在上一篇《你真的懂ReentrantReadWriteLock嗎？》中我給大家留了一個引子，一個更高效同時可以避免寫飢餓的讀寫鎖---StampedLock。StampedLock實現了不僅多個讀不互相阻塞，同時在讀操作時不會阻塞寫操作。 為什麼StampedLock這麼神奇？能夠達到這種...

在上一篇《你真的懂ReentrantReadWriteLock嗎？》中我給大家留了一個引子，一個更高效同時可以避免寫飢餓的讀寫鎖---StampedLock。StampedLock實現了不僅多個讀不互相阻塞，同時在讀操作時不會阻塞寫操作。

為什麼StampedLock這麼神奇？能夠達到這種效果，它的核心思想在於，在讀的時候如果發生了寫，應該通過重試的方式來獲取新的值，而不應該阻塞寫操作。這種模式也就是典型的無鎖程式設計思想，和CAS自旋的思想一樣。這種操作方式決定了StampedLock在讀執行緒非常多而寫執行緒非常少的場景下非常適用，同時還避免了寫飢餓情況的發生。這篇文章將通過以下幾點來分析StampedLock。

• StampedLock的官方使用示例分析
• 原始碼分析：讀寫鎖共享的狀態量
• 原始碼分析：寫鎖的釋放和獲取
• 原始碼分析：悲觀讀鎖的釋放和獲取
• 效能測試

StampedLock的官方使用示例分析

先來看一個官方給出的StampedLock使用案例：

public class Point {

private double x, y;

private final StampedLock stampedLock = new StampedLock();

//寫鎖的使用
void move(double deltaX, double deltaY){

long stamp = stampedLock.writeLock(); //獲取寫鎖
try {
x += deltaX;
y += deltaY;
} finally {
stampedLock.unlockWrite(stamp); //釋放寫鎖
}
}

//樂觀讀鎖的使用
double distanceFromOrigin() {

long stamp = stampedLock.tryOptimisticRead(); //獲得一個樂觀讀鎖
double currentX = x;
double currentY = y;
if (!stampedLock.validate(stamp)) { //檢查樂觀讀鎖後是否有其他寫鎖發生，有則返回false

stamp = stampedLock.readLock(); //獲取一個悲觀讀鎖

try {
currentX = x;
} finally {
stampedLock.unlockRead(stamp); //釋放悲觀讀鎖
}
} 
return Math.sqrt(currentX*currentX + currentY*currentY);
}

//悲觀讀鎖以及讀鎖升級寫鎖的使用
void moveIfAtOrigin(double newX,double newY) {

long stamp = stampedLock.readLock(); //悲觀讀鎖
try {
while (x == 0.0 && y == 0.0) {
long ws = stampedLock.tryConvertToWriteLock(stamp); //讀鎖轉換為寫鎖
if (ws != 0L) { //轉換成功

stamp = ws; //票據更新
x = newX;
y = newY;
break;
} else {
stampedLock.unlockRead(stamp); //轉換失敗釋放讀鎖
stamp = stampedLock.writeLock(); //強制獲取寫鎖
}
}
} finally {
stampedLock.unlock(stamp); //釋放所有鎖
}
}
}

首先看看第一個方法move，可以看到它和ReentrantReadWriteLock寫鎖的使用基本一樣，都是簡單的獲取釋放，可以猜測這裡也是一個獨佔鎖的實現。需要注意的是 在獲取寫鎖是會返回個只long型別的stamp，然後在釋放寫鎖時會將stamp傳入進去。這個stamp是做什麼用的呢？如果我們在中間改變了這個值又會發生什麼呢？這裡先暫時不做解釋，後面分析原始碼時會解答這個問題。

第二個方法distanceFromOrigin就比較特別了，它呼叫了tryOptimisticRead，根據名字判斷這是一個樂觀讀鎖。首先什麼是樂觀鎖？樂觀鎖的意思就是先假定在樂觀鎖獲取期間，共享變數不會被改變，既然假定不會被改變，那就不需要上鎖。在獲取樂觀讀鎖之後進行了一些操作，然後又呼叫了validate方法，這個方法就是用來驗證tryOptimisticRead之後，是否有寫操作執行過，如果有，則獲取一個讀鎖，這裡的讀鎖和ReentrantReadWriteLock中的讀鎖類似，猜測也是個共享鎖。

第三個方法moveIfAtOrigin，它做了一個鎖升級的操作，通過呼叫tryConvertToWriteLock嘗試將讀鎖轉換為寫鎖，轉換成功後相當於獲取了寫鎖，轉換失敗相當於有寫鎖被佔用，這時通過呼叫writeLock來獲取寫鎖進行操作。

看過了上面的三個方法，估計大家對怎麼使用StampedLock有了一個初步的印象。下面就通過對StampedLock原始碼的分析來一步步瞭解它背後是怎麼解決鎖飢餓問題的。

原始碼分析：讀寫鎖共享的狀態量

從上面的使用示例中我們看到，在StampedLock中，除了提供了類似ReentrantReadWriteLock讀寫鎖的獲取釋放方法，還提供了一個樂觀讀鎖的獲取方式。那麼這三種方式是如何互動的呢？根據AQS的經驗，StampedLock中應該也是使用了一個狀態量來標誌鎖的狀態。通過下面的原始碼可以證明這點：

// 用於操作state後獲取stamp的值
private static final int LG_READERS = 7;
private static final long RUNIT = 1L;//0000 0000 0001
private static final long WBIT= 1L << LG_READERS; //0000 1000 0000
private static final long RBITS = WBIT - 1L;//0000 0111 1111
private static final long RFULL = RBITS - 1L;//0000 0111 1110
private static final long ABITS = RBITS | WBIT;//0000 1111 1111
private static final long SBITS = ~RBITS;//1111 1000 0000

//初始化時state的值
private static final long ORIGIN = WBIT << 1;//0001 0000 0000

//鎖共享變數state
private transient volatile long state;
//讀鎖溢位時用來儲存多出的毒素哦
private transient int readerOverflow;

上面的原始碼中除了定義state變數外，還提供了一系列變數用來操作state，用來表示讀鎖和寫鎖的各種狀態。為了方便理解，我將他們都表示成二進位制的值，長度有限，這裡用低12位來表示64的long，高位自動用0補齊。要理解這些狀態的作用，就需要具體分析三種鎖操作方式是怎麼通過state這一個變數來表示的，首先來看看獲取寫鎖和釋放寫鎖。

原始碼分析：寫鎖的釋放和獲取

public StampedLock() {
state = ORIGIN; //初始化state為 0001 0000 0000
}

public long writeLock() {
long s, next; 
return ((((s = state) & ABITS) == 0L && //沒有讀寫鎖
U.compareAndSwapLong(this, STATE, s, next = s + WBIT)) ? //cas操作嘗試獲取寫鎖
next : acquireWrite(false, 0L));//獲取成功後返回next，失敗則進行後續處理，排隊也在後續處理中
}

public void unlockWrite(long stamp) {
WNode h;
if (state != stamp || (stamp & WBIT) == 0L) //stamp值被修改，或者寫鎖已經被釋放，丟擲錯誤
throw new IllegalMonitorStateException();
state = (stamp += WBIT) == 0L ? ORIGIN : stamp; //加0000 1000 0000來記錄寫鎖的變化，同時改變寫鎖狀態
if ((h = whead) != null && h.status != 0)
release(h);
}

這裡先說明兩點結論：讀鎖通過前7位來表示，每獲取一個讀鎖，則加1。寫鎖通過除前7位後剩下的位來表示，每獲取一次寫鎖，則加1000 0000，這兩點在後面的原始碼中都可以得倒證明。

初始化時將state變數設定為0001 0000 0000。寫鎖獲取通過 ((s = state) & ABITS) 操作等於0時預設沒有讀鎖和寫鎖。寫鎖獲取分三種情況：

• 沒有讀鎖和寫鎖時，state為0001 0000 0000

  0001 0000 0000 & 0000 1111 1111 = 0000 0000 0000 // 等於0L，可以嘗試獲取寫鎖

• 有一個讀鎖時，state為0001 0000 0001

  0001 0000 0001 & 0000 1111 1111 = 0000 0000 0001 // 不等於0L

• 有一個寫鎖，state為0001 1000 0000

  0001 1000 0000 & 0000 1111 1111 = 0000 1000 0000 // 不等於0L

獲取到寫鎖，需要將s + WBIT設定到state，也就是說每次獲取寫鎖，都需要加0000 1000 0000。同時返回s + WBIT的值

0001 0000 0000 + 0000 1000 0000 = 0001 1000 0000

大家可以想象這樣一個場景，字母A變化為B能看到變化，如果在一段時間內從A變到B然後又變到A，在記憶體中自會顯示A，而不能記錄變化的過程，這也就是CAS中的ABA問題。在StampedLock中就是通過每次對高位加0000 1000 0000來達到記錄寫鎖操作的過程，可以通過下面的步驟理解：

第一次獲取寫鎖：

0001 0000 0000 + 0000 1000 0000 = 0001 1000 0000

第一次釋放寫鎖：

0001 1000 0000 + 0000 1000 0000 = 0010 0000 0000

第二次獲取寫鎖：

0010 0000 0000 + 0000 1000 0000 = 0010 1000 0000

第二次釋放寫鎖：

0010 1000 0000 + 0000 1000 0000 = 0011 0000 0000

第n次獲取寫鎖：

1110 0000 0000 + 0000 1000 0000 = 1110 1000 0000

第n次釋放寫鎖：

1110 1000 0000 + 0000 1000 0000 = 1111 0000 0000

可以看到第8位在獲取和釋放寫鎖時會產生變化，也就是說第8位是用來表示寫鎖狀態的，前7位是用來表示讀鎖狀態的，8位之後是用來表示寫鎖的獲取次數的。這樣就有效的解決了ABA問題，留下了每次寫鎖的記錄，也為後面樂觀鎖檢查變化提供了基礎。

關於 acquireWrite 方法這裡不做具體分析，方法非常複雜，感興趣的同學可以網上搜索相關資料。這裡只對該方法做下簡單總結，該方法分兩步來進行執行緒排隊，首先通過隨機探測的方式多次自旋嘗試獲取鎖，然後自旋一定次數失敗後再初始化節點進行插入。

原始碼分析：悲觀讀鎖的釋放和獲取

public long readLock() {
long s = state, next;
return ((whead == wtail && (s & ABITS) < RFULL && //佇列為空，無寫鎖，同時讀鎖未溢位，嘗試獲取讀鎖
U.compareAndSwapLong(this, STATE, s, next = s + RUNIT)) ?//cas嘗試獲取讀鎖+1
next : acquireRead(false, 0L));//獲取讀鎖成功，返回s + RUNIT，失敗進入後續處理，類似acquireWrite
}

public void unlockRead(long stamp) {
long s, m; WNode h;
for (;;) {
if (((s = state) & SBITS) != (stamp & SBITS) ||
(stamp & ABITS) == 0L || (m = s & ABITS) == 0L || m == WBIT)
throw new IllegalMonitorStateException();
if (m < RFULL) {//小於最大記錄值（最大記錄值127超過後放在readerOverflow變數中）
if (U.compareAndSwapLong(this, STATE, s, s - RUNIT)) {//cas嘗試釋放讀鎖-1
if (m == RUNIT && (h = whead) != null && h.status != 0)
release(h);
break;
}
}
else if (tryDecReaderOverflow(s) != 0L) //readerOverflow - 1
break;
}
}

悲觀讀鎖的獲取和ReentrantReadWriteLock類似，不同在於StampedLock的讀鎖很容易溢位，最大隻有127，超過後通過一個額外的變數readerOverflow來儲存，這是為了給寫鎖留下更大的空間，因為寫鎖是在不停增加的。悲觀讀鎖獲取分下面四種情況：

• 沒有讀鎖和寫鎖時，state為0001 0000 0000

  // 小於 0000 0111 1110，可以嘗試獲取讀鎖

  0001 0000 0000 & 0000 1111 1111 = 0000 0000 0000

• 有一個讀鎖時，state為0001 0000 0001

  // 小於 0000 0111 1110，可以嘗試獲取讀鎖

  0001 0000 0001 & 0000 1111 1111 = 0000 0000 0001

• 有一個寫鎖，state為0001 1000 0000

  // 大於 0000 0111 1110，不可以獲取讀鎖

  0001 1000 0000 & 0000 1111 1111 = 0000 1000 0000

• 讀鎖溢位，state為0001 0111 1110

  // 等於 0000 0111 1110，不可以獲取讀鎖

  0001 0111 1110 & 0000 1111 1111 = 0000 0111 1110

  讀鎖的釋放過程在沒有溢位的情況下是通過 s - RUNIT 操作也就是-1來釋放的，當溢位後則將readerOverflow變數-1。

樂觀讀鎖的獲取和驗證

樂觀讀鎖因為實際上沒有獲取過鎖，所以也就沒有釋放鎖的過程，只是在操作後通過驗證檢查和獲取前的變化。原始碼如下：

//嘗試獲取樂觀鎖
public long tryOptimisticRead() {
long s;
return (((s = state) & WBIT) == 0L) ? (s & SBITS) : 0L;
}

//驗證樂觀鎖獲取之後是否有過寫操作
public boolean validate(long stamp) {
//該方法之前的所有load操作在記憶體屏障之前完成，對應的還有storeFence()及fullFence()
U.loadFence();
return (stamp & SBITS) == (state & SBITS);//比較是否有過寫操作
}

樂觀鎖基本原理就時獲取鎖時記錄state的寫狀態，然後在操作完成之後檢查寫狀態是否有變化，因為寫狀態每次都會在高位留下記錄，這樣就避免了寫鎖獲取又釋放後得不到準確資料。獲取寫鎖記錄有三種情況：

• 沒有讀鎖和寫鎖時，state為0001 0000 0000

  //((s = state) & WBIT) == 0L) true

  0001 0000 0000 & 0000 1000 0000 = 0000 0000 0000

  //(s & SBITS)

  0001 0000 0000 & 1111 1000 0000 = 0001 0000 0000

• 有一個讀鎖時，state為0001 0000 0001

  //((s = state) & WBIT) == 0L) true

  0001 0000 0001 & 0000 1000 0000 = 0000 0000 0000

  //(s & SBITS)

  0001 0000 0001 & 1111 1000 0000 = 0001 0000 0000

• 有一個寫鎖，state為0001 1000 0000

  //((s = state) & WBIT) == 0L) false

  0001 1000 0000 & 0000 1000 0000 = 0000 1000 0000

  //0L

  0000 0000 0000

驗證過程中是否有過寫操作，分四種情況

• 寫過一次

  0001 0000 0000 & 1111 1000 0000 = 0001 0000 0000

  0010 0000 0000 & 1111 1000 0000 = 0010 0000 0000 //false

• 未寫過，但讀過

  0001 0000 0000 & 1111 1000 0000 = 0001 0000 0000

  0001 0000 1111 & 1111 1000 0000 = 0001 0000 0000 //true

• 正在寫

  0001 0000 0000 & 1111 1000 0000 = 0001 0000 0000

  0001 1000 0000 & 1111 1000 0000 = 0001 1000 0000 //false

• 之前正在寫，無論是否寫完都不會為0L

  0000 0000 0000 & 1111 1000 0000 = 0000 0000 0000 //false

效能測試

分析完了StampedLock的實現原理，這裡對StampedLock、ReentrantReadWriteLock以及Synchronized分別在各種場景下進行效能測試，測試的基準程式碼採用https://blog.takipi.com/java-8-stampedlocks-vs-readwritelocks-and-synchronized/ 文章中的程式碼，首先貼出上述部落格中的測試結果,文章中的OPTIMISTIC模式由於採用了“髒讀”模式，這裡不採用OPTIMISTIC的測試結果，只比較StampedLock、ReentrantReadWriteLock以及Synchronized。

看完了上面的測試，前面3種場景表現最好的都為StampedLock，但第4種情況下StampedLock表現很差，於是我自己對程式碼又進行了一遍測試，同時鑑於讀寫鎖的大量應用在快取場景下，讀寫差距極大，我增加了100個讀和1個寫的場景。

同時鑑於原生的Synchronized後期可優化空間比較大，而且在程式碼複雜性以及安全性上面都具有一定優勢，因此在絕大多數場景可以使用Synchronized來進行同步，對效能有一定要求的在某些特定場景下可以使用StampedLock。測試所用程式碼在我所引用的部落格中都可以找到，大家可以自行嘗試測試，如果對結果有什麼疑問，歡迎在評論中提出。