摘要：一起來聊聊在高并發環境下比ReadWriteLock更快的鎖——StampedLock。

本文分享自華為雲社區《【高并發】高并發場景下一種比讀寫鎖更快的鎖，看完我徹底折服了！！（建議收藏）-雲社區-華為雲》，作者：冰 河 。

ReadWriteLock鎖允許多個線程同時讀取共享變量，但是在讀取共享變量的時候，不允許另外的線程多共享變量進行寫操作，更多的适合于讀多寫少的環境中。那麼，在讀多寫少的環境中，有沒有一種比ReadWriteLock更快的鎖呢？

答案當然是有！那就是我們今天要介紹的主角——JDK1.8中新增的StampedLock！沒錯，就是它！

StampedLock與ReadWriteLock相比，在讀的過程中也允許後面的一個線程獲取寫鎖對共享變量進行寫操作，為了避免讀取的數據不一緻，使用StampedLock讀取共享變量時，需要對共享變量進行是否有寫入的檢驗操作，并且這種讀是一種樂觀讀。

總之，StampedLock是一種在讀取共享變量的過程中，允許後面的一個線程獲取寫鎖對共享變量進行寫操作，使用樂觀讀避免數據不一緻的問題，并且在讀多寫少的高并發環境下，比ReadWritelock更快的一種鎖。

這裡，我們可以簡單對比下StampedLock與ReadWriteLock，ReadWriteLock支持兩種鎖模式：一種是讀鎖，另一種是寫鎖，并且ReadWriteLock允許多個線程同時讀共享變量，在讀時，不允許寫，在寫時，不允許讀，讀和寫是互斥的，所以，ReadWriteLock中的讀鎖，更多的是指悲觀讀鎖。

StampedLock支持三種鎖模式：寫鎖、讀鎖（這裡的讀鎖指的是悲觀讀鎖）和樂觀讀（很多資料和書籍寫的是樂觀讀鎖，這裡我個人覺得更準确的是樂觀讀，為啥呢？我們繼續往下看啊）。其中，寫鎖和讀鎖與ReadWriteLock中的語義類似，允許多個線程同時獲取讀鎖，但是隻允許一個線程獲取寫鎖，寫鎖和讀鎖也是互斥的。

另一個與ReadWriteLock不同的地方在于：StampedLock在獲取讀鎖或者寫鎖成功後，都會返回一個long類型的變量，之後在釋放鎖時，需要傳入這個Long類型的變量。例如，下面的僞代碼所示的邏輯演示了StampedLock如何獲取鎖和釋放鎖。

public class StampedLockDemo{ //創建StampedLock鎖對象 public StampedLock stampedLock = new StampedLock(); //獲取、釋放讀鎖 public void testGetAndReleaseReadLock(){ long stamp = stampedLock.readLock(); try{ //執行獲取讀鎖後的業務邏輯 }finally{ //釋放鎖 stampedLock.unlockRead(stamp); } } //獲取、釋放寫鎖 public void testGetAndReleaseWriteLock(){ long stamp = stampedLock.writeLock(); try{ //執行獲取寫鎖後的業務邏輯。 }finally{ //釋放鎖 stampedLock.unlockWrite(stamp); } } }

StampedLock支持樂觀讀，這是它比ReadWriteLock性能要好的關鍵所在。 ReadWriteLock在讀取共享變量時，所有對共享變量的寫操作都會被阻塞。而StampedLock提供的樂觀讀，在多個線程讀取共享變量時，允許一個線程對共享變量進行寫操作。

我們再來看一下JDK官方給出的StampedLock示例，如下所示。

class Point { private double x, y; private final StampedLock sl = new StampedLock(); void move(double deltaX, double deltaY) { // an exclusively locked method long stamp = sl.writeLock(); try { x = deltaX; y = deltaY; } finally { sl.unlockWrite(stamp); } } double distanceFromOrigin() { // A read-only method long stamp = sl.tryOptimisticRead(); double currentX = x, currentY = y; if (!sl.validate(stamp)) { stamp = sl.readLock(); try { currentX = x; currentY = y; } finally { sl.unlockRead(stamp); } } return Math.sqrt(currentX * currentX currentY * currentY); } void moveIfAtOrigin(double newX, double newY) { // upgrade // Could instead start with optimistic, not read mode long stamp = sl.readLock(); try { while (x == 0.0 && y == 0.0) { long ws = sl.tryConvertToWriteLock(stamp); if (ws != 0L) { stamp = ws; x = newX; y = newY; break; } else { sl.unlockRead(stamp); stamp = sl.writeLock(); } } } finally { sl.unlock(stamp); } } }

在上述代碼中，如果在執行樂觀讀操作時，另外的線程對共享變量進行了寫操作，則會把樂觀讀升級為悲觀讀鎖，如下代碼片段所示。

double distanceFromOrigin() { // A read-only method //樂觀讀 long stamp = sl.tryOptimisticRead(); double currentX = x, currentY = y; //判斷是否有線程對變量進行了寫操作 //如果有線程對共享變量進行了寫操作 //則sl.validate(stamp)會返回false if (!sl.validate(stamp)) { //将樂觀讀升級為悲觀讀鎖 stamp = sl.readLock(); try { currentX = x; currentY = y; } finally { //釋放悲觀鎖 sl.unlockRead(stamp); } } return Math.sqrt(currentX * currentX currentY * currentY); }

這種将樂觀讀升級為悲觀讀鎖的方式相比一直使用樂觀讀的方式更加合理，如果不升級為悲觀讀鎖，則程序會在一個循環中反複執行樂觀讀操作，直到樂觀讀操作期間沒有線程執行寫操作，而在循環中不斷的執行樂觀讀會消耗大量的CPU資源，升級為悲觀讀鎖是更加合理的一種方式。

StampedLock内部是基于CLH鎖實現的，CLH是一種自旋鎖，能夠保證沒有“饑餓現象”的發生，并且能夠保證FIFO（先進先出）的服務順序。

在CLH中，鎖維護一個等待線程隊列，所有申請鎖，但是沒有成功的線程都會存入這個隊列中，每一個節點代表一個線程，保存一個标記位(locked)，用于判斷當前線程是否已經釋放鎖，當locked标記位為true時， 表示獲取到鎖，當locked标記位為false時，表示成功釋放了鎖。

當一個線程試圖獲得鎖時，取得等待隊列的尾部節點作為其前序節點，并使用類似如下代碼判斷前序節點是否已經成功釋放鎖:

while (pred.locked) { //省略操作 }

隻要前序節點(pred)沒有釋放鎖，則表示當前線程還不能繼續執行，因此會自旋等待；反之，如果前序線程已經釋放鎖，則當前線程可以繼續執行。

釋放鎖時，也遵循這個邏輯，線程會将自身節點的locked位置标記為false，後續等待的線程就能繼續執行了，也就是已經釋放了鎖。

StampedLock的實現思想總體來說，還是比較簡單的，這裡就不展開講了。

在讀多寫少的高并發環境下，StampedLock的性能确實不錯，但是它不能夠完全取代ReadWriteLock。在使用的時候，也需要特别注意以下幾個方面。

沒錯，StampedLock是不支持重入的，也就是說，在使用StampedLock時，不能嵌套使用，這點在使用時要特别注意。

第二個需要注意的是就是StampedLock不支持條件變量，無論是讀鎖還是寫鎖，都不支持條件變量。

這點也是最重要的一點，在使用時需要特别注意：如果某個線程阻塞在StampedLock的readLock()或者writeLock()方法上時，此時調用阻塞線程的interrupt()方法中斷線程，會導緻CPU飙升到100%。例如，下面的代碼所示。

public void testStampedLock() throws Exception{ final StampedLock lock = new StampedLock(); Thread thread01 = new Thread(()->{ // 獲取寫鎖 lock.writeLock(); // 永遠阻塞在此處，不釋放寫鎖 LockSupport.park(); }); thread01.start(); // 保證thread01獲取寫鎖 Thread.sleep(100); Thread thread02 = new Thread(()-> //阻塞在悲觀讀鎖 lock.readLock() ); thread02.start(); // 保證T2阻塞在讀鎖 Thread.sleep(100); //中斷線程thread02 //會導緻線程thread02所在CPU飙升 thread02.interrupt(); thread02.join(); }

運行上面的程序，會導緻thread02線程所在的CPU飙升到100%。

這裡，有很多小夥伴不太明白為啥LockSupport.park();會導緻thread01會永遠阻塞。這裡，冰河為你畫了一張線程的生命周期圖，如下所示。

這下明白了吧？在線程的生命周期中，有幾個重要的狀态需要說明一下。

• NEW：初始狀态，線程被構建，但是還沒有調用start()方法。
• RUNNABLE：可運行狀态，可運行狀态可以包括：運行中狀态和就緒狀态。
• BLOCKED：阻塞狀态，處于這個狀态的線程需要等待其他線程釋放鎖或者等待進入synchronized。
• WAITING：表示等待狀态，處于該狀态的線程需要等待其他線程對其進行通知或中斷等操作，進而進入下一個狀态。
• TIME_WAITING：超時等待狀态。可以在一定的時間自行返回。
• TERMINATED：終止狀态，當前線程執行完畢。

看完這個線程的生命周期圖，知道為啥調用LockSupport.park();會使thread02阻塞了吧？

所以，在使用StampedLock時，一定要注意避免線程所在的CPU飙升的問題。那如何避免呢？

那就是使用StampedLock的readLock()方法或者讀鎖和使用writeLock()方法獲取寫鎖時，一定不要調用線程的中斷方法來中斷線程，如果不可避免的要中斷線程的話，一定要用StampedLock的readLockInterruptibly()方法獲取可中斷的讀鎖和使用StampedLock的writeLockInterruptibly()方法獲取可中斷的悲觀寫鎖。

最後，對于StampedLock的使用，JDK官方給出的StampedLock示例本身就是一個最佳實踐了，小夥伴們可以多看看JDK官方給出的StampedLock示例，多多體會下StampedLock的使用方式和背後原理與核心思想。

點擊下方，第一時間了解華為雲新鮮技術~

華為雲博客_大數據博客_AI博客_雲計算博客_開發者中心-華為雲

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!