我們經(jīng)常提到一個(gè)短語(yǔ)Mechanical Sympathy，這個(gè)短語(yǔ)也是Martin博客的標(biāo)題（譯注：Martin Thompson），Mechanical Sympathy講的是底層硬件是如何運(yùn)作的，以及與其協(xié)作而非相悖的編程方式。（注解：sympathy這里是共鳴、一致的含義）

我在上一篇文章中提到RingBuffer后，我們收到一些關(guān)于RingBuffer中填充高速緩存行的評(píng)論和疑問。由于這個(gè)適合用漂亮的圖片來(lái)說(shuō)明，所以我想這是下一個(gè)我該解決的問題了。

（譯注：Martin Thompson很喜歡用Mechanical Sympathy這個(gè)短語(yǔ)，這個(gè)短語(yǔ)源于賽車駕駛,它反映了駕駛員對(duì)于汽車有一種天生的感覺，所以他們對(duì)于如何最佳的駕御它非常有感覺。）

計(jì)算機(jī)入門

我喜歡在LMAX工作的原因之一是，在這里工作讓我明白從大學(xué)和A Level Computing所學(xué)的東西實(shí)際上還是有意義的。做為一個(gè)開發(fā)者你可以逃避不去了解CPU，數(shù)據(jù)結(jié)構(gòu)或者大O符號(hào) —— 而我用了10年的職業(yè)生涯來(lái)忘記這些東西。但是現(xiàn)在看來(lái)，如果你知道這些知識(shí)并應(yīng)用它，你能寫出一些非常巧妙和非常快速的代碼。

因此，對(duì)在學(xué)校學(xué)過(guò)的人是種復(fù)習(xí)，對(duì)未學(xué)過(guò)的人是個(gè)簡(jiǎn)單介紹。但是請(qǐng)注意，這篇文章包含了大量的過(guò)度簡(jiǎn)化。

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

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

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

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

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

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

緩存行

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

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

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

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

設(shè)想你的消費(fèi)者更新了head的值。緩存中的值和內(nèi)存中的值都被更新了，而其他所有存儲(chǔ)head的緩存行都會(huì)都會(huì)失效，因?yàn)槠渌彺嬷?code>head不是最新值了。請(qǐng)記住我們必須以整個(gè)緩存行作為單位來(lái)處理（譯注：這是CPU的實(shí)現(xiàn)所規(guī)定的，詳細(xì)可參見深入分析Volatile的實(shí)現(xiàn)原理），不能只把head標(biāo)記為無(wú)效。

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

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

這叫作“偽共享”（譯注：可以理解為錯(cuò)誤的共享），因?yàn)槊看文阍L問head你也會(huì)得到tail，而且每次你訪問tail，你也會(huì)得到head。這一切都在后臺(tái)發(fā)生，并且沒有任何編譯警告會(huì)告訴你，你正在寫一個(gè)并發(fā)訪問效率很低的代碼。

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

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

public long p1, p2, p3, p4, p5, p6, p7; // cache line padding 
    private volatile long cursor = INITIAL_CURSOR_VALUE; 
    public long p8, p9, p10, p11, p12, p13, p14; // cache line padding 

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

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

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

原文鏈接：http://ifeve.com/disruptor-padding/

譯文鏈接：http://ifeve.com/disruptor-cacheline-padding/