http://coderplay.iteye.com/blog/1485760

眾所周知, CPU是計算機(jī)的大腦, 它負(fù)責(zé)執(zhí)行程序的指令; 內(nèi)存負(fù)責(zé)存數(shù)據(jù), 包括程序自身數(shù)據(jù). 同樣大家都知道, 內(nèi)存比CPU慢很多. 其實在30年前, CPU的頻率和內(nèi)存總線的頻率在同一個級別, 訪問內(nèi)存只比訪問CPU寄存器慢一點(diǎn)兒. 由于內(nèi)存的發(fā)展都到技術(shù)及成本的限制, 現(xiàn)在獲取內(nèi)存中的一條數(shù)據(jù)大概需要200多個CPU周期(CPU cycles), 而CPU寄存器一般情況下1個CPU周期就夠了.?

CPU緩存?
網(wǎng)頁瀏覽器為了加快速度,會在本機(jī)存緩存以前瀏覽過的數(shù)據(jù); 傳統(tǒng)數(shù)據(jù)庫或NoSQL數(shù)據(jù)庫為了加速查詢, 常在內(nèi)存設(shè)置一個緩存, 減少對磁盤(慢)的IO. 同樣內(nèi)存與CPU的速度相差太遠(yuǎn), 于是CPU設(shè)計者們就給CPU加上了緩存(CPU Cache). 如果你需要對同一批數(shù)據(jù)操作很多次, 那么把數(shù)據(jù)放至離CPU更近的緩存, 會給程序帶來很大的速度提升. 例如, 做一個循環(huán)計數(shù), 把計數(shù)變量放到緩存里,就不用每次循環(huán)都往內(nèi)存存取數(shù)據(jù)了. 下面是CPU Cache的簡單示意圖.??
?
隨著多核的發(fā)展, CPU Cache分成了三個級別: L1, L2, L3. 級別越小越接近CPU, 所以速度也更快, 同時也代表著容量越小. L1是最接近CPU的, 它容量最小, 例如32K, 速度最快,每個核上都有一個L1 Cache(準(zhǔn)確地說每個核上有兩個L1 Cache, 一個存數(shù)據(jù) L1d Cache, 一個存指令 L1i Cache). L2 Cache 更大一些,例如256K, 速度要慢一些, 一般情況下每個核上都有一個獨(dú)立的L2 Cache; L3 Cache是三級緩存中最大的一級,例如12MB,同時也是最慢的一級, 在同一個CPU插槽之間的核共享一個L3 Cache.?

從CPU到	大約需要的CPU周期	大約需要的時間(單位ns)
寄存器	1 cycle	?
L1 Cache	~3-4 cycles	~0.5-1 ns
L2 Cache	~10-20 cycles	~3-7 ns
L3 Cache	~40-45 cycles	~15 ns
跨槽傳輸	?	~20 ns
內(nèi)存	~120-240 cycles	~60-120ns

感興趣的同學(xué)可以在Linux下面用cat /proc/cpuinfo, 或Ubuntu下lscpu看看自己機(jī)器的緩存情況, 更細(xì)的可以通過以下命令看看:?

Shell代碼??

$?cat?/sys/devices/system/cpu/cpu0/cache/index0/size??

32K??

$?cat?/sys/devices/system/cpu/cpu0/cache/index0/type??

Data??

$?cat?/sys/devices/system/cpu/cpu0/cache/index0/level???

1??

$?cat?/sys/devices/system/cpu/cpu3/cache/index3/level?????

3??

就像數(shù)據(jù)庫cache一樣, 獲取數(shù)據(jù)時首先會在最快的cache中找數(shù)據(jù), 如果沒有命中(Cache miss) 則往下一級找, 直到三層Cache都找不到,那只要向內(nèi)存要數(shù)據(jù)了. 一次次地未命中,代表取數(shù)據(jù)消耗的時間越長.?

緩存行(Cache line) ?
為了高效地存取緩存, 不是簡單隨意地將單條數(shù)據(jù)寫入緩存的.? 緩存是由緩存行組成的, 典型的一行是64字節(jié). 讀者可以通過下面的shell命令,查看cherency_line_size就知道知道機(jī)器的緩存行是多大.?
Shell代碼??

$?cat?/sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size???

64??

CPU存取緩存都是按行為最小單位操作的. 在這兒我將不提及緩存的associativity問題, 將問題簡化一些. 一個Java long型占8字節(jié), 所以從一條緩存行上你可以獲取到8個long型變量. 所以如果你訪問一個long型數(shù)組, 當(dāng)有一個long被加載到cache中, 你將無消耗地加載了另外7個. 所以你可以非常快地遍歷數(shù)組.?

實驗及分析 ?
我們在Java編程時, 如果不注意CPU Cache, 那么將導(dǎo)致程序效率低下. 例如以下程序, 有一個二維long型數(shù)組, 在我的32位筆記本上運(yùn)行時的內(nèi)存分布如圖:?
?
32位機(jī)器中的java的數(shù)組對象頭共占16字節(jié)(詳情見? 鏈接 ), 加上62個long型一行l(wèi)ong數(shù)據(jù)一共占512字節(jié). 所以這個二維數(shù)據(jù)是順序排列的.?
Java代碼??

public?class?L1CacheMiss?{??

????private?static?final?int?RUNS?=?10;??

????private?static?final?int?DIMENSION_1?=?1024?*?1024;??

????private?static?final?int?DIMENSION_2?=?62;??

??

????private?static?long[][]?longs;??

??

????public?static?void?main(String[]?args)?throws?Exception?{??

????????Thread.sleep(10000);??

????????longs?=?new?long[DIMENSION_1][];??

????????for?(int?i?=?0;?i?<?DIMENSION_1;?i++)?{??

????????????longs[i]?=?new?long[DIMENSION_2];??

????????????for?(int?j?=?0;?j?<?DIMENSION_2;?j++)?{??

????????????????longs[i][j]?=?0L;??

????????????}??

????????}??

????????System.out.println("starting....");??

??

????????final?long?start?=?System.nanoTime();??

????????long?sum?=?0L;??

????????for?(int?r?=?0;?r?<?RUNS;?r++)?{??

//??????????for?(int?j?=?0;?j?<?DIMENSION_2;?j++)?{??

//??????????????for?(int?i?=?0;?i?<?DIMENSION_1;?i++)?{??

//??????????????????sum?+=?longs[i][j];??

//??????????????}??

//??????????}??

??

????????????for?(int?i?=?0;?i?<?DIMENSION_1;?i++)?{??

????????????????for?(int?j?=?0;?j?<?DIMENSION_2;?j++)?{??

????????????????????sum?+=?longs[i][j];??

????????????????}??

????????????}??

????????}??

????????System.out.println("duration?=?"?+?(System.nanoTime()?-?start));??

????}??

}??

編譯后運(yùn)行,結(jié)果如下?
Shell代碼??

$?java?L1CacheMiss???

starting....??

duration?=?1460583903??

然后我們將22-26行的注釋取消, 將28-32行注釋, 編譯后再次運(yùn)行,結(jié)果是不是比我們預(yù)想得還糟??
Shell代碼??

$?java?L1CacheMiss???

starting....??

duration?=?22332686898??

前面只花了1.4秒的程序, 只做一行的對調(diào)要運(yùn)行22秒. 從上節(jié)我們可以知道在加載longs[i][j]時, longs[i][j+1]很可能也會被加載至cache中, 所以立即訪問longs[i][j+1]將會命中L1 Cache, 而如果你訪問longs[i+1][j]情況就不一樣了, 這時候很可能會產(chǎn)生 cache miss導(dǎo)致效率低下.?
下面我們用perf來驗證一下,先將快的程序跑一下.?
Shell代碼??

$?perf?stat?-e?L1-dcache-load-misses?java?L1CacheMiss???

starting....??

duration?=?1463011588??

??

?Performance?counter?stats?for?'java?L1CacheMiss':??

??

???????164,625,965?L1-dcache-load-misses?????????????????????????????????????????

??

??????13.273572184?seconds?time?elapsed??

一共164,625,965次L1 cache miss, 再看看慢的程序?
Shell代碼??

$?perf?stat?-e?L1-dcache-load-misses?java?L1CacheMiss???

starting....??

duration?=?21095062165??

??

?Performance?counter?stats?for?'java?L1CacheMiss':??

??

?????1,421,402,322?L1-dcache-load-misses?????????????????????????????????????????

??

??????32.894789436?seconds?time?elapsed??

這回產(chǎn)生了1,421,402,322次 L1-dcache-load-misses, 所以慢多了.?

以上我只是示例了在L1 Cache滿了之后才會發(fā)生的cache miss. 其實cache miss的原因有下面三種:?
1. 第一次訪問數(shù)據(jù), 在cache中根本不存在這條數(shù)據(jù), 所以cache miss, 可以通過prefetch解決.?
2. cache沖突, 需要通過補(bǔ)齊來解決.?
3. 就是我示例的這種, cache滿, 一般情況下我們需要減少操作的數(shù)據(jù)大小, 盡量按數(shù)據(jù)的物理順序訪問數(shù)據(jù).?
具體的信息可以參考 這篇 論文.?

從我的前一篇博文中, 我們知道了CPU緩存及緩存行的概念, 同時用一個例子說明了編寫單線程Java代碼時應(yīng)該注意的問題. 下面我們討論更為復(fù)雜, 而且更符合現(xiàn)實情況的多核編程時將會碰到的問題. 這些問題更容易犯, 連j.u.c包作者Doug Lea大師的JDK代碼里也存在這些問題.?

MESI協(xié)議及RFO請求?
從前一篇我們知道, 典型的CPU微架構(gòu)有3級緩存, 每個核都有自己私有的L1, L2緩存. 那么多線程編程時, 另外一個核的線程想要訪問當(dāng)前核內(nèi)L1, L2 緩存行的數(shù)據(jù), 該怎么辦呢??
有人說可以通過第2個核直接訪問第1個核的緩存行. 這是可行的, 但這種方法不夠快. 跨核訪問需要通過Memory Controller(見上一篇的示意圖), 典型的情況是第2個核經(jīng)常訪問第1個核的這條數(shù)據(jù), 那么每次都有跨核的消耗. 更糟的情況是, 有可能第2個核與第1個核不在一個插槽內(nèi).況且Memory Controller的總線帶寬是有限的, 扛不住這么多數(shù)據(jù)傳輸. 所以, CPU設(shè)計者們更偏向于另一種辦法: 如果第2個核需要這份數(shù)據(jù), 由第1個核直接把數(shù)據(jù)內(nèi)容發(fā)過去, 數(shù)據(jù)只需要傳一次.?

那么什么時候會發(fā)生緩存行的傳輸呢? 答案很簡單: 當(dāng)一個核需要讀取另外一個核的臟緩存行時發(fā)生. 但是前者怎么判斷后者的緩存行已經(jīng)被弄臟(寫)了呢??

下面將詳細(xì)地解答以上問題. 首先我們需要談到一個協(xié)議--MESI協(xié)議(鏈接). 現(xiàn)在主流的處理器都是用它來保證緩存的相干性和內(nèi)存的相干性. M,E,S和I代表使用MESI協(xié)議時緩存行所處的四個狀態(tài):?

• M(修改, Modified): 本地處理器已經(jīng)修改緩存行, 即是臟行, 它的內(nèi)容與內(nèi)存中的內(nèi)容不一樣. 并且此cache只有本地一個拷貝(專有).
• E(專有, Exclusive): 緩存行內(nèi)容和內(nèi)存中的一樣, 而且其它處理器都沒有這行數(shù)據(jù)
• S(共享, Shared): 緩存行內(nèi)容和內(nèi)存中的一樣, 有可能其它處理器也存在此緩存行的拷貝
• I(無效, Invalid): 緩存行失效, 不能使用

?
上圖源自于內(nèi)核開發(fā)者Ulrich Drepper著名的What Every Programmer Should Know About Memory一書( 下載 ), 簡要地展示了緩存行的四種狀態(tài)轉(zhuǎn)換. 不過他的書中沒有說明白這四個狀態(tài)是怎么轉(zhuǎn)換的, 下面我用小段文字來說明一下.?

初始 ?一開始時, 緩存行沒有加載任何數(shù)據(jù), 所以它處于I狀態(tài).?
本地寫(Local Write) 如果本地處理器寫數(shù)據(jù)至處于I狀態(tài)的緩存行, 則緩存行的狀態(tài)變成M.?
本地讀(Local Read) ?如果本地處理器讀取處于I狀態(tài)的緩存行, 很明顯此緩存沒有數(shù)據(jù)給它. 此時分兩種情況: (1)其它處理器的緩存里也沒有此行數(shù)據(jù), 則從內(nèi)存加載數(shù)據(jù)到此緩存行后, 再將它設(shè)成E狀態(tài), 表示只有我一家有這條數(shù)據(jù), 其它處理器都沒有 (2)其它處理器的緩存有此行數(shù)據(jù), 則將此緩存行的狀態(tài)設(shè)為S狀態(tài).?

P.S.如果處于M狀態(tài)的緩存行, 再由本地處理器寫入/讀出, 狀態(tài)是不會改變的.?

遠(yuǎn)程讀(Remote Read) ?假設(shè)我們有兩個處理器c1和c2. 如果c2需要讀另外一個處理器c1的緩存行內(nèi)容, c1需要把它緩存行的內(nèi)容通過內(nèi)存控制器(Memory Controller)發(fā)送給c2, c2接到后將相應(yīng)的緩存行狀態(tài)設(shè)為S. 在設(shè)置之前, 內(nèi)存也得從總線上得到這份數(shù)據(jù)并保存.?

遠(yuǎn)程寫(Remote Write) ?其實確切地說不是遠(yuǎn)程寫, 而是c2得到c1的數(shù)據(jù)后, 不是為了讀, 而是為了寫. 也算是本地寫, 只是c1也擁有這份數(shù)據(jù)的拷貝, 這該怎么辦呢? c2將發(fā)出一個RFO(Request For Owner)請求, 它需要擁有這行數(shù)據(jù)的權(quán)限, 其它處理器的相應(yīng)緩存行設(shè)為I, 除了它自已, 誰不能動這行數(shù)據(jù). 這保證了數(shù)據(jù)的安全, 同時處理RFO請求以及設(shè)置I的過程將給寫操作帶來很大的性能消耗.?

以上只是列舉了一些狀態(tài)轉(zhuǎn)換, 為下文做鋪墊. 如果全部描述,需要非常大量的文字, 大家參考 這張圖 就知道原因了, 可以通過此圖了解MESI協(xié)議更詳細(xì)的信息.?

偽共享 ?
我們從上節(jié)知道, 寫操作的代價很高, 特別當(dāng)需要發(fā)送RFO消息時. 我們編寫程序時, 什么時候會發(fā)生RFO請求呢? 有以下兩種:?
1. 線程的工作從一個處理器移到另一個處理器, 它操作的所有緩存行都需要移到新的處理器上. 此后如果再寫緩存行, 則此緩存行在不同核上有多個拷貝, 需要發(fā)送RFO請求了.?
2. 兩個不同的處理器確實都需要操作相同的緩存行?

由上一篇我們知道, 在Java程序中,數(shù)組的成員在緩存中也是連續(xù)的. 其實從Java對象的相鄰成員變量也會加載到同一緩存行中. 如果多個線程操作不同的成員變量, 但是相同的緩存行, 偽共享(False Sharing)問題就發(fā)生了. 下面引用 Disruptor 項目Lead的 博文 中的示例圖和實驗例子(偷會懶,但會加上更詳細(xì)的profile方法).?
?
一個運(yùn)行在處理器core 1上的線程想要更新變量X的值, 同時另外一個運(yùn)行在處理器core 2上的線程想要更新變量Y的值. 但是, 這兩個頻繁改動的變量都處于同一條緩存行. 兩個線程就會輪番發(fā)送RFO消息, 占得此緩存行的擁有權(quán). 當(dāng)core 1取得了擁有權(quán)開始更新X, 則core 2對應(yīng)的緩存行需要設(shè)為I狀態(tài). 當(dāng)core 2取得了擁有權(quán)開始更新Y, 則core 1對應(yīng)的緩存行需要設(shè)為I狀態(tài)(失效態(tài)). 輪番奪取擁有權(quán)不但帶來大量的RFO消息, 而且如果某個線程需要讀此行數(shù)據(jù)時, L1和L2緩存上都是失效數(shù)據(jù), 只有L3緩存上是同步好的數(shù)據(jù).從 前一篇 我們知道, 讀L3的數(shù)據(jù)非常影響性能. 更壞的情況是跨槽讀取, L3都要miss,只能從內(nèi)存上加載.?
表面上X和Y都是被獨(dú)立線程操作的, 而且兩操作之間也沒有任何關(guān)系.只不過它們共享了一個緩存行, 但所有競爭沖突都是來源于共享.?

實驗及分析 ?
引用Martin的例子, 稍做修改,代碼如下:?
Java代碼??

public?final?class?FalseSharing?implements?Runnable?{??

????public?static?int?NUM_THREADS?=?4;?//?change??

????public?final?static?long?ITERATIONS?=?500L?*?1000L?*?1000L;??

????private?final?int?arrayIndex;??

????private?static?VolatileLong[]?longs;??

??

????public?FalseSharing(final?int?arrayIndex)?{??

????????this.arrayIndex?=?arrayIndex;??

????}??

??

????public?static?void?main(final?String[]?args)?throws?Exception?{??

????????Thread.sleep(10000);??

????????System.out.println("starting....");??

????????if?(args.length?==?1)?{??

????????????NUM_THREADS?=?Integer.parseInt(args[0]);??

????????}??

??

????????longs?=?new?VolatileLong[NUM_THREADS];??

????????for?(int?i?=?0;?i?<?longs.length;?i++)?{??

????????????longs[i]?=?new?VolatileLong();??

????????}??

????????final?long?start?=?System.nanoTime();??

????????runTest();??

????????System.out.println("duration?=?"?+?(System.nanoTime()?-?start));??

????}??

??

????private?static?void?runTest()?throws?InterruptedException?{??

????????Thread[]?threads?=?new?Thread[NUM_THREADS];??

????????for?(int?i?=?0;?i?<?threads.length;?i++)?{??

????????????threads[i]?=?new?Thread(new?FalseSharing(i));??

????????}??

????????for?(Thread?t?:?threads)?{??

????????????t.start();??

????????}??

????????for?(Thread?t?:?threads)?{??

????????????t.join();??

????????}??

????}??

??

????public?void?run()?{??

????????long?i?=?ITERATIONS?+?1;??

????????while?(0?!=?--i)?{??

????????????longs[arrayIndex].value?=?i;??

????????}??

????}??

??

????public?final?static?class?VolatileLong?{??

????????public?volatile?long?value?=?0L;??

????????public?long?p1,?p2,?p3,?p4,?p5,?p6;?//?注釋??

????}??

}??

代碼的邏輯是默認(rèn)4個線程修改一數(shù)組不同元素的內(nèi)容.? 元素的類型是VolatileLong, 只有一個長整型成員value和6個沒用到的長整型成員. value設(shè)為volatile是為了讓value的修改所有線程都可見. 在一臺Westmere(Xeon E5620 8core*2)機(jī)器上跑一下看?
Shell代碼??

$?java?FalseSharing??

starting....??

duration?=?9316356836??

把以上代碼49行注釋掉, 看看結(jié)果:?
Shell代碼??

$?java?FalseSharing??

starting....??

duration?=?59791968514??

兩個邏輯一模一樣的程序, 前者只需要9秒, 后者跑了將近一分鐘, 這太不可思議了! 我們用偽共享(False Sharing)的理論來分析一下. 后面的那個程序longs數(shù)組的4個元素,由于VolatileLong只有1個長整型成員, 所以整個數(shù)組都將被加載至同一緩存行, 但有4個線程同時操作這條緩存行, 于是偽共享就悄悄地發(fā)生了. 讀者可以測試一下2,4,8, 16個線程分別操作時分別是什么效果, 什么樣的趨勢.?

那么怎么避免偽共享呢? 我們未注釋的代碼就告訴了我們方法. 我們知道一條緩存行有64字節(jié), 而Java程序的對象頭固定占8字節(jié)(32位系統(tǒng))或12字節(jié)(64位系統(tǒng)默認(rèn)開啟壓縮, 不開壓縮為16字節(jié)), 詳情見? 鏈接 . 我們只需要填6個無用的長整型補(bǔ)上6*8=48字節(jié), 讓不同的VolatileLong對象處于不同的緩存行, 就可以避免偽共享了(64位系統(tǒng)超過緩存行的64字節(jié)也無所謂,只要保證不同線程不要操作同一緩存行就可以). 這個辦法叫做補(bǔ)齊(Padding).?

如何從系統(tǒng)層面觀察到這種優(yōu)化是切實有效的呢? 很可惜, 由于很多計算機(jī)的微架構(gòu)不同, 我們沒有工具來直接探測偽共享事件(包括Intel Vtune和Valgrind). 所有的工具都是從側(cè)面來發(fā)現(xiàn)的, 下面通過Linux利器 OProfile 來證明一下. 上面的程序的數(shù)組只是占64 * 4 = 256字節(jié), 而且在連續(xù)的物理空間, 照理來說數(shù)據(jù)會在L1緩存上就命中, 肯定不會傳入到L2緩存中, 只有在偽共享發(fā)生時才會出現(xiàn). 于是, 我們可以通過觀察L2緩存的IN事件就可以證明了,步驟如下:?
Shell代碼??

#?設(shè)置捕捉L2緩存IN事件??

$?sudo??opcontrol?--setup?--event=L2_LINES_IN:100000??

#?清空工作區(qū)??

$?sudo?opcontrol?--reset??

#?開始捕捉??

$?sudo?opcontrol?--start??

#?運(yùn)行程序??

$?java?FalseSharing??

#?程序跑完后,?dump捕捉到的數(shù)據(jù)??

$?sudo?opcontrol?--dump??

#?停止捕捉??

$?sudo?opcontrol?-h??

#?報告結(jié)果??

$?opreport?-l?`which?java`??

比較一下兩個版本的結(jié)果, 慢的版本:?
Shell代碼??

$?opreport?-l?`which?java`??

CPU:?Intel?Westmere?microarchitecture,?speed?2400.2?MHz?(estimated)??

Counted?L2_LINES_IN?events?(L2?lines?alloacated)?with?a?unit?mask?of?0x07?(any?L2?lines?alloacated)?count?100000??

samples??%????????image?name???????????????symbol?name??

34085????99.8447??anon?(tgid:18051?range:0x7fcdee53d000-0x7fcdee7ad000)?anon?(tgid:18051?range:0x7fcdee53d000-0x7fcdee7ad000)??

51????????0.1494??anon?(tgid:16054?range:0x7fa485722000-0x7fa485992000)?anon?(tgid:16054?range:0x7fa485722000-0x7fa485992000)??

2?????????0.0059??anon?(tgid:2753?range:0x7f43b317e000-0x7f43b375e000)?anon?(tgid:2753?range:0x7f43b317e000-0x7f43b375e000)??

快的版本:?
Shell代碼??

$?opreport?-l?`which?java`??

CPU:?Intel?Westmere?microarchitecture,?speed?2400.2?MHz?(estimated)??

Counted?L2_LINES_IN?events?(L2?lines?alloacated)?with?a?unit?mask?of?0x07?(any?L2?lines?alloacated)?count?100000??

samples??%????????image?name???????????????symbol?name??

22???????88.0000??anon?(tgid:18873?range:0x7f3e3fa8a000-0x7f3e3fcfa000)?anon?(tgid:18873?range:0x7f3e3fa8a000-0x7f3e3fcfa000)??

3????????12.0000??anon?(tgid:2753?range:0x7f43b317e000-0x7f43b375e000)?anon?(tgid:2753?range:0x7f43b317e000-0x7f43b375e000)??

慢的版本由于False Sharing引發(fā)的L2緩存IN事件達(dá)34085次, 而快版本的為0次.?

總結(jié) ?
偽共享在多核編程中很容易發(fā)生, 而且比較隱蔽. 例如, 在JDK的LinkedBlockingQueue中, 存在指向隊列頭的引用head和指向隊列尾的引用last. 而這種隊列經(jīng)常在異步編程中使有,這兩個引用的值經(jīng)常的被不同的線程修改, 但它們卻很可能在同一個緩存行, 于是就產(chǎn)生了偽共享. 線程越多, 核越多,對性能產(chǎn)生的負(fù)面效果就越大.?
某些Java編譯器會將沒有使用到的補(bǔ)齊數(shù)據(jù), 即示例代碼中的6個長整型在編譯時優(yōu)化掉, 可以在程序中加入一些代碼防止被編譯優(yōu)化.?
Java代碼??

public?static?long?preventFromOptimization(VolatileLong?v)?{??

????return?v.p1?+?v.p2?+?v.p3?+?v.p4?+?v.p5?+?v.p6;??

}??

另外, 由于Java的GC問題. 數(shù)據(jù)在內(nèi)存和對應(yīng)的CPU緩存行的位置有可能發(fā)生變化, 所以在使用pad的時候應(yīng)該注意GC的影響.?

小結(jié)：

如果兩個核上的線程處理的不是同一緩存行，那么每個核上的L1,L2都會緩存自己要處理的部分

如果處理的是同一緩存行，為了加快速度，一個核會將另外一個核上的L1上的緩存行拷貝到自己的緩存行中，但是又發(fā)現(xiàn)拷貝過來的數(shù)據(jù)已經(jīng)成為了臟數(shù)據(jù)，那么又要從內(nèi)存中重新讀入

最后感謝同事撒迦,?長仁在Java對象內(nèi)存布局及Profile工具上給予的幫助.?

2012年4月19日更新:?
發(fā)現(xiàn)netty和grizzly的代碼中的LinkedTransferQueue中都使用了PaddedAtomicReference<QNode>來代替原來的Node, 使用了補(bǔ)齊的辦法解決了隊列偽共享的問題. 不知道是不是JSR-166的人開發(fā)的, 看來他們早就意識到這個問題了. 但是從Doug Lea JSR-166的cvs看不到這個變化, 不知道究竟是誰改的? 他們的repository到底是在哪??

2012年5月19日更新:?
為了區(qū)別Cache Coherence和Cache Consistency兩個概念, 不讓讀者混淆, 這里把Cache Coherence改翻譯成緩存相干性.?

總結(jié)

以上是生活随笔為你收集整理的从Java视角理解CPU缓存(CPU Cache)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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