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

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

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

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

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

因此，對在學(xué)校學(xué)過的人是種復(fù)習(xí)，對未學(xué)過的人是個簡單介紹。但是請注意，這篇文章包含了大量的過度簡化。

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

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

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

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

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

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

緩存行

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

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

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

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

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

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

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

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

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

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

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)者往不同的字段寫入，你需要確保各個字段間不會出現(xiàn)偽共享。

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

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

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