一，使用數(shù)組存儲

二，緩存行優(yōu)勢&偽共享

三，內(nèi)存屏障

參考文章：https://ifeve.com/dissecting-disruptor-whats-so-special/

一，使用數(shù)組存儲

之所以ringbuffer采用這種數(shù)據(jù)結(jié)構(gòu)，是因為它在可靠消息傳遞方面有很好的性能。這就夠了，不過它還有一些其他的優(yōu)點。

首先，因為它是數(shù)組，所以要比鏈表快，而且有一個容易預(yù)測的訪問模式。（譯者注：數(shù)組內(nèi)元素的內(nèi)存地址的連續(xù)性存儲的）。這是對CPU緩存友好的—也就是說，在硬件級別，數(shù)組中的元素是會被預(yù)加載的，因此在ringbuffer當(dāng)中，cpu無需時不時去主存加載數(shù)組中的下一個元素。（校對注：因為只要一個元素被加載到緩存行，其他相鄰的幾個元素也會被加載進同一個緩存行）

其次，你可以為數(shù)組預(yù)先分配內(nèi)存，使得數(shù)組對象一直存在（除非程序終止）。這就意味著不需要花大量的時間用于垃圾回收。此外，不像鏈表那樣，需要為每一個添加到其上面的對象創(chuàng)造節(jié)點對象—對應(yīng)的，當(dāng)刪除節(jié)點時，需要執(zhí)行相應(yīng)的內(nèi)存清理操作。

在本文中并沒有介紹如何避免ringbuffer產(chǎn)生重疊，以及如何對ringbuffer進行讀寫操作。你可能注意到了我將ringbuffer和鏈表那樣的數(shù)據(jù)結(jié)構(gòu)進行比較，因為我并不認為鏈表是實際問題的標準答案。

當(dāng)你將Disruptor和基于 隊列之類的實現(xiàn)進行比較時，事情將變得很有趣。隊列通常注重維護隊列的頭尾元素，添加和刪除元素等。所有的這些我都沒有在ringbuffer里提到，這是因為ringbuffer不負責(zé)這些事情，我們把這些操作都移到了數(shù)據(jù)結(jié)構(gòu)（ringbuffer）的外部。

二，緩存行優(yōu)勢&偽共享

計算機基礎(chǔ)

CPU是你機器的心臟，最終由它來執(zhí)行所有運算和程序。主內(nèi)存（RAM）是你的數(shù)據(jù)（包括代碼行）存放的地方。本文將忽略硬件驅(qū)動和網(wǎng)絡(luò)之類的東西，因為Disruptor的目標是盡可能多的在內(nèi)存中運行。

CPU和主內(nèi)存之間有好幾層緩存，因為即使直接訪問主內(nèi)存也是非常慢的。如果你正在多次對一塊數(shù)據(jù)做相同的運算，那么在執(zhí)行運算的時候把它加載到離CPU很近的地方就有意義了（比如一個循環(huán)計數(shù)－你不想每次循環(huán)都跑到主內(nèi)存去取這個數(shù)據(jù)來增長它吧）。

越靠近CPU的緩存越快也越小。所以L1緩存很小但很快(譯注：L1表示一級緩存)，并且緊靠著在使用它的CPU內(nèi)核。L2大一些，也慢一些，并且仍然只能被一個單獨的 CPU 核使用。L3在現(xiàn)代多核機器中更普遍，仍然更大，更慢，并且被單個插槽上的所有CPU 核共享。最后，你擁有一塊主存，由全部插槽上的所有 CPU 核共享。

當(dāng)CPU執(zhí)行運算的時候，它先去L1查找所需的數(shù)據(jù)，再去L2，然后是L3，最后如果這些緩存中都沒有，所需的數(shù)據(jù)就要去主內(nèi)存拿。走得越遠，運算耗費的時間就越長。所以如果你在做一些很頻繁的事，你要確保數(shù)據(jù)在L1緩存中。

Martin和Mike的QCon presentation演講中給出了一些緩存未命中的消耗數(shù)據(jù)：

從CPU到	大約需要的 CPU 周期	大約需要的時間
主存		約60-80納秒
QPI 總線傳輸 (between sockets, not drawn)		約20ns
L3 cache	約40-45 cycles,	約15ns
L2 cache	約10 cycles,	約3ns
L1 cache	約3-4 cycles,	約1ns
寄存器	1 cycle

如果你的目標是讓端到端的延遲只有 10毫秒，而其中花80納秒去主存拿一些未命中數(shù)據(jù)的過程將占很重的一塊。

緩存行

現(xiàn)在需要注意一件有趣的事情，數(shù)據(jù)在緩存中不是以獨立的項來存儲的，如不是一個單獨的變量，也不是一個單獨的指針。緩存是由緩存行組成的，通常是64字節(jié)（譯注：這篇文章發(fā)表時常用處理器的緩存行是64字節(jié)的，比較舊的處理器緩存行是32字節(jié)），并且它有效地引用主內(nèi)存中的一塊地址。一個Java的long類型是8字節(jié)，因此在一個緩存行中可以存8個long類型的變量。

(為了簡化，我將忽略多級緩存)

非常奇妙的是如果你訪問一個long數(shù)組，當(dāng)數(shù)組中的一個值被加載到緩存中，它會額外加載另外7個。因此你能非常快地遍歷這個數(shù)組。事實上，你可以非常快速的遍歷在連續(xù)的內(nèi)存塊中分配的任意數(shù)據(jù)結(jié)構(gòu)。我在第一篇關(guān)于ring buffer的文章中順便提到過這個，它解釋了我們的ring buffer使用數(shù)組的原因。

因此如果你數(shù)據(jù)結(jié)構(gòu)中的項在內(nèi)存中不是彼此相鄰的（鏈表，我正在關(guān)注你呢），你將得不到免費緩存加載所帶來的優(yōu)勢。并且在這些數(shù)據(jù)結(jié)構(gòu)中的每一個項都可能會出現(xiàn)緩存未命中。

不過，所有這種免費加載有一個弊端。設(shè)想你的long類型的數(shù)據(jù)不是數(shù)組的一部分。設(shè)想它只是一個單獨的變量。讓我們稱它為head，這么稱呼它其實沒有什么原因。然后再設(shè)想在你的類中有另一個變量緊挨著它。讓我們直接稱它為tail。現(xiàn)在，當(dāng)你加載head到緩存的時候，你也免費加載了tail。

聽想來不錯。直到你意識到tail正在被你的生產(chǎn)者寫入，而head正在被你的消費者寫入。這兩個變量實際上并不是密切相關(guān)的，而事實上卻要被兩個不同內(nèi)核中運行的線程所使用。

設(shè)想你的消費者更新了head的值。緩存中的值和內(nèi)存中的值都被更新了，而其他所有存儲head的緩存行都會都會失效，因為其它緩存中head不是最新值了。請記住我們必須以整個緩存行作為單位來處理（譯注：這是CPU的實現(xiàn)所規(guī)定的，詳細可參見深入分析Volatile的實現(xiàn)原理），不能只把head標記為無效。

現(xiàn)在如果一些正在其他內(nèi)核中運行的進程只是想讀tail的值，整個緩存行需要從主內(nèi)存重新讀取。那么一個和你的消費者無關(guān)的線程讀一個和head無關(guān)的值，它被緩存未命中給拖慢了。

當(dāng)然如果兩個獨立的線程同時寫兩個不同的值會更糟。因為每次線程對緩存行進行寫操作時，每個內(nèi)核都要把另一個內(nèi)核上的緩存塊無效掉并重新讀取里面的數(shù)據(jù)。你基本上是遇到兩個線程之間的寫沖突了，盡管它們寫入的是不同的變量。

這叫作“偽共享”（譯注：可以理解為錯誤的共享），因為每次你訪問head你也會得到tail，而且每次你訪問tail，你也會得到head。這一切都在后臺發(fā)生，并且沒有任何編譯警告會告訴你，你正在寫一個并發(fā)訪問效率很低的代碼。

解決方案－神奇的緩存行填充

你會看到Disruptor消除這個問題，至少對于緩存行大小是64字節(jié)或更少的處理器架構(gòu)來說是這樣的（譯注：有可能處理器的緩存行是128字節(jié)，那么使用64字節(jié)填充還是會存在偽共享問題），通過增加補全來確保ring buffer的序列號不會和其他東西同時存在于一個緩存行中。

1	publiclongp1, p2, p3, p4, p5, p6, p7;// cache line padding

2	privatevolatilelongcursor = INITIAL_CURSOR_VALUE;

3	publiclongp8, p9, p10, p11, p12, p13, p14;// cache line padding

因此沒有偽共享，就沒有和其它任何變量的意外沖突，沒有不必要的緩存未命中。

在你的Entry類中也值得這樣做，如果你有不同的消費者往不同的字段寫入，你需要確保各個字段間不會出現(xiàn)偽共享。

修改：Martin寫了一個從技術(shù)上來說更準確更詳細的關(guān)于偽共享的文章，并且發(fā)布了性能測試結(jié)果。

三，內(nèi)存屏障

什么是內(nèi)存屏障？

它是一個CPU指令。沒錯，又一次，我們在討論CPU級別的東西，以便獲得我們想要的性能（Martin著名的Mechanical Sympathy理論）。基本上，它是這樣一條指令： a)確保一些特定操作執(zhí)行的順序； b)影響一些數(shù)據(jù)的可見性(可能是某些指令執(zhí)行后的結(jié)果)。

編譯器和CPU可以在保證輸出結(jié)果一樣的情況下對指令重排序，使性能得到優(yōu)化。插入一個內(nèi)存屏障，相當(dāng)于告訴CPU和編譯器先于這個命令的必須先執(zhí)行，后于這個命令的必須后執(zhí)行。正如去拉斯維加斯旅途中各個站點的先后順序在你心中都一清二楚。

內(nèi)存屏障另一個作用是強制更新一次不同CPU的緩存。例如，一個寫屏障會把這個屏障前寫入的數(shù)據(jù)刷新到緩存，這樣任何試圖讀取該數(shù)據(jù)的線程將得到最新值，而不用考慮到底是被哪個cpu核心或者哪顆CPU執(zhí)行的。

和Java有什么關(guān)系？

現(xiàn)在我知道你在想什么——這不是匯編程序。它是Java。

這里有個神奇咒語叫volatile(我覺得這個詞在Java規(guī)范中從未被解釋清楚)。如果你的字段是volatile，Java內(nèi)存模型將在寫操作后插入一個寫屏障指令，在讀操作前插入一個讀屏障指令。

這意味著如果你對一個volatile字段進行寫操作，你必須知道：

1、一旦你完成寫入，任何訪問這個字段的線程將會得到最新的值。

2、在你寫入前，會保證所有之前發(fā)生的事已經(jīng)發(fā)生，并且任何更新過的數(shù)據(jù)值也是可見的，因為內(nèi)存屏障會把之前的寫入值都刷新到緩存。

舉個例子唄！

很高興你這樣說了。又是時候讓我來畫幾個甜甜圈了。

RingBuffer的指針(cursor)（譯注：指向隊尾元素）屬于一個神奇的volatile變量，同時也是我們能夠不用鎖操作就能實現(xiàn)Disruptor的原因之一。

生產(chǎn)者將會取得下一個Entry（或者是一批）,并可對它（們）作任意改動， 把它（們）更新為任何想要的值。如你所知，在所有改動都完成后，生產(chǎn)者對ring buffer調(diào)用commit方法來更新序列號（譯注:把cursor更新為該Entry的序列號）。對volatile字段(cursor)的寫操作創(chuàng)建了一個內(nèi)存屏障，這個屏障將刷新所有緩存里的值（或者至少相應(yīng)地使得緩存失效）。

這時候，消費者們能獲得最新的序列號碼(8)，并且因為內(nèi)存屏障保證了它之前執(zhí)行的指令的順序，消費者們可以確信生產(chǎn)者對7號Entry所作的改動已經(jīng)可用。

…那么消費者那邊會發(fā)生什么？

消費者中的序列號是volatile類型的，會被若干個外部對象讀取——其他的下游消費者可能在跟蹤這個消費者。ProducerBarrier/RingBuffer(取決于你看的是舊的還是新的代碼)跟蹤它以確保環(huán)沒有出現(xiàn)重疊（wrap）的情況（譯注：為了防止下游的消費者和上游的消費者對同一個Entry競爭消費，導(dǎo)致在環(huán)形隊列中互相覆蓋數(shù)據(jù)，下游消費者要對上游消費者的消費情況進行跟蹤）。

所以，如果你的下游消費者(C2)看見前一個消費者(C1)在消費號碼為12的Entry，當(dāng)C2的讀取也到了12，它在更新序列號前將可以獲得C1對該Entry的所作的更新。

基本來說就是，C1更新序列號前對ring buffer的所有操作（如上圖黑色所示），必須先發(fā)生，待C2拿到C1更新過的序列號之后，C2才可以為所欲為（如上圖藍色所示）。

對性能的影響

內(nèi)存屏障作為另一個CPU級的指令，沒有鎖那樣大的開銷。內(nèi)核并沒有在多個線程間干涉和調(diào)度。但凡事都是有代價的。內(nèi)存屏障的確是有開銷的——編譯器/cpu不能重排序指令，導(dǎo)致不可以盡可能地高效利用CPU，另外刷新緩存亦會有開銷。所以不要以為用volatile代替鎖操作就一點事都沒。

你會注意到Disruptor的實現(xiàn)對序列號的讀寫頻率盡量降到最低。對volatile字段的每次讀或?qū)懚际窍鄬Ω叱杀镜牟僮鳌５牵矐?yīng)該認識到在批量的情況下可以獲得很好的表現(xiàn)。如果你知道不應(yīng)對序列號頻繁讀寫，那么很合理的想到，先獲得一整批Entries,并在更新序列號前處理它們。這個技巧對生產(chǎn)者和消費者都適用。以下的例子來自BatchConsumer:

01	longnextSequence = sequence +1;

02	while(running)

03

{

04

try

05

{

06	finallongavailableSequence = consumerBarrier.waitFor(nextSequence);

07	while(nextSequence <= availableSequence)

08

{

09	entry = consumerBarrier.getEntry(nextSequence);

10	handler.onAvailable(entry);

11	nextSequence++;

12

}

13	handler.onEndOfBatch();

14	sequence = entry.getSequence();

15

}

16

…

17	catch(finalException ex)

18

{

19	exceptionHandler.handle(ex, entry);

20	sequence = entry.getSequence();

21	nextSequence = entry.getSequence() +1;

22

}

23

}

（你會注意到，這是個舊式的代碼和命名習(xí)慣，因為這是摘自我以前的博客文章，我認為如果直接轉(zhuǎn)換為新式的代碼和命名習(xí)慣會讓人有點混亂）

在上面的代碼中，我們在消費者處理entries的循環(huán)中用一個局部變量（nextSequence）來遞增。這表明我們想盡可能地減少對volatile類型的序列號的進行讀寫。

總結(jié)

內(nèi)存屏障是CPU指令，它允許你對數(shù)據(jù)什么時候?qū)ζ渌M程可見作出假設(shè)。在Java里，你使用volatile關(guān)鍵字來實現(xiàn)內(nèi)存屏障。使用volatile意味著你不用被迫選擇加鎖，并且還能讓你獲得性能的提升。

但是，你需要對你的設(shè)計進行一些更細致的思考，特別是你對volatile字段的使用有多頻繁，以及對它們的讀寫有多頻繁。

總結(jié)

以上是生活随笔為你收集整理的深扒Disruptor高性能的原因的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。