同步部分就像訪問您的岳父母。 您希望盡可能少出現。 關于鎖定，規則是相同的–您想花費最短的時間在關鍵區域內獲取鎖定，以防止形成瓶頸。

鎖定的核心語言慣用法一直是用于方法和離散塊的synced關鍵字。 這個關鍵字實際上已硬連接到HotSpot JVM中。 我們在代碼中分配的每個對象，無論是String，Array還是成熟的JSON文檔，都在本機GC級別的標頭中內置鎖定功能。 對于JIT編譯器（根據特定鎖的特定狀態和爭用級別來編譯和重新編譯字節碼）也是如此。

同步塊的問題在于它們全有還是全無 -關鍵部分中不能有多個線程。 在消費者/生產者方案中，這尤其令人a舌，其中一些線程試圖專門編輯一些數據，而另一些線??程只是試圖讀取數據并且可以共享訪問權限。

ReadWriteLocks旨在成為此的完美解決方案。 您可以指定哪些線程阻止其他所有人（作家），以及哪些線程與其他人一起使用以消費內容（讀者）。 一個快樂的結局？ 不怕。

與同步塊不同，RW鎖不是JVM內置的，并且具有與凡人代碼相同的功能。 盡管如此，要實現鎖定習慣，您仍然需要指示CPU自動執行特定操作或以特定順序執行操作，以避免出現競爭情況。 傳統上，這是通過進入JVM的神奇門戶漏洞- 不安全的類來完成的。 RW鎖使用比較和交換（CAS）操作將值直接設置到內存中，作為其線程排隊算法的一部分。

即便如此，RWLocks仍然不夠快，有時甚至被證明確實很慢 ，以至于不值得為此煩惱。 但是，正在尋求幫助，JDK的好伙伴們沒有放棄，現在又有了新的StampedLock 。 該RW鎖采用了Java 8 JDK中新增的一組算法和內存隔離功能，以幫助使此鎖更快，更可靠。

它兌現了諾言嗎？ 讓我們來看看。

使用鎖。 從表面上看，StampedLocks使用起來更復雜。 他們采用的郵票概念是很長的值，可以用作任何鎖定/解鎖操作使用的票證。 這意味著要解鎖R / W操作，您需要為其傳遞相關的鎖定標記。 通過錯誤的印章，您將面臨例外甚至更糟的意外風險。

另一個需要牢記的關鍵是，與RWLocks不同，StampedLocks 不可重入 。 因此，盡管它們可能更快，但它們有一個缺點，那就是線程現在可以使自己陷入僵局。 實際上，這意味著比以往任何時候都更應該確保鎖和圖章不會逸出其封閉的代碼塊。

long stamp = lock.writeLock(); ?//blocking lock, returns a stamptry {write(stamp); // this is a bad move, you’re letting the stamp escape }finally {lock.unlock(stamp);// release the lock in the same block - way better }

我對這種設計的另一個討厭之處是，郵票被用作長期價值，對您實際上沒有任何意義。 我希望使用鎖定操作來返回一個描述印記的對象-其類型（R / W），鎖定時間，所有者線程等。這將使調試和記錄更加容易。 但是，這可能是有意的，它旨在防止開發人員在代碼的不同部分之間傳遞標記，并且還節省了分配對象的成本。

樂觀鎖 。 就此鎖的新功能而言，最重要的部分是新的樂觀鎖模式。 研究和實踐經驗表明，讀操作在大多數情況下都無法與寫操作抗衡。 結果，獲得一個成熟的讀鎖可能被證明是過大的。 更好的方法可能是繼續執行讀取，并在讀取的最后查看該值是否實際上已被修改。 如果是這種情況，您可以重試讀取，或升級到較重的鎖。

long stamp = lock.tryOptimisticRead(); // non blockingread();if(!lock.validate(stamp)){ // if a write occurred, try again with a read locklong stamp = lock.readLock();try {read();}finally {lock.unlock(stamp);} }

選鎖的最大麻煩之一是，它在生產中的實際行為將根據應用程序狀態而有所不同。 這意味著鎖定習語的選擇不能憑空完成，而必須考慮代碼將在其下執行的實際條件。

并發讀取器線程與寫入器線程的數量將更改您應使用的鎖–同步段或RW鎖。 由于這些數字在JVM的生命周期中會發生變化，因此這變得更加困難，具體取決于應用程序狀態和線程爭用。

為了說明這一點，我對不同鎖定級別和R / W線程組合下的四種鎖定模式進行了壓力測試-同步，RW鎖定，Stamped RW鎖定和RW樂觀鎖定。 讀取器線程將消耗計數器的值，而寫入器線程將其從0遞增到1M。

5個讀取器與5個寫入器：堆疊5個并發讀取器和5個寫入器線程，我們看到加蓋的鎖發光了，性能比同步提高了3倍。 RW鎖定也表現良好。 奇怪的是，樂觀鎖在表面上應該是最快的，但實際上卻是最慢的 。

1 0個讀者與10個作家：接下來，我將爭用級別提高到10個作家和10個讀者線程。 在這里，事情開始發生重大變化。 RW鎖現在比在相同級別上執行的加蓋和同步鎖慢一個數量級。 請注意，令人驚訝的是樂觀鎖仍然是慢速加蓋的RW鎖。

16位讀者與4位作家：接下來，我保持較高的競爭水平，同時又使平衡趨于有利于讀者線程：16位讀者與4位作家。 RW鎖繼續說明了其被替換的原因- 速度慢了一百倍 。 Stamped和Optimistic的性能很好，同步性也不差。

19位讀者與1位讀者：最后，我研究了單個作者線程對19位讀者的影響。 請注意，結果要慢得多，因為單線程需要更長的時間才能完成工作。 在這里，我們得到一些非常有趣的結果。 毫不奇怪，RW鎖需要無窮大才能完成。 但是，沖壓鎖定的性能并沒有好得多……樂觀鎖定顯然是贏家，比RW鎖定高100倍。即使如此，請記住，這種鎖定方式可能會使您失敗，因為在此期間可能會發生寫入器。 我們忠實的老客戶，同步化繼續取得可喜的成果。

完整的結果可以在這里找到……硬件：MBP四核i7。

基準代碼可以在這里找到。

結論

似乎平均而言，內在同步鎖仍可提供總體上最佳的性能。 即使這樣，這里的意思并不是說它將在所有情況下都表現最佳。 主要是為了表明， 在將代碼投入生產之前 ，應該基于測試預期的爭用級別以及讀取器和寫入器線程之間的劃分來選擇鎖定習慣用法。 否則，您將冒著嚴重的生產調試痛苦的風險。

在此處了解有關StampedLocks的更多信息 。

對基準有疑問，意見或建議嗎？ 讓我知道！

翻譯自: https://www.javacodegeeks.com/2014/06/java-8-stampedlocks-vs-readwritelocks-and-synchronized.html

總結

以上是生活随笔為你收集整理的Java 8 StampedLocks与ReadWriteLocks和同步的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。