前言

Java 語(yǔ)言在設(shè)計(jì)之初就引入了線程的概念，以充分利用現(xiàn)代處理器的計(jì)算能力，這既帶來了強(qiáng)大、靈活的多線程機(jī)制，也帶來了線程安全等令人混淆的問題，而 Java 內(nèi)存模型（Java Memory Model，JMM）為我們提供了一個(gè)在紛亂之中達(dá)成一致的指導(dǎo)準(zhǔn)則。

本篇博文的重點(diǎn)是，Java 內(nèi)存模型中的 happen-before 是什么？

概述

Happen-before 關(guān)系，是 Java 內(nèi)存模型中保證多線程操作可見性的機(jī)制，也是對(duì)早期語(yǔ)言規(guī)范中含糊的可見性概念的一個(gè)精確定義。

它的具體表現(xiàn)形式，包括但遠(yuǎn)不止是我們直覺中的 synchronized、volatile、lock 操作順序等方面，例如：

• 線程內(nèi)執(zhí)行的每個(gè)操作，都保證 happen-before 后面的操作，這就保證了基本的程序順序規(guī)則，這是開發(fā)者在書寫程序時(shí)的基本約定。
• 對(duì)于 volatile 變量，對(duì)它的寫操作，保證 happen-before 在隨后對(duì)該變量的讀取操作。
• 對(duì)于一個(gè)鎖的解鎖操作，保證 happen-before 加鎖操作。
• 對(duì)象構(gòu)建完成，保證 happen-before 于 finalizer 的開始動(dòng)作。
• 甚至是類似線程內(nèi)部操作的完成，保證 happen-before 其他 Thread.join() 的線程等。

這些 happen-before 關(guān)系是存在著傳遞性的，如果滿足 a happen-before b 和 b happen-before c，那么 a happen-before c 也成立。

前面我一直用 happen-before，而不是簡(jiǎn)單說前后，是因?yàn)樗粌H僅是對(duì)執(zhí)行時(shí)間的保證，也包括對(duì)內(nèi)存讀、寫操作順序的保證。僅僅是時(shí)鐘順序上的先后，并不能保證線程交互的可見性。

為什么需要 JMM，它試圖解決什么問題？

Java 是最早嘗試提供內(nèi)存模型的語(yǔ)言，這是簡(jiǎn)化多線程編程、保證程序可移植性的一個(gè)飛躍。早期類似 C、C++ 等語(yǔ)言，并不存在內(nèi)存模型的概念（C++ 11 中也引入了標(biāo)準(zhǔn)內(nèi)存模型），其行為依賴于處理器本身的內(nèi)存一致性模型，但不同的處理器可能差異很大，所以一段 C++ 程序在處理器 A 上運(yùn)行正常，并不能保證其在處理器 B 上也是一致的。

即使如此，最初的 Java 語(yǔ)言規(guī)范仍然是存在著缺陷的，當(dāng)時(shí)的目標(biāo)是，希望 Java 程序可以充分利用現(xiàn)代硬件的計(jì)算能力，同時(shí)保持“書寫一次，到處執(zhí)行”的能力。

但是，顯然問題的復(fù)雜度被低估了，隨著 Java 被運(yùn)行在越來越多的平臺(tái)上，人們發(fā)現(xiàn)，過于泛泛的內(nèi)存模型定義，存在很多模棱兩可之處，對(duì) synchronized 或 volatile 等，類似指令重排序時(shí)的行為，并沒有提供清晰規(guī)范。這里說的指令重排序，既可以是編譯器優(yōu)化行為，也可能是源自于現(xiàn)代處理器的亂序執(zhí)行等。

換句話說：

• 既不能保證一些多線程程序的正確性，例如最著名的就是雙檢鎖（Double-Checked Locking，DCL）的失效問題，雙檢鎖可能導(dǎo)致未完整初始化的對(duì)象被訪問，理論上這叫并發(fā)編程中的安全發(fā)布（Safe Publication）失敗。
• 也不能保證同一段程序在不同的處理器架構(gòu)上表現(xiàn)一致，例如有的處理器支持緩存一致性，有的不支持，各自都有自己的內(nèi)存排序模型。

所以，Java 迫切需要一個(gè)完善的 JMM，能夠讓普通 Java 開發(fā)者和編譯器、JVM 工程師，能夠清晰地達(dá)成共識(shí)。換句話說，可以相對(duì)簡(jiǎn)單并準(zhǔn)確地判斷出，多線程程序什么樣的執(zhí)行序列是符合規(guī)范的。

所以：

• 對(duì)于編譯器、JVM 開發(fā)者，關(guān)注點(diǎn)可能是如何使用類似內(nèi)存屏障（Memory-Barrier）之類技術(shù)，保證執(zhí)行結(jié)果符合 JMM 的推斷。
• 對(duì)于 Java 應(yīng)用開發(fā)者，則可能更加關(guān)注 volatile、synchronized 等語(yǔ)義，如何利用類似 happen-before 的規(guī)則，寫出可靠的多線程應(yīng)用，而不是利用一些“秘籍”去糊弄編譯器、JVM。

我畫了一個(gè)簡(jiǎn)單的角色層次圖，不同工程師分工合作，其實(shí)所處的層面是有區(qū)別的。JMM 為 Java 工程師隔離了不同處理器內(nèi)存排序的區(qū)別，這也是為什么我通常不建議過早深入處理器體系結(jié)構(gòu)，某種意義上來說，這樣本就違背了 JMM 的初衷。

JMM 是怎么解決可見性等問題的呢？

在這里有必要簡(jiǎn)要介紹一下典型的問題場(chǎng)景。

在 【JAVA】JVM 內(nèi)存區(qū)域的劃分 里介紹了 JVM 內(nèi)部的運(yùn)行時(shí)數(shù)據(jù)區(qū)，但是真正程序執(zhí)行，實(shí)際是要跑在具體的處理器內(nèi)核上。你可以簡(jiǎn)單理解為，把本地變量等數(shù)據(jù)從內(nèi)存加載到緩存、寄存器，然后運(yùn)算結(jié)束寫回主內(nèi)存。你可以從下面示意圖，看這兩種模型的對(duì)應(yīng)。

看上去很美好，但是當(dāng)多線程共享變量時(shí)，情況就復(fù)雜了。試想，如果處理器對(duì)某個(gè)共享變量進(jìn)行了修改，可能只是體現(xiàn)在該內(nèi)核的緩存里，這是個(gè)本地狀態(tài)，而運(yùn)行在其他內(nèi)核上的線程，可能還是加載的舊狀態(tài)，這很可能導(dǎo)致一致性的問題。從理論上來說，多線程共享引入了復(fù)雜的數(shù)據(jù)依賴性，不管編譯器、處理器怎么做重排序，都必須尊重?cái)?shù)據(jù)依賴性的要求，否則就打破了正確性！這就是 JMM 所要解決的問題。

JMM 內(nèi)部的實(shí)現(xiàn)通常是依賴于所謂的內(nèi)存屏障，通過禁止某些重排序的方式，提供內(nèi)存可見性保證，也就是實(shí)現(xiàn)了各種 happen-before 規(guī)則。與此同時(shí)，更多復(fù)雜度在于，需要盡量確保各種編譯器、各種體系結(jié)構(gòu)的處理器，都能夠提供一致的行為。

我以 volatile 為例，看看如何利用內(nèi)存屏障實(shí)現(xiàn) JMM 定義的可見性？

對(duì)于一個(gè) volatile 變量：

• 對(duì)該變量的寫操作之后，編譯器會(huì)插入一個(gè)寫屏障。
• 對(duì)該變量的讀操作之前，編譯器會(huì)插入一個(gè)讀屏障。

內(nèi)存屏障能夠在類似變量讀、寫操作之后，保證其他線程對(duì) volatile 變量的修改對(duì)當(dāng)前線程可見，或者本地修改對(duì)其他線程提供可見性。換句話說，線程寫入，寫屏障會(huì)通過類似強(qiáng)迫刷出處理器緩存的方式，讓其他線程能夠拿到最新數(shù)值。

如果你對(duì)更多內(nèi)存屏障的細(xì)節(jié)感興趣，或者想了解不同體系結(jié)構(gòu)的處理器模型，建議參考 JSR-133 相關(guān)文檔，我個(gè)人認(rèn)為這些都是和特定硬件相關(guān)的，內(nèi)存屏障之類只是實(shí)現(xiàn) JMM 規(guī)范的技術(shù)手段，并不是規(guī)范的要求。

從應(yīng)用開發(fā)者的角度，JMM 提供的可見性，體現(xiàn)在類似 volatile 上，具體行為是什么樣呢？

我這里循序漸進(jìn)的舉兩個(gè)例子。

首先，請(qǐng)看下面的代碼片段，希望達(dá)到的效果是，當(dāng) condition 被賦值為 false 時(shí)，線程 A 能夠從循環(huán)中退出。

// Thread A
while (condition) {
}
// Thread B
condition = false;

這里就需要 condition 被定義為 volatile 變量，不然其數(shù)值變化，往往并不能被線程 A 感知，進(jìn)而無法退出。當(dāng)然，也可以在 while 中，添加能夠直接或間接起到類似效果的代碼。

第二，我想舉 Brian Goetz 提供的一個(gè)經(jīng)典用例，使用 volatile 作為守衛(wèi)對(duì)象，實(shí)現(xiàn)某種程度上輕量級(jí)的同步，請(qǐng)看代碼片段：

Map configOptions;
char[] configText;
volatile boolean initialized = false;
// Thread A
configOptions = new HashMap();
configText = readConfigFile(fileName);
processConfigOptions(configText, configOptions);
initialized = true;
// Thread B
while (!initialized)
  sleep();
// use configOptions

JSR-133 重新定義的 JMM 模型，能夠保證線程 B 獲取的 configOptions 是更新后的數(shù)值。

也就是說 volatile 變量的可見性發(fā)生了增強(qiáng)，能夠起到守護(hù)其上下文的作用。線程 A 對(duì) volatile 變量的賦值，會(huì)強(qiáng)制將該變量自己和當(dāng)時(shí)其他變量的狀態(tài)都刷出緩存，為線程 B 提供可見性。當(dāng)然，這也是以一定的性能開銷作為代價(jià)的，但畢竟帶來了更加簡(jiǎn)單的多線程行為。

我們經(jīng)常會(huì)說 volatile 比 synchronized 之類更加輕量，但輕量也僅僅是相對(duì)的，volatile 的讀、寫仍然要比普通的讀寫要開銷更大，所以如果你是在性能高度敏感的場(chǎng)景，除非你確定需要它的語(yǔ)義，不然慎用。

后記

以上就是 【JAVA】Java 內(nèi)存模型中的 happen-before 的所有內(nèi)容了;

從 happen-before 關(guān)系開始，幫你理解了什么是 Java 內(nèi)存模型。為了更方便理解，我作了簡(jiǎn)化，從不同工程師的角色劃分等角度，闡述了問題的由來，以及 JMM 是如何通過類似內(nèi)存屏障等技術(shù)實(shí)現(xiàn)的。最后，我以 volatile 為例，分析了可見性在多線程場(chǎng)景中的典型用例。

更多關(guān)于Java happen before的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論