> 本文來源於公眾號【胖滾豬學程式設計】 轉載請註明出處！ 在[互斥鎖ReentrantLock不好用？試試讀寫鎖ReadWriteLock](http://mp.weixin.qq.com/s?__biz=MzA3MjY1MTcyNw==&mid=2247484351&idx=1&sn=d126f11d22ce9e465e5a5f7bed9592ab&chksm=9f1a451fa86dcc0949ead5fa1d75c47d56d774d2d5d197a9c7f0a2d0b29345f158469b494de7#rd)一文中，我們對比了互斥鎖ReentrantLock和讀寫鎖ReadWriteLock的區別，說明了讀寫鎖在讀多寫少的場景下具有明顯的效能優勢，但是人的慾望是無窮的，還是不能被滿足。。  # 資料庫中的鎖 由於大部分碼農接觸鎖都是從資料庫中的鎖開始的，所以這裡不妨先聊聊資料庫中的鎖。 我們以火車票售票的例子，假設如下場景，兩處火車票售票點同時讀取某一趟列車車票資料庫中的餘票數量，然後兩處售票點同時賣出一張車票，同時修改餘票為 X -1，寫回資料庫，這樣就造成了實際賣出兩張火車票而資料庫中的記錄卻只減少了一張。 如果你閱讀了公眾號【胖滾豬學程式設計】的併發系列文章，包括：[如何解決原子性問題](http://mp.weixin.qq.com/s?__biz=MzA3MjY1MTcyNw==&mid=2247484289&idx=1&sn=381562e6dccaa61eaa26b7301f162b5e&chksm=9f1a4521a86dcc3747f6dc986b16d6dc8d1f75434c0f56eb99ce9fbb8ebdfbaa85c33f11f740#rd)、[ReentrantLock互斥鎖](http://mp.weixin.qq.com/s?__biz=MzA3MjY1MTcyNw==&mid=2247484334&idx=1&sn=a9a45cbea5155c025a30191d9dd8dee2&chksm=9f1a450ea86dcc18d418552530cc9869be0b6f8862944d7ecb8019b8ae3a3eff121a594de09e#rd)、[讀寫鎖ReadWriteLock](http://mp.weixin.qq.com/s?__biz=MzA3MjY1MTcyNw==&mid=2247484351&idx=1&sn=d126f11d22ce9e465e5a5f7bed9592ab&chksm=9f1a451fa86dcc0949ead5fa1d75c47d56d774d2d5d197a9c7f0a2d0b29345f158469b494de7#rd)，那麼你一定知道出現原因和解決方案，對了，可以**使用鎖**。 鎖可以分為兩大類，樂觀鎖和悲觀鎖： - **悲觀鎖**：顧名思義，就是很悲觀，總是假設最壞的情況，每次去拿資料的時候都認為別人會修改， 所以每次在拿資料的時候都會上鎖，這樣別人想拿這個資料就會阻塞直到它拿到鎖。 - **樂觀鎖**：樂觀鎖，每次去拿資料的時候想法都是“沒事，肯定沒被改過”，於是就開心地獲取到資料，不放心嗎？那就在更新的時候判斷一下在此期間別人有沒有去更新過這個資料，可以使用版本號等機制。 一般情況下，資料庫都會有讀共享寫獨佔的鎖併發的方案，也就是說讀讀併發是沒問題的，但在讀寫併發時，則有可能出現讀取不一致情況，也就是常說的髒讀，所以在悲觀鎖的模式下，在有寫執行緒的時候，是不允許有任何其他的讀和寫執行緒的，也就是說寫是獨佔的，這樣會導致系統的吞吐明顯下降。**我們所說的ReadWriteLock的寫鎖就屬於悲觀鎖。** 如何避免這一情況，答案是使用樂觀鎖。每個執行緒都不會修改原始資料，而是從原始資料上拷貝上一份資料，同時記錄版本號，不同的執行緒更新自己的資料，在最終寫會時會判斷版本號是否變更，如果變更則意味有人已經更改過了，那麼當前執行緒需要做的就是自旋重試，如果重試指定的次數依然失敗，那麼就應該放棄更新，這種策略僅僅適合寫併發並不強烈的場景，如果寫競爭嚴重，那麼多次自旋重試的開銷也是非常耗效能的，如果競爭激烈，那麼寫鎖獨佔的方式則更加適合。 **那麼具體怎麼使用版本號機制呢？** 很簡單，對資料庫表添加了一個version欄位，設定為bigint型別。查詢的時候我們需要查出版本資訊，更新的時候，需要將版本資訊+1。 ``` 1.查詢資料資訊 select xxx,version from xxx where id= #{id} 2.根據資料資訊是判斷當前資料庫中的version是否還是剛才查出來的那個version update xxx set xxx=xxx ,version = version+1 where id=#{id} and version= #{version}; ``` 由於update指定了where條件，可根據返回修改記錄條數來判斷當前更新是否生效，如果成功改動0條資料，說明version發生了變更，這時候可以根據自己業務邏輯來決定是否需要回滾事務。 資料庫裡的樂觀鎖，查詢的時候需要把 version 欄位查出來，更新的時候要利用 version 欄位做驗證。**這個 version 欄位就類似於今天我們要說的 StampedLock 裡面的 stamp**。基於上面談到的這些內容，我們再來分析StampedLock類，就會非常比較容易理解。 > 本文來源於公眾號【胖滾豬學程式設計】 以漫畫形式讓程式設計so easy and interesting ！轉載請註明出處！ # StampedLock Java 在 1.8 這個版本里，提供了一種叫 StampedLock 的鎖，它的效能比讀寫鎖還要好。 ### 對比ReadWriteLock 我們先來看看StampedLock 和上一篇文章講的 ReadWriteLock 有哪些區別。 ReadWriteLock 支援兩種模式：一種是讀鎖，一種是寫鎖。而 StampedLock 支援三種模式，分別是：**寫鎖、悲觀讀鎖和樂觀讀**。 其中，寫鎖、悲觀讀鎖的語義和 ReadWriteLock 的寫鎖、讀鎖的語義非常類似，允許多個執行緒同時獲取悲觀讀鎖，但是隻允許一個執行緒獲取寫鎖，寫鎖和悲觀讀鎖是互斥的。 不同的是：**StampedLock 裡的寫鎖和悲觀讀鎖加鎖成功之後，都會返回一個 stamp；然後解鎖的時候，需要傳入這個 stamp**，這裡的stamp就類似剛剛我們說的資料庫version，相信你已經明白了。 我們通過程式碼演示一下寫鎖、悲觀讀鎖是如何使用的： ``` // 鎖例項 private final StampedLock sl = new StampedLock(); // 排它鎖-寫鎖 void writeLock() { long stamp = sl.writeLock();//獲取寫鎖 try { // 業務邏輯 } finally { sl.unlockWrite(stamp);//釋放寫鎖 } } // 悲觀讀鎖 void readLock() { long stamp = sl.readLock(); try { // 業務邏輯 } finally { sl.unlockRead(stamp); } } ``` ### 樂觀讀 StampedLock 的效能之所以比 ReadWriteLock 還要好，其關鍵是 StampedLock 支援樂觀讀的方式。所謂樂觀讀，即**讀的時候也能允許一個執行緒獲取寫鎖**，也就是說不是所有的寫操作都被阻塞，自然而然的會比所有寫都阻塞效能要強。 還是通過程式碼來說明一下樂觀讀是如何使用的： ``` // 樂觀讀 double distanceFromOrigin() { long stamp = sl.tryOptimisticRead();//(1) double currentX = x, currentY = y; // 檢查在(1)獲取到讀鎖票據後，鎖有沒被其他寫執行緒排它性搶佔 if (!sl.validate(stamp)) { // 如果被搶佔則獲取一個共享讀鎖（悲觀讀鎖） stamp = sl.readLock(); try { currentX = x; currentY = y; } finally { sl.unlockRead(stamp); } } return Math.sqrt(currentX*currentX + currentY*currentY); } ``` tryOptimisticRead() 就是我們前面提到的樂觀讀。不過需要注意的是，由於 tryOptimisticRead() 是無鎖的，所以共享變數 x 和 y 讀入方法區域性變數時，x 和 y 有可能被其他執行緒修改了。因此最後讀完之後，**還需要再次驗證一下是否存在寫操作**，這個驗證操作是通過呼叫 validate(stamp) 來實現的。 還有一個巧妙的地方：如果執行樂觀讀操作的期間，存在寫操作，**會把樂觀讀升級為悲觀讀鎖**。這個做法挺合理的，否則你就需要在一個迴圈裡反覆執行樂觀讀，直到執行樂觀讀操作的期間沒有寫操作（只有這樣才能保證 x 和 y 的正確性和一致性），而迴圈讀會浪費大量的 CPU。升級為悲觀讀鎖，程式碼簡練且不易出錯。  ### 鎖的升級 在上一篇讀寫鎖文章中，我們說到鎖的升級和降級，ReadWriteLock是隻允許降級而不允許升級的，而StampedLock 支援鎖的降級（通過 tryConvertToReadLock() 方法實現）和升級（通過 tryConvertToWriteLock() 方法實現），讀鎖居然也可以升級為寫鎖，這也是它區別於讀寫鎖的一大特性！ ``` // 讀鎖升級成寫鎖 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); } } ``` ### StampedLock 使用注意事項 StampedLock真有這麼完美嗎？挑刺時間又來咯！ 1、StampedLock 在命名上並沒有增加 Reentrant，顯然，StampedLock 不支援重入。這個是在使用中必須要特別注意的。 2、StampedLock 的悲觀讀鎖、寫鎖都不支援條件變數（Condition），這個也需要你注意。 3、使用 StampedLock 一定不要呼叫中斷操作，即不要呼叫interrupt() 方法，因為內部實現裡while迴圈裡面對中斷的處理有點問題。如果需要支援中斷功能，一定使用可中斷的悲觀讀鎖 readLockInterruptibly() 和寫鎖 writeLockInterruptibly()。 # 總結 以[如何解決原子性問題](http://mp.weixin.qq.com/s?__biz=MzA3MjY1MTcyNw==&mid=2247484289&idx=1&sn=381562e6dccaa61eaa26b7301f162b5e&chksm=9f1a4521a86dcc3747f6dc986b16d6dc8d1f75434c0f56eb99ce9fbb8ebdfbaa85c33f11f740#rd)為起點，我們初始了鎖的概念，瞭解了synchronized鎖模型，之後又走進了J.U.C Lock包，首先接觸到了[ReentrantLock互斥鎖](http://mp.weixin.qq.com/s?__biz=MzA3MjY1MTcyNw==&mid=2247484334&idx=1&sn=a9a45cbea5155c025a30191d9dd8dee2&chksm=9f1a450ea86dcc18d418552530cc9869be0b6f8862944d7ecb8019b8ae3a3eff121a594de09e#rd)，由於互斥鎖在讀多寫少場景的效率不高，因此接觸了[讀寫鎖ReadWriteLock](http://mp.weixin.qq.com/s?__biz=MzA3MjY1MTcyNw==&mid=2247484351&idx=1&sn=d126f11d22ce9e465e5a5f7bed9592ab&chksm=9f1a451fa86dcc0949ead5fa1d75c47d56d774d2d5d197a9c7f0a2d0b29345f158469b494de7#rd)，而今天，又學習了一種比讀寫鎖還要快的鎖StampedLock。說明JAVA真是博大精深，連鎖都有那麼多種，需要根據實際情況合理選擇才是！ 關於StampedLock，**重點應該瞭解它獨特的思想：樂觀的思想**。就像人一樣，不能總是悲觀思想，樂觀思想積極面對生活效率才更高！StampedLock通過一個叫做stamp的類似於資料庫版本號的欄位，實現了樂觀讀。當然永遠樂觀也是不行的，StampedLock也有它的缺陷，對於這些，你也需要特別注意。 > 本文來源於公眾號【胖滾豬學程式設計】 以漫畫形式讓程式設計so easy and interesting ！轉載請註明出處！ > 本文轉載自公眾號【胖滾豬學程式設計】 用漫畫讓程式設計so easy and interesting！歡迎關注！形象來源於微信表情包【胖滾家族】喜歡可以