內存屏障，又稱內存柵欄，是一組處理器指令，用於實現對內存操作的順序限 制。本文介紹了內存屏障對多線程程序的影響。我們將研究內存屏障與JVM並發機 制的關系，如易變量（volatile）、同步（synchronized）和原子條件式 （atomic conditional）。本文假定讀者已經充分掌握了相關概念和Java內存模 型，不討論並發互斥、並行機制和原子性。內存屏障用來實現並發編程中稱為可 見性（visibility）的同樣重要的作用。
內存屏障為何重要？
對主存的一次訪問一般花費硬件的數百次時鐘周期。處理器通過緩存 （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 8aaf01
11 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開發人員了解一些代碼在底層 如何運行的知識。
