我從LongAdder中窺探到了高併發的秘籍，上面只寫了兩個字…

admin 環保清潔

這是why的第 53 篇原創文章

荒腔走板

大家好，我是why。

時間過的真是快，一周又要結束了。那麼，你比上周更博學了嗎？先來一個簡短的荒腔走板，給冰冷的技術文注入一絲色彩。

上面這圖是我之前拼的一副拼圖，一共劃分了800塊，背面無提示，難度極高，我花了兩周的時間才拼完。

拼的是壇城，傳說中佛祖居住生活的地方。

第一次知道這個名詞是 2015 年，窩在寢室看紀錄片《第三極》。

其中有一個片段講的就是僧人為了某個節日用沙繪畫壇城，他們的那種專註，虔誠，真摯深深的打動了我，當宏偉的壇城畫完之後，他靜靜的等待節日的到來。

本以為節日當天眾人會對壇城頂禮膜拜，而實際情況是大家手握一炷香，看着眾僧人快速的摧毀壇城。

還沒來得及仔細欣賞那複雜的美麗的圖案，卻又用掃把掃的乾乾凈凈。

掃把掃下去的那一瞬間，我的心受到了一種強烈的撞擊：可以辛苦地拿起，也可以輕鬆地放下。

看到摧毀壇城的片段的時候，有一個彈幕是這樣說的：

一切有為法，如夢幻泡影，如露亦如電，應作如是觀。

這句話出自《金剛般若波羅蜜經》第三十二品，應化非真分。

因為之前翻閱過幾次《金剛經》，看到這句話的時候我一下就想起了它。

因為讀的時候我就覺得這句話很有哲理，但是也似懂非懂。所以印象比較深刻。

當他再次在壇城這個畫面上以彈幕的形式展現在我的眼前的時候，我一下就懂了其中的哲理，不敢說大徹大悟，至少領悟一二。

觀看摧毀壇城，這個色彩斑斕的世界變幻消失的過程，正常人的感受都是震撼，轉而覺得可惜，心裏久久不能平靜。

但是僧人卻風輕雲淡的說：一切有為法，如夢幻泡影，如露亦如電，應作如是觀。

好了，說迴文章。

先說AtomicLong

關於 AtomicLong 我就不進行詳細的介紹了。

先寫這一小節的目的是預熱一下，拋出一個問題，而這個問題是關於 CAS 操作和 volatile 關鍵字的。

我不知道源碼為什麼這樣寫，希望知道答案的朋友指點一二。

抱拳了，老鐵。

為了順利的拋出這個問題，我就得先用《Java併發編程的藝術》一書做引子，引出這個問題。

首先在書的第 2.3 章節《原子操作的實現原理》中介紹處理器是如何實現原子操作時提到了兩點：

  • 使用總線鎖保證原子性。

  • 使用緩存鎖保證原子性。

所謂總線鎖就是使用處理器提供一個提供的一個 LOCK # 信號，當一個處理器在總線上輸出此信號時，其他處理器的請求將被阻塞住，那麼該處理器可以獨佔共享內存。

總線鎖保證原子性的操作有點簡單粗暴直接了，導致總線鎖定的開銷比較大。

所以，目前處理器在某些場合下使用緩存鎖來進行優化。

緩存鎖的概念可以看一下書裏面怎麼寫的：

其中提到的圖 2-3 是這樣的：

其實關鍵 Lock 前綴指令。

被 Lock 前綴指令操作的內存區域就會加鎖，導致其他處理器不能同時訪問。

而根據 IA-32 架構軟件開發者手冊可以知道，Lock 前綴的指令在多核處理器下會引發兩件事情：

  • 將當前處理器緩存行的數據寫回系統內存。
  • 這個寫回內存的操作會使在其他 CPU 里緩存了該內存地址的數據無效。

對於 volatile 關鍵字，毫無疑問，我們是知道它是使用了 Lock 前綴指令的。

那麼問題來了，JVM 的 CAS 操作使用了 Lock 前綴指令嗎？

是的，使用了。

JVM 中的 CAS 操作使用的是處理器通過的 CMPXCHG 指令實現的。這也是一個 Lock 前綴指令。

好，接下來我們看一個方法：

java.util.concurrent.locks.AbstractQueuedLongSynchronizer#compareAndSetState

這個方法位於 AQS 包裏面，就是一個 CAS 的操作。現在只需要關心我框起來的部分。

英文部分翻譯過來是：這個操作具有 volatile 讀和寫的內存語言。

而這個操作是什麼操作？

就是 344 行 unsafe 的 compareAndSwapLong 操作，這個方法是一個 native 方法。

public final native boolean compareAndSwapLong(Object var1, long var2, long var4, long var6);

為什麼這個操作具有 volatile 讀和寫的內存語言呢？

書裏面是這樣寫的：

這個本地方法的最終實現在 openjdk 的如下位置：
openjdk-7-fcs-src-b147- 27_jun_2011\openjdk\hotspot\src\os_cpu\windows_x86\vm\atomic_windows_x86.inline.hpp（對應於Windows操作系統，X86處理器）

intel 的手冊對 Lock 前綴的說明如下。

  • 確保對內存的讀-改-寫操作原子執行。在 Pentium 及 Pentium 之前的處理器中，帶有 Lock 前綴的指令在執行期間會鎖住總線，使得其他處理器暫時無法通過總線訪問內存。很顯然，這會帶來昂貴的開銷。從Pentium 4、Intel Xeon及P6處理器開始，Intel使用緩存鎖定（Cache Locking） 來保證指令執行的原子性。緩存鎖定將大大降低lock前綴指令的執行開銷。

  • 禁止該指令，與之前和之後的讀和寫指令重排序。

  • 把寫緩衝區中的所有數據刷新到內存中。

上面的第2點和第3點所具有的內存屏障效果，足以同時實現 volatile 讀和volatile 寫的內存語義。

好，如果你說你對書上的內容存疑。那麼我帶大家再看看官方文檔：

https://docs.oracle.com/javase/8/docs/api/

我框起來的部分：

compareAndSet 和所有其他的諸如 getAndIncrement 這種讀然後更新的操作擁有和 volatile 讀、寫一樣的內存語義。

原因就是用的到了 Lock 指令。

好，到這裏我們可以得出結論了：

compareAndSet 同時具有volatile讀和volatile寫的內存語義。

那麼問題就來了！

這個操作，在 AtomicLong 裏面也有調用：

而 AtomicLong 裏面的 value 又是被 volatile 修飾了的：

請問：為什麼 compareAndSwapLong 操作已經同時具有 volatile 讀和 volatile 寫的內存語義了，其操作的 value 還需要被 volatile 修飾呢？

這個問題也是一個朋友拋出來探討的，探討的結果是，我們都不知道為什麼：

我猜測會不會是由於操作系統不同而不同。在 x86 上面運行是這樣，其他的操作系統就不一定了，但是沒有證據。

希望知道為什麼這樣做的朋友能指點一下。

好，那麼前面說到 CAS ，那麼一個經典的面試題就來了：

請問，CAS 實現原子操作有哪些問題呢？

  • ABA問題。

  • 循環時間開銷大。

  • 只能保證一個共享變量的原子操作。

如果上面這三點你不知道，或者你說不明白，那我建議你看完本文後一定去了解一下，屬於面試常問系列。

我主要說說這個循環時間開銷大的問題。自旋 CAS 如果長時間不成功，就會對 CPU 帶來比較大的執行開銷。

而回答這個問題的朋友，大多數舉例的時候都會說： “AtomicLong 就是基於自旋 CAS 做的，會帶來一定的性能問題。巴拉巴拉……”

而我作為面試官的時候只是微笑着看着你，讓你錯以為自己答的很完美。

我知道你為什麼這樣答，因為你看了幾篇博客，刷了刷常見面試題，那裡面都是這樣寫的 ：AtomicLong 就是基於自旋 CAS 做的。

但是，朋友，你可以這樣說，但是回答不完美。這題得分別從 JDK 7 和 JDK 8 去答：

JDK 7 的 AtomicLong 是基於自旋 CAS 做的，比如下面這個方法：

while(true) 就是自旋，自旋裏面純粹依賴於 compareAndSet 方法：

這個方法裏面調用的 native 的 comareAndSwapLong 方法，對應的 Lock 前綴指令就是我們前面說到的 cmpxchg。

而在 JDK 8 裏面 AtomicLong 裏面的一些方法也是自旋，但是就不僅僅依賴於 cmpxchg 指令做了，比如還是上面這個方法：

可以看到這裏面還是有一個 do-while 的循環，還是調用的 compareAndSwapLong 方法：

這個方法對應的 Lock 前綴指令是我們前面提到過的 xadd 指令。

從 Java 代碼的角度來看，都是自旋，都是 compareAndSwapLong 方法。沒有什麼差異。

但是從這篇 oracle 官網的文章，我們可以窺見 JDK 8 在 x86 平台上對 compareAndSwapLong 方法做了一些操作，使用了 xadd 彙編指令代替 CAS 操作。

xadd 指令是 fetch and add。

cmpxchg 指令是 compare and swap。

xadd 指令的性能是優於 cmpxchg 指令的。

具體可以看看這篇 oracle 官網的文章：

https://blogs.oracle.com/dave/atomic-fetch-and-add-vs-compare-and-swap

文章下面的評論，可以多注意一下，我截取其中兩個，大家品一品：

然後是這個：

總之就是：這篇文章說的有道理，我們（Dave and Doug）也在思考這個問題。所以我們會在 JIT 上面搞事情，在 x86 平台上把 CAS 操作替換為 LOCK:XADD 指令。

（這個地方我之前理解的有問題，經過朋友的指正後才修改過來。）

所以，JDK 8 之後的 AtomicLong 裏面的方法都是經過改良后， xadd+cmpxchg 雙重加持的方法。

另外需要注意的是，我怕有的朋友懵逼，專門多提一嘴：CAS 是指一次比較並交換的過程，成功了就返回 true，失敗了則返回 false，強調的是一次。而自旋 CAS 是在死循環裏面進行比較並交換，只要不返回 true 就一直循環。

所以，不要一提到 CAS 就說循環時間開銷大。前面記得加上“自旋”和“競爭大”兩個條件。

至於 JDK 8 使用 xadd 彙編指令代替 CAS 操作的是否真的是性能更好了，可以看看這篇 oracle 官網的文章：

https://blogs.oracle.com/dave/atomic-fetch-and-add-vs-compare-and-swap

文章下面的評論，可以多注意一下，我截取其中一個，大家品一品：

經過我們前面的分析，AtomicLong 從 JDK 7 到 JDK 8 是有一定程度上的性能優化的，但是改動並不大。

還是存在一個問題：雖然它可以實現原子性的增減操作，但是當競爭非常大的時候，被操作的這個 value 就是一個熱點數據，所有線程都要去對其進行爭搶，導致併發修改時衝突很大。

所以，歸根到底它的主要問題還是出在共享熱點數據上。

為了解決這個問題，Doug Lea 在 JDK 8 裏面引入了 LongAdder 類。

更加牛逼的LongAdder

大家先看一下官網上的介紹：

上面的截圖一共兩段話，是對 LongAdder 的簡介，我給大家翻譯並解讀一下。

首先第一段：當有多線程競爭的情況下，有個叫做變量集合（set of variables）的東西會動態的增加，以減少競爭。sum() 方法返回的是某個時刻的這些變量的總和。

所以，我們知道了它的返回值，不論是 sum() 方法還是 longValue() 方法，都是那個時刻的，不是一個準確的值。

意思就是你拿到這個值的那一刻，這個值其實已經變了。

這點是非常重要的，為什麼會是這樣呢？

我們對比一下 AtomicLong 和 LongAdder 的自增方法就可以知道了：

AtomicLong 的自增是有返回值的，就是一個這次調用之後的準確的值，這是一個原子性的操作。

LongAdder 的自增是沒有返回值的，你要獲取當前值的時候，只能調用 sum 方法。

你想這個操作：先自增，再獲取值，這就不是原子操作了。

所以，當多線程併發調用的時候，sum 方法返回的值必定不是一個準確的值。除非你加鎖。

該方法上的說明也是這樣的：

至於為什麼不能返回一個準確的值，這就是和它的設計相關了，這點放在後面去說。

然後第二段：當在多線程的情況下對一個共享數據進行更新（寫）操作，比如實現一些統計信息類的需求，LongAdder 的表現比它的老大哥 AtomicLong 表現的更好。在併發不高的時候，兩個類都差不多。但是高併發時 LongAdder 的吞吐量明顯高一點，它也佔用更多的空間。這是一種空間換時間的思想。

這段話其實是接着第一段話在進行描述的。

因為它在多線程併發情況下，沒有一個準確的返回值，所以當你需要根據返回值去搞事情的時候，你就要仔細思考思考，這個返回值你是要精準的，還是大概的統計類的數據就行。

比如說，如果你是用來做序號生成器，所以你需要一個準確的返回值，那麼還是用 AtomicLong 更加合適。

如果你是用來做計數器，這種寫多讀少的場景。比如接口訪問次數的統計類需求，不需要時時刻刻的返回一個準確的值，那就上 LongAdder 吧。

總之，AtomicLong 是可以保證每次都有準確值，而 LongAdder 是可以保證最終數據是準確的。高併發的場景下 LongAdder 的寫性能比 AtomicLong 高。

接下來探討三個問題：

  • LongAdder 是怎麼解決多線程操作熱點 value 導致併發修改衝突很大這個問題的？

  • 為什麼高併發場景下 LongAdder 的 sum 方法不能返回一個準確的值？

  • 為什麼高併發場景下 LongAdder 的寫性能比 AtomicLong 高？

先帶大家看個圖片，看不懂沒有關係，先有個大概的印象：

接下來我們就去探索源碼，源碼之下無秘密。

從源碼我們可以看到 add 方法是關鍵：

裏面有 cells 、base 這樣的變量，所以在解釋 add 方法之前，我們先看一下 這幾個成員變量。

這幾個變量是 Striped64 裏面的。

LongAdder 是 Striped64 的子類：

其中的四個變量如下：

  • NCPU：cpu 的個數，用來決定 cells 數組的大小。

  • cells：一個數組，當不為 null 的時候大小是 2 的次冪。裏面放的是 cell 對象。

  • base : 基數值，當沒有競爭的時候直接把值累加到 base 裏面。還有一個作用就是在 cells 初始化時，由於 cells 只能初始化一次，所以其他競爭初始化操作失敗線程會把值累加到 base 裏面。

  • cellsBusy：當 cells 在擴容或者初始化的時候的鎖標識。

之前，文檔裏面說的 set of variables 就是這裏的 cells。

好了，我們再回到 add 方法裏面：

cells 沒有被初始化過，說明是第一次調用或者競爭不大，導致 CAS 操作每次都是成功的。

casBase 方法就是進行 CAS 操作。

當由於競爭激烈導致 casBase 方法返回了 false 后，進入 if 分支判斷。

這個 if 分子判斷有 4 個條件，做了 3 種情況的判斷

  • 標號為 ① 的地方是再次判斷 cells 數組是否為 null 或者 size 為 0 。as 就是 cells 數組。

  • 標號為 ② 的地方是判斷當前線程對 cells 數組大小取模后的值，在 cells 數組裡面是否能取到 cell 對象。

  • 標號為 ③ 的地方是對取到的 cell 對象進行 CAS 操作是否能成功。

這三個操作的含義為：當 cells 數組裡面有東西，並且通過 getProbe() & m算出來的值，在 cells 數組裡面能取到東西（cell）時，就再次對取到的 cell 對象進行 CAS 操作。

如果不滿足上面的條件，則進入 longAccumulate 函數。

這個方法主要是對 cells 數組進行操作，你想一個數組它可以有三個狀態：未初始化、初始化中、已初始化，所以下面就是對這三種狀態的分別處理：

  • 標號為 ① 的地方是 cells 已經初始化過了，那麼這個裡面可以進行在 cell 裏面累加的操作，或者擴容的操作。

  • 標號為 ② 的地方是 cells 沒有初始化，也還沒有被加鎖，那就對 cellsBusy 標識進行 CAS 操作，嘗試加鎖。加鎖成功了就可以在這裏面進行一些初始化的事情。

  • 標號為 ③ 的地方是 cells 正在進行初始化，這個時候就在 base 基數上進行 CAS 的累加操作。

上面三步是在一個死循環裏面的。

所以如果 cells 還沒有進行初始化，由於有鎖的標誌位，所以就算併發非常大的時候一定只有一個線程去做初始化 cells 的操作，然後對 cells 進行初始化或者擴容的時候，其他線程的值就在 base 上進行累加操作。

上面就是 sum 方法的工作過程。

感受到了嗎，其實這就是一個分段操作的思想，不知道你有沒有想到 ConcurrentHashMap，也不奇怪，畢竟這兩個東西都是 Doug Lea 寫的。

然後再補充說明一下，cells 的初始化大小為 2：

cells 的最大值為 CPU 核數：

cell 是被 Contended 註解修飾了，為了解決偽共享的問題：

說起偽共享，我想起了之前的《一個困擾我122天的技術問題，我好像知道答案了》這篇文章中提到的一個猜想：

後來，我也用這個註解去解決偽共享的問題了，可惜最終的實驗結果表明不是這個原因。

那篇文章發布後有很多朋友給我反饋他們的看法，而更多的是在這條路上發現了更多更多的玄學問題，但是最終這些問題的背後都指向了同一個東西：JIT。

扯遠了，說回本文的這個 LongAdder。

總的來說，就是當沒有衝突的時候 LongAdder 表現的和 AtomicLong 一樣。當有衝突的時候，才是 LongAdder 表現的時候，然後我們再回去看這個圖，就能明白怎麼回事了：

好了，現在我們回到前面提出的三個問題：

  • LongAdder 是怎麼解決多線程操作熱點 value 導致併發修改衝突很大這個問題的？

  • 為什麼高併發場景下 LongAdder 的 sum 方法不能返回一個準確的值？

  • 為什麼高併發場景下 LongAdder 的寫性能比 AtomicLong 高？

它們其實是一個問題。

因為 LongAdder 把熱點 value 拆分了，放到了各個 cell 裏面去操作。這樣就相當於把衝突分散到了 cell 裏面。所以解決了併發修改衝突很大這個問題。

當發生衝突時 sum= base+cells。高併發的情況下當你獲取 sum 的時候，cells 極有可能正在被其他的線程改變。一個在高併發場景下實時變化的值，你要它怎麼給你個準確值？當然，你也可以通過加鎖操作拿到當前的一個準確值，但是這種場景你還用啥 LongAdder，是 AtomicLong 不香了嗎？

為什麼高併發場景下 LongAdder 的寫性能比 AtomicLong 高？

你發動你的小腦殼想一想，朋友。

AtomicLong 不管有沒有衝突，它寫的都是一個共享的 value，有衝突的時候它就在自旋。

LongAdder 沒有衝突的時候表現的和 AtomicLong 一樣，有衝突的時候就把衝突分散到各個 cell 裏面了，衝突分散了，寫的當然更快了。

一點思考

本文的題目是《我從LongAdder中窺探到了高併發的秘籍，上面就寫了兩個字……》。

那麼這兩個字是什麼呢？

就是拆分。我淺顯的覺得分佈式、高併發都是基於拆分思想的。

本文的 LongAdder 就不說了。

微服務化、分庫分表、讀寫分離……這些東西都是在拆分，把集中的壓力分散開來。

我們常常說性能不行了，那就堆機器解決，這就是在做拆分。

當然，拆分了帶來好處的同時也是有一定的問題的。

比如老大難的分佈式事務、數據聚合查詢等需求。

舉一個我遇到過的例子吧。

在寫這篇文章之前，我看了 LongAdder 源碼，了解到它這樣的結構后，知道了它和 AtomicLong 之間的差異后，我想起了之前做過的一個需求。

就是賬戶服務，有個大商戶的賬戶是一個熱點賬戶，交易非常的頻繁。

這個賬戶上的金額就相當於是一個共享的熱點數據。

我們當時的做法是把這個賬戶拆分為多個影子賬戶，這樣就把熱點賬戶拆分成了多個影子賬戶，壓力就分攤了。

其實這個思想和 LongAdder 是一脈相承的。

這個場景下拆分帶來的問題是什麼呢？

其中一個問題就是這個賬戶的總餘額是多個影子賬戶之和，而每個影子賬戶上的餘額是時刻在變化的，所以我們不能保證餘額是一個實時準確的值。

但是商戶不關心這個呀。他只關心上日餘額是準確的，每日對賬都能對上就行了。

我們在滿足需求的同時，性能還上去了。

還有一個簡單的思考是如果我們把“實現原子操作進行加減”這句話當做一個需求。

我個人拙見是這樣的，AtomicLong 類就是實現了這個需求，交付出去后，它能用，能正常工作，而且還附送了一個功能是每次都給你返回一個準確的值。

而 LongAdder 就是更加優雅的實現了這個需求，它是在原有的基礎上進行了迭代開發，功能還是能一樣的實現，沒有附加功能，但是針對某些場景來說，更好用了。

它們傳遞給我的思想不是我們常說的：先上，能跑就行，後期再迭代。

而是：它確實能跑，但是還有更加快，更加優雅的實現方式，我們可以實現它。

這是我們需要學習的地方。

最後說兩句（求關注）

才疏學淺，難免會有紕漏，如果你發現了錯誤的地方，還請你留言指出來，我對其加以修改。

感謝您的閱讀，我堅持原創，十分歡迎並感謝您的關注。

我是 why，一個被代碼耽誤的文學創作者，不是大佬，但是喜歡分享，是一個又暖又有料的四川好男人。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!