作者 Dennis Byrne 譯者 崔康 發佈於 2010年4月21日 上午1時10分
社區Java主題性能和可伸縮性標籤併發,HotSpot,JVM
分享 | 內存屏障，又稱內存柵欄，是一組處理器指令，用於實現對內存操作的順序限制。本文介紹了內存屏障對多線程程序的影響。我們將研究內存屏障與JVM併發機制 的關係，如易變量（volatile）、同步（synchronized）和原子條件式（atomic conditional）。本文假定讀者已經充分掌握了相關概念和Java內存模型，不討論併發互斥、並行機制和原子性。內存屏障用來實現併發編程中稱爲 可見性（visibility）的同樣重要的作用。
感謝Brian Goetz 和 Eric Yew 審校本文，同時感謝Christian Thalinger提供訪問SPARC硬件的支持。
內存屏障爲何重要？
對主存的一次訪問一般花費硬件的數百次時鐘週期。處理器通過緩存（caching）能夠從數量級上降低內存延遲的成本這些緩存爲了性能重新排列待定內存操 作的順序。也就是說，程序的讀寫操作不一定會按照它要求處理器的順序執行。當數據是不可變的，同時/或者數據限制在線程範圍內，這些優化是無害的。如果把 這些優化與對稱多處理（symmetric multi-processing）和共享可變狀態（shared mutable state）結合，那麼就是一場噩夢。當基於共享可變狀態的內存操作被重新排序時，程序可能行爲不定。一個線程寫入的數據可能被其他線程可見，原因是數據 寫入的順序不一致。適當的放置內存屏障通過強制處理器順序執行待定的內存操作來避免這個問題。
內存屏障的協調作用
內存屏障不直接由JVM暴露，相反它們被JVM插入到指令序列中以維持語言層併發原語的語義。我們研究幾個簡單Java程序的源代碼和彙編指令。首先快速 看一下Dekker算法中的內存屏障。該算法利用volatile變量協調兩個線程之間的共享資源訪問。
請不要關注該算法的出色細節。哪些部分是相關的？每個線程通過發信號試圖進入代碼第一行的關鍵區域。如果線程在第三行意識到衝突（兩個線程都要訪問），通 過turn變量的操作來解決。在任何時刻只有一個線程可以訪問關鍵區域。
// code run by first thread // code run by second thread
1 intentFirst = true; intentSecond = true;
2
3 while (intentSecond) while (intentFirst) // volatile read
4 if (turn != 0) { if (turn != 1) { // volatile read
5 intentFirst = false; intentSecond = false;
6 while (turn != 0) {} while (turn != 1) {}
7 intentFirst = true; intentSecond = true;
8 } }
9
10 criticalSection(); criticalSection();
11
12 turn = 1; turn = 0; // volatile write
13 intentFirst = false; intentSecond = false; // volatile write
硬件優化可以在沒有內存屏障的情況下打亂這段代碼，即使編譯器按照程序員的想法順序列出所有的內存操作。考慮第三、四行的兩次順序volatile讀操 作。每一個線程檢查其他線程是否發信號想進入關鍵區域，然後檢查輪到誰操作了。考慮第12、13行的兩次順序寫操作。每一個線程把訪問權釋放給其他線程， 然後撤銷自己訪問關鍵區域的意圖。讀線程應該從不期望在其他線程撤銷訪問意願後觀察到其他線程對turn變量的寫操作。這是個災難。但是如果這些變量沒有 volatile修飾符，這的確會發生！例如，沒有volatile修飾符，第二個線程在第一個線程對turn執行寫操作（倒數第二行）之前可能會觀察到 第一個線程對intentFirst(倒數第一行)的寫操作。關鍵詞volatile避免了這種情況，因爲它在對turn變量的寫操作和對 intentFirst變量的寫操作之間創建了一個先後關係。編譯器無法重新排序這些寫操作，如果必要，它會利用一個內存屏障禁止處理器重排序。讓我們來 看看一些實現細節。
PrintAssembly HotSpot選項是JVM的一個診斷標誌，允許我們獲取JIT編譯器生成的彙編指令。這需要最新的OpenJDK版本或者新HotSpot update14或者更高版本。通過需要一個反編譯插件。Kenai項目提供了用於Solaris、Linux和BSD的插件二進制文件。hsdis是另 一款可以在Windows通過源碼構建的插件。
兩次順序讀操作的第一次（第三行）的彙編指令如下。指令流基於Itanium 2多處理硬件、JDK 1.6 update 17。本文的所有指令流都在左手邊以行號標記。相關的讀操作、寫操作和內存屏障指令都以粗體標記。建議讀者不要沉迷於每一行指令。
1 0x2000000001de819c: adds r37=597,r36;; ;...84112554 2 0x2000000001de81a0: ld1.acq r38=[r37];; ;...0b30014a a010 3 0x2000000001de81a6: nop.m 0x0 ;...00000002 00c0 4 0x2000000001de81ac: sxt1 r38=r38;; ;...00513004 5 0x2000000001de81b0: cmp4.eq p0,p6=0,r38 ;...1100004c 8639 6 0x2000000001de81b6: nop.i 0x0 ;...00000002 0003 7 0x2000000001de81bc: br.cond.dpnt.many 0x2000000001de8220;;
簡短的指令流其實內容豐富。第一次volatile位於第二行。Java內存模型確保了JVM會在第二次讀操作之前將第一次讀操作交給處理器，也就是按照 “程序的順序”——但是這單單一行指令是不夠的，因爲處理器仍然可以自由亂序執行這些操作。爲了支持Java內存模型的一致性，JVM在第一次讀操作上添 加了註解ld.acq，也就是“載入獲取”（load acquire）。通過使用ld.acq，編譯器確保第二行的讀操作在接下來的讀操作之前完成。問題就解決了。
請注意這影響了讀操作，而不是寫。內存屏障強制讀或寫操作順序限制不是單向的。強制讀和寫操作順序限制的內存屏障是雙向的， 類似於雙向開的柵欄。使用ld.acq就是單向內存屏障的例子。
一致性具有兩面性。如果一個讀線程在兩次讀操作之間插入了內存屏障而另外一個線程沒有在兩次寫操作之間添加內存屏障又有什麼用呢？線程爲了協調，必須同時 遵守這個協議，就像網絡中的節點或者團隊中的成員。如果某個線程破壞了這個約定，那麼其他所有線程的努力都白費。Dekker算法的最後兩行代碼的彙編指 令應該插入一個內存屏障，兩次volatile寫之間。
$ java -XX:+UnlockDiagnosticVMOptions -XX:PrintAssemblyOptions=hsdis-print-bytes -XX:CompileCommand=print,WriterReader.write WriterReader
1 0x2000000001de81c0: adds r37=592,r36;; ;...0b284149 0421 2 0x2000000001de81c6: st4.rel [r37]=r39 ;...00389560 2380 3 0x2000000001de81cc: adds r36=596,r36;; ;...84112544 4 0x2000000001de81d0: st1.rel [r36]=r0 ;...09000048 a011 5 0x2000000001de81d6: mf ;...00000044 0000 6 0x2000000001de81dc: nop.i 0x0;; ;...00040000 7 0x2000000001de81e0: mov r12=r33 ;...00600042 0021 8 0x2000000001de81e6: mov.ret b0=r35,0x2000000001de81e0 9 0x2000000001de81ec: mov.i ar.pfs=r34 ;...00aa0220 10 0x2000000001de81f0: mov r6=r32 ;...09300040 0021
這裏我們可以看到在第四行第二次寫操作被註解了一個顯式內存屏障。通過使用st.rel，即“存儲釋放”（store release），編譯器確保第一次寫操作在第二次寫操作之前完成。這就完成了兩邊的約定，因爲第一次寫操作在第二次寫操作之前發生。
st.rel屏障是單向的——就像ld.acq一樣。但是在第五行編譯器設置了一個雙向內存屏障。mf指令，或者稱爲“內存柵欄”，是Itanium 2指令集中的完整柵欄。筆者認爲是多餘的。
內存屏障是特定於硬件的
本文不想針對所有內存屏障做一綜述。這將是一件不朽的功績。但是，重要的是認識到這些指令在不同的硬件體系中迥異。下面的指令是連續寫操作在多處理 Intel Xeon硬件上編譯的結果。本文後面的所有彙編指令除非特殊聲明否則都出自於Intel Xeon。
1 0x03f8340c: push %ebp ;...55
2 0x03f8340d: sub $0x8,%esp ;...81ec0800 0000
3 0x03f83413: mov $0x14c,%edi ;...bf4c0100 00
4 0x03f83418: movb $0x1,-0x505a72f0(%edi) ;...c687108d a5af01
5 0x03f8341f: mfence ;...0faef0
6 0x03f83422: mov $0x148,%ebp ;...bd480100 00
7 0x03f83427: mov $0x14d,%edx ;...ba4d0100 00
8 0x03f8342c: movsbl -0x505a72f0(%edx),%ebx ;...0fbe9a10 8da5af
9 0x03f83433: test %ebx,%ebx ;...85db
10 0x03f83435: jne 0x03f83460 ;...7529
11 0x03f83437: movl $0x1,-0x505a72f0(%ebp) ;...c785108d a5af01
12 0x03f83441: movb $0x0,-0x505a72f0(%edi) ;...c687108d a5af00
13 0x03f83448: mfence ;...0faef0
14 0x03f8344b: add $0x8,%esp ;...83c408
15 0x03f8344e: pop %ebp ;...5d
我們可以看到x86 Xeon在第11、12行執行兩次volatile寫操作。第二次寫操作後面緊跟着mfence操作——顯式的雙向內存屏障。
下面的連續寫操作基於SPARC。
1 0xfb8ecc84: ldub [ %l1 + 0x155 ], %l3 ;...e60c6155
2 0xfb8ecc88: cmp %l3, 0 ;...80a4e000
3 0xfb8ecc8c: bne,pn %icc, 0xfb8eccb0 ;...12400009
4 0xfb8ecc90: nop ;...01000000
5 0xfb8ecc94: st %l0, [ %l1 + 0x150 ] ;...e0246150
6 0xfb8ecc98: clrb [ %l1 + 0x154 ] ;...c02c6154
7 0xfb8ecc9c: membar #StoreLoad ;...8143e002
8 0xfb8ecca0: sethi %hi(0xff3fc000), %l0 ;...213fcff0
9 0xfb8ecca4: ld [ %l0 ], %g0 ;...c0042000
10 0xfb8ecca8: ret ;...81c7e008
11 0xfb8eccac: restore ;...81e80000
我們看到在第五、六行存在兩次volatile寫操作。第二次寫操作後面是一個membar指令——顯式的雙向內存屏障。
x86和SPARC的指令流與Itanium的指令流存在一個重要區別。JVM在x86和SPARC上通過內存屏障跟蹤連續寫操作，但是在兩次寫操作之間 沒有放置內存屏障。另一方面，Itanium的指令流在兩次寫操作之間存在內存屏障。爲何JVM在不同的硬件架構之間表現不一？因爲硬件架構都有自己的內 存模型，每一個內存模型有一套一致性保障。某些內存模型，如x86和SPARC等，擁有強大的一致性保障。另一些內存模型，如Itanium、 PowerPC和Alpha，是一種弱保障。例如，x86和SPARC不會重新排序連續寫操作——也就沒有必要放置內存屏障。Itanium、 PowerPC和Alpha將重新排序連續寫操作——因此JVM必須在兩者之間放置內存屏障。JVM使用內存屏障減少Java內存模型和硬件內存模型之間 的距離。
隱式內存屏障
顯式屏障指令不是序列化內存操作的唯一方式。讓我們再看一看Counter類這個例子。
class Counter{
static int counter = 0;
public static void main(String[] _){
for(int i = 0; i < 100000; i++)
inc();
}
static synchronized void inc(){ counter += 1; }
}
Counter類執行了一個典型的讀-修改-寫的操作。靜態counter字段不是volatile的，因爲所有三個操作必須要原子可見的。因此，inc 方法是synchronized修飾的。我們可以採用下面的命令編譯Counter類並查看生成的彙編指令。Java內存模型確保了 synchronized區域的退出和volatile內存操作都是相同的可見性，因此我們應該預料到會有另一個內存屏障。
$ java -XX:+UnlockDiagnosticVMOptions -XX:PrintAssemblyOptions=hsdis-print-bytes -XX:-UseBiasedLocking -XX:CompileCommand=print,Counter.inc Counter
1 0x04d5eda7: push %ebp ;...55
2 0x04d5eda8: mov %esp,%ebp ;...8bec
3 0x04d5edaa: sub $0x28,%esp ;...83ec28
4 0x04d5edad: mov $0x95ba5408,%esi ;...be0854ba 95
5 0x04d5edb2: lea 0x10(%esp),%edi ;...8d7c2410
6 0x04d5edb6: mov %esi,0x4(%edi) ;...897704
7 0x04d5edb9: mov (%esi),%eax ;...8b06
8 0x04d5edbb: or $0x1,%eax ;...83c801
9 0x04d5edbe: mov %eax,(%edi) ;...8907
10 0x04d5edc0: lock cmpxchg %edi,(%esi) ;...f00fb13e
11 0x04d5edc4: je 0x04d5edda ;...0f841000 0000
12 0x04d5edca: sub %esp,%eax ;...2bc4
13 0x04d5edcc: and $0xfffff003,%eax ;...81e003f0 ffff
14 0x04d5edd2: mov %eax,(%edi) ;...8907
15 0x04d5edd4: jne 0x04d5ee11 ;...0f853700 0000
16 0x04d5edda: mov $0x95ba52b8,%eax ;...b8b852ba 95
17 0x04d5eddf: mov 0x148(%eax),%esi ;...8bb04801 0000
18 0x04d5ede5: inc %esi ;...46
19 0x04d5ede6: mov %esi,0x148(%eax) ;...89b04801 0000
20 0x04d5edec: lea 0x10(%esp),%eax ;...8d442410
21 0x04d5edf0: mov (%eax),%esi ;...8b30
22 0x04d5edf2: test %esi,%esi ;...85f6
23 0x04d5edf4: je 0x04d5ee07 ;...0f840d00 0000
24 0x04d5edfa: mov 0x4(%eax),%edi ;...8b7804
25 0x04d5edfd: lock cmpxchg %esi,(%edi) ;...f00fb137
26 0x04d5ee01: jne 0x04d5ee1f ;...0f851800 0000
27 0x04d5ee07: mov %ebp,%esp ;...8be5
28 0x04d5ee09: pop %ebp ;...5d
不出意外，synchronized生成的指令數量比volatile多。第18行做了一次增操作，但是JVM沒有顯式插入內存屏障。相反，JVM通過在 第10行和第25行cmpxchg的lock前綴一石二鳥。cmpxchg的語義超越了本文的範疇。lock cmpxchg不僅原子性執行寫操作，也會刷新等待的讀寫操作。寫操作現在將在所有後續內存操作之前完成。如果我們通過 java.util.concurrent.atomic.AtomicInteger 重構和運行Counter，將看到同樣的手段。
import java.util.concurrent.atomic.AtomicInteger;
class Counter{
static AtomicInteger counter = new AtomicInteger(0);
public static void main(String[] args){
for(int i = 0; i < 1000000; i++)
counter.incrementAndGet();
}
}
$ java -XX:+UnlockDiagnosticVMOptions -XX:PrintAssemblyOptions=hsdis-print-bytes -XX:CompileCommand=print,*AtomicInteger.incrementAndGet Counter
1 0x024451f7: push %ebp ;...55
2 0x024451f8: mov %esp,%ebp ;...8bec
3 0x024451fa: sub $0x38,%esp ;...83ec38
4 0x024451fd: jmp 0x0244520a ;...e9080000 00
5 0x02445202: xchg %ax,%ax ;...6690
6 0x02445204: test %eax,0xb771e100 ;...850500e1 71b7
7 0x0244520a: mov 0x8(%ecx),%eax ;...8b4108
8 0x0244520d: mov %eax,%esi ;...8bf0
9 0x0244520f: inc %esi ;...46
10 0x02445210: mov $0x9a3f03d0,%edi ;...bfd0033f 9a
11 0x02445215: mov 0x160(%edi),%edi ;...8bbf6001 0000
12 0x0244521b: mov %ecx,%edi ;...8bf9
13 0x0244521d: add $0x8,%edi ;...83c708
14 0x02445220: lock cmpxchg %esi,(%edi) ;...f00fb137
15 0x02445224: mov $0x1,%eax ;...b8010000 00
16 0x02445229: je 0x02445234 ;...0f840500 0000
17 0x0244522f: mov $0x0,%eax ;...b8000000 00
18 0x02445234: cmp $0x0,%eax ;...83f800
19 0x02445237: je 0x02445204 ;...74cb
20 0x02445239: mov %esi,%eax ;...8bc6
21 0x0244523b: mov %ebp,%esp ;...8be5
22 0x0244523d: pop %ebp ;...5d
我們又一次在第14行看到了帶有lock前綴的寫操作。這確保了變量的新值（寫操作）會在其他所有後續內存操作之前完成。
內存屏障能夠避免
JVM非常擅於消除不必要的內存屏障。通常JVM很幸運，因爲硬件內存模型的一致性保障強於或者等於Java內存模型。在這種情況下，JVM只是簡單地插 入一個no op語句，而不是真實的內存屏障。例如，x86和SPARC內存模型的一致性保障足夠強壯以消除讀volatile變量時所需的內存屏障。還記得在 Itanium上兩次讀操作之間的顯式單向內存屏障嗎？x86上的Dekker算法中連續volatile讀操作的彙編指令之間沒有任何內存屏障。
x86平臺上共享內存的連續讀操作。
1 0x03f83422: mov $0x148,%ebp ;...bd480100 00
2 0x03f83427: mov $0x14d,%edx ;...ba4d0100 00
3 0x03f8342c: movsbl -0x505a72f0(%edx),%ebx ;...0fbe9a10 8da5af
4 0x03f83433: test %ebx,%ebx ;...85db
5 0x03f83435: jne 0x03f83460 ;...7529
6 0x03f83437: movl $0x1,-0x505a72f0(%ebp) ;...c785108d a5af01
7 0x03f83441: movb $0x0,-0x505a72f0(%edi) ;...c687108d a5af00
8 0x03f83448: mfence ;...0faef0
9 0x03f8344b: add $0x8,%esp ;...83c408
10 0x03f8344e: pop %ebp ;...5d
11 0x03f8344f: test %eax,0xb78ec000 ;...850500c0 8eb7
12 0x03f83455: ret ;...c3
13 0x03f83456: nopw 0x0(%eax,%eax,1) ;...66660f1f 840000
14 0x03f83460: mov -0x505a72f0(%ebp),%ebx ;...8b9d108d a5af
15 0x03f83466: test %edi,0xb78ec000 ;...853d00c0 8eb7
第三行和第十四行存在volatile讀操作，而且都沒有伴隨內存屏障。也就是說，x86和SPARC上的volatile讀操作的性能下降對於代碼的優 化影響很小——指令本身和常規讀操作一樣。
單向內存屏障本質上比雙向屏障性能要好一些。JVM在確保單向屏障即可的情況下會避免使用雙向屏障。本文的第一個例子展示了這點。Itanium平臺上的 連續兩次讀操作被插入單向內存屏障。如果讀操作插入顯式雙向內存屏障，程序仍然正確，但是延遲比較長。
動態編譯
靜態編譯器在構建階段決定的一切事情，在動態編譯器那裏都可以在運行時決定，甚至更多。更多信息意味着存在更多機會可以優化。例如，讓我們看看JVM在單 處理器運行時如何對待內存屏障。以下指令流來自於通過Dekker算法實現兩次連續volatile寫操作的運行時編譯。程序運行於 x86硬件上的單處理器模式中的VMWare工作站鏡像。
1 0x017b474c: push %ebp ;...55
2 0x017b474d: sub $0x8,%esp ;...81ec0800 0000
3 0x017b4753: mov $0x14c,%edi ;...bf4c0100 00
4 0x017b4758: movb $0x1,-0x507572f0(%edi) ;...c687108d 8aaf01
5 0x017b475f: mov $0x148,%ebp ;...bd480100 00
6 0x017b4764: mov $0x14d,%edx ;...ba4d0100 00
7 0x017b4769: movsbl -0x507572f0(%edx),%ebx ;...0fbe9a10 8d8aaf
8 0x017b4770: test %ebx,%ebx ;...85db
9 0x017b4772: jne 0x017b4790 ;...751c
10 0x017b4774: movl $0x1,-0x507572f0(%ebp) ;...c785108d 8aaf0111 0x017b477e: movb $0x0,-0x507572f0(%edi) ;...c687108d 8aaf00
12 0x017b4785: add $0x8,%esp ;...83c408
13 0x017b4788: pop %ebp ;...5d
在單處理器系統上，JVM爲所有內存屏障插入了一個no op指令，因爲內存操作已經序列化了。每一個寫操作（第10、11行）後面都跟着一個屏障。JVM針對原子條件式做了類似的優化。下面的指令流來自於同一 個VMWare鏡像的AtomicInteger.incrementAndGet動態編譯結果。
1 0x036880f7: push %ebp ;...55
2 0x036880f8: mov %esp,%ebp ;...8bec
3 0x036880fa: sub $0x38,%esp ;...83ec38
4 0x036880fd: jmp 0x0368810a ;...e9080000 00
5 0x03688102: xchg %ax,%ax ;...6690
6 0x03688104: test %eax,0xb78b8100 ;...85050081 8bb7
7 0x0368810a: mov 0x8(%ecx),%eax ;...8b4108
8 0x0368810d: mov %eax,%esi ;...8bf0
9 0x0368810f: inc %esi ;...46
10 0x03688110: mov $0x9a3f03d0,%edi ;...bfd0033f 9a
11 0x03688115: mov 0x160(%edi),%edi ;...8bbf6001 0000
12 0x0368811b: mov %ecx,%edi ;...8bf9
13 0x0368811d: add $0x8,%edi ;...83c708
14 0x03688120: cmpxchg %esi,(%edi) ;...0fb137
15 0x03688123: mov $0x1,%eax ;...b8010000 00
16 0x03688128: je 0x03688133 ;...0f840500 0000
17 0x0368812e: mov $0x0,%eax ;...b8000000 00
18 0x03688133: cmp $0x0,%eax ;...83f800
19 0x03688136: je 0x03688104 ;...74cc
20 0x03688138: mov %esi,%eax ;...8bc6
21 0x0368813a: mov %ebp,%esp ;...8be5
22 0x0368813c: pop %ebp ;...5d
注意第14行的cmpxchg指令。之前我們看到編譯器通過lock前綴把該指令提供給處理器。由於缺少SMP，JVM決定避免這種成本——與靜態編譯有些不同。
結束語
內存屏障是多線程編程的必要裝備。它們形式多樣，某些是顯式的，某些是隱式的。某些是雙向的，某些是單向的。JVM利用這些形式在所有平臺中有效地支持 Java內存模型。我希望本文能夠幫助經驗豐富的JVM開發人員瞭解一些代碼在底層如何運行的知識。
參考書目
•Intel 64和IA-32架構軟件開發人員手冊
•IA- 64應用指令集架構指南
•Java併發實踐（作者Brian Goetz）
•JSR-133手冊（作 者 Doug Lea）
•互斥（利用 Dekker 算法）
•通過PrintAssembly查看生成的代碼
•Kenai 項目——反編譯工具
•hsdis ——反編譯工具
關於作者
Dennis Byrne是DRW Trading（一家自營證券投資公司和流通量供應商）的一名高級軟件 工程師。他是一名作家、演說家和開源社區的活躍成員。
查看英文原文：Memory Barriers and JVM Concurrency。