我經常聽到Java原子類型（java.util.concurrent.atomic）超級快，可以很好地與高度并發的代碼一起使用。 在大多數情況下，原子以健壯和高效的方式發揮作用。 但是，在某些情況下，原子類型上非托管爭用的隱藏成本成為嚴重的性能問題。 讓我們看一下如何實現java.util.concurrent.atomic.Atomic *類型以及該設計的含義。

所有原子類型，例如AtomicLong，AtomicBoolean，AtomicReference等，本質上都是易失值的包裝器。 附加值來自內部使用的sun.misc.Unsafe ，可為這些類型提供CAS功能。

本質上， CAS（比較和交換）是由現代CPU硬件實現的原子指令，它允許以安全有效的方式進行無阻塞的多線程數據操作。 與鎖定相比，CAS的巨大優勢在于，由于沒有套利，CAS不會在內核級別上產生任何開銷。 而是，編譯器發出CPU指令，例如鎖cmpxchg，鎖xadd，鎖addq等。這與從JVM角度調用指令所獲得的速度一樣快。

在許多情況下，低成本的CAS提供了一種有效的方法來鎖定基元，但是在滿足場景的情況下使用CAS的成本呈指數級增長。

Dave Dice，Danny Hendler和Ilya Mirsky在一項非常有趣的研究中對這個問題進行了研究 。 我強烈建議您閱讀全文，因為它比這篇簡短的文章包含了更多有價值的信息。

我從論文中復制了一些概念，并對其進行了測試。 由于人們對原子（CAS）性能存在普遍的誤解，因此許多Java程序員應該發現結果很能說明問題。

實現退避競爭管理的代碼非常簡單。 它回退了很短的時間，而不是遍歷失敗的比較和交換，讓其他線程嘗試更新。

import java.util.concurrent.atomic.AtomicLong; import java.util.concurrent.locks.LockSupport;public class BackOffAtomicLong {public static long bk;private final AtomicLong value = new AtomicLong(0L);public long get() {return value.get();}public long incrementAndGet() {for (;;) {long current = get();long next = current + 1;if (compareAndSet(current, next))return next;}}public boolean compareAndSet(final long current, final long next) {if (value.compareAndSet(current, next)) {return true;} else {LockSupport.parkNanos(1L);return false;}}public void set(final long l) {value.set(l);}}

該測試是在64位Linux 3.5.0（x86_64）和Intel?CoreTM i7-3632QM CPU @ 2.20GHz（8個邏輯內核）上使用64位Hotspot Java 1.7.0_25-b15執行的。

不出所料，對于高負載爭用，兩種實現之間沒有太大的區別：

但是，在商店競爭激烈的情況下，它變得更加有趣。 這種情況暴露了Hotspot的AtomicLong實現所采用的樂觀重試方法的弱點。

同樣，在讀寫器混合競爭的情況下，輕量級訪問管理的好處也顯而易見。

當涉及套接字間通信時，結果會有很大的不同，但是不幸的是，我在某種程度上失去了針對基于Intel Xeon的硬件進行測試的輸出。 隨時發布不同架構/ JVM的結果。

參考：是否 希望使用AtomicLong更快？ 等待它。 來自我們的JCG合作伙伴 Wojciech Kudla在Fast上。 快點。 怪胎的博客。

翻譯自: https://www.javacodegeeks.com/2014/01/want-to-get-faster-with-atomiclong-make-it-wait.html

總結

以上是生活随笔為你收集整理的想要更快地使用AtomicLong？ 等待它。的全部內容，希望文章能夠幫你解決所遇到的問題。

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