Java 內(nèi)存模型

前言

在并發(fā)編程中,當(dāng)多個(gè)線程同時(shí)訪問同一個(gè)共享的可變變量時(shí),會(huì)產(chǎn)生不確定的結(jié)果,所以要編寫線程安全的代碼,其本質(zhì)上是對這些可變的共享變量的訪問操作進(jìn)行管理。導(dǎo)致這種不確定結(jié)果的原因就是可見性有序性原子性問題,Java 為解決可見性和有序性問題引入了 Java 內(nèi)存模型,使用互斥方案(其核心實(shí)現(xiàn)技術(shù)是)來解決原子性問題。這篇先來看看解決可見性、有序性問題的 Java 內(nèi)存模型(JMM)。

什么是 Java 內(nèi)存模型

Java 內(nèi)存模型在維基百科上的定義如下:

The Java memory model describes how threads in the Java programming language interact through memory. Together with the description of single-threaded execution of code, the memory model provides the semantics of the Java programming language.

內(nèi)存模型限制的是共享變量,也就是存儲(chǔ)在堆內(nèi)存中的變量,在 Java 語言中,所有的實(shí)例變量、靜態(tài)變量和數(shù)組元素都存儲(chǔ)在堆內(nèi)存之中。而方法參數(shù)、異常處理參數(shù)這些局部變量存儲(chǔ)在方法棧幀之中,因此不會(huì)在線程之間共享,不會(huì)受到內(nèi)存模型影響,也不存在內(nèi)存可見性問題。

通常,在線程之間的通訊方式有共享內(nèi)存和消息傳遞兩種,很明顯,Java 采用的是第一種即共享的內(nèi)存模型,在共享的內(nèi)存模型里,多線程之間共享程序的公共狀態(tài),通過讀-寫內(nèi)存的方式來進(jìn)行隱式通訊。

從抽象的角度來看,JMM 其實(shí)是定義了線程和主內(nèi)存之間的關(guān)系,首先,多個(gè)線程之間的共享變量存儲(chǔ)在主內(nèi)存之中,同時(shí)每個(gè)線程都有一個(gè)自己私有的本地內(nèi)存,本地內(nèi)存中存儲(chǔ)著該線程讀或?qū)懝蚕碜兞康母北荆ㄗ⒁猓罕镜貎?nèi)存是 JMM 定義的抽象概念,實(shí)際上并不存在)。抽象模型如下圖所示:

1.png

在這個(gè)抽象的內(nèi)存模型中,在兩個(gè)線程之間的通信(共享變量狀態(tài)變更)時(shí),會(huì)進(jìn)行如下兩個(gè)步驟:

  1. 線程 A 把在本地內(nèi)存更新后的共享變量副本的值,刷新到主內(nèi)存中。
  2. 線程 B 在使用到該共享變量時(shí),到主內(nèi)存中去讀取線程 A 更新后的共享變量的值,并更新線程 B 本地內(nèi)存的值。

JMM 本質(zhì)上是在硬件(處理器)內(nèi)存模型之上又做了一層抽象,使得應(yīng)用開發(fā)人員只需要了解 JMM 就可以編寫出正確的并發(fā)代碼,而無需過多了解硬件層面的內(nèi)存模型。

為什么需要 Java 內(nèi)存模型

在日常的程序開發(fā)中,為一些共享變量賦值的場景會(huì)經(jīng)常碰到,假設(shè)一個(gè)線程為整型共享變量 count 做賦值操作(count = 9527;),此時(shí)就會(huì)有一個(gè)問題,其它讀取該共享變量的線程在什么情況下獲取到的變量值為 9527 呢?如果缺少同步的話,會(huì)有很多因素導(dǎo)致其它讀取該變量的線程無法立即甚至是永遠(yuǎn)都無法看到該變量的最新值。

比如緩存就可能會(huì)改變寫入共享變量副本提交到主內(nèi)存的次序,保存在本地緩存的值,對于其它線程是不可見的;編譯器為了優(yōu)化性能,有時(shí)候會(huì)改變程序中語句執(zhí)行的先后順序,這些因素都有可能會(huì)導(dǎo)致其它線程無法看到共享變量的最新值。

在文章開頭,提到了 JMM 主要是為了解決可見性有序性問題,那么首先就要先搞清楚,導(dǎo)致可見性有序性問題發(fā)生的本質(zhì)原因是什么?現(xiàn)在的服務(wù)絕大部分都是運(yùn)行在多核 CPU 的服務(wù)器上,每顆 CPU 都有自己的緩存,這時(shí) CPU 緩存與內(nèi)存的數(shù)據(jù)就會(huì)有一致性問題了,當(dāng)一個(gè)線程對共享變量的修改,另外一個(gè)線程無法立刻看到。導(dǎo)致可見性問題的本質(zhì)原因是緩存

2.png

有序性是指代碼實(shí)際的執(zhí)行順序和代碼定義的順序一致,編譯器為了優(yōu)化性能,雖然會(huì)遵守 as-if-serial 語義(不管怎么重排序,在單線程下的執(zhí)行結(jié)果不能改變),不過有時(shí)候編譯器及解釋器的優(yōu)化也可能引發(fā)一些問題。比如:雙重檢查來創(chuàng)建單實(shí)例對象。下面是使用雙重檢查來實(shí)現(xiàn)延遲創(chuàng)建單例對象的代碼:

/**
 * @author mghio
 * @since 2021-08-22
 */
public class DoubleCheckedInstance {

  private static DoubleCheckedInstance instance;

  public static DoubleCheckedInstance getInstance() {
    if (instance == null) {
      synchronized (DoubleCheckedInstance.class) {
        if (instance == null) {
          instance = new DoubleCheckedInstance();
        }
      }
    }

    return instance;
  }
  
}

這里的 instance = new DoubleCheckedInstance();,看起來 Java 代碼只有一行,應(yīng)該是無法就行重排序的,實(shí)際上其編譯后的實(shí)際指令是如下三步:

  1. 分配對象的內(nèi)存空間
  2. 初始化對象
  3. 設(shè)置 instance 指向剛剛已經(jīng)分配的內(nèi)存地址

上面的第 2 步和第 3 步如果改變執(zhí)行順序也不會(huì)改變單線程的執(zhí)行結(jié)果,也就是說可能會(huì)發(fā)生重排序,下圖是一種多線程并發(fā)執(zhí)行的場景:

3.png

此時(shí)線程 B 獲取到的 instance 是沒有初始化過的,如果此來訪問 instance 的成員變量就可能觸發(fā)空指針異常。導(dǎo)致有序性問題的本質(zhì)原因是編譯器優(yōu)化。那你可能會(huì)想既然緩存和編譯器優(yōu)化是導(dǎo)致可見性問題和有序性問題的原因,那直接禁用掉不就可以徹底解決這些問題了嗎,但是如果這么做了的話,程序的性能可能就會(huì)受到比較大的影響了。

其實(shí)可以換一種思路,能不能把這些禁用緩存和編譯器優(yōu)化的權(quán)利交給編碼的工程師來處理,他們肯定最清楚什么時(shí)候需要禁用,這樣就只需要提供按需禁用緩存和編譯優(yōu)化的方法即可,使用比較靈活。因此Java 內(nèi)存模型就誕生了,它規(guī)范了 JVM 如何提供按需禁用緩存和編譯優(yōu)化的方法,規(guī)定了 JVM 必須遵守一組最小的保證,這個(gè)最小保證規(guī)定了線程對共享變量的寫入操作何時(shí)對其它線程可見。

順序一致性內(nèi)存模型

順序一致性模型是一個(gè)理想化后的理論參考模型,處理器和編程語言的內(nèi)存模型的設(shè)計(jì)都是參考的順序一致性模型理論。其有如下兩大特性:

  1. 一個(gè)線程中的所有操作必須按照程序的順序來執(zhí)行
  2. 所有的線程都只能看到一個(gè)單一的執(zhí)行操作順序,不管程序是否同步

在工程師視角下的順序一致性模型如下:

4.png

順序一致性模型有一個(gè)單一的全局內(nèi)存,這個(gè)全局內(nèi)存可以通過左右搖擺的開關(guān)可以連接到任意一個(gè)線程,每個(gè)線程都必須按照程序的順序來執(zhí)行內(nèi)存的讀和寫操作。該理想模型下,任務(wù)時(shí)刻都只能有一個(gè)線程可以連接到內(nèi)存,當(dāng)多個(gè)線程并發(fā)執(zhí)行時(shí),就可以通過開關(guān)就可以把多個(gè)線程的讀和寫操作串行化

順序一致性模型中,所有操操作完全按照順序串行執(zhí)行,但是在 JMM 中就沒有這個(gè)保證了,未同步的程序在 JMM 中不僅程序的執(zhí)行順序是無序的,而且由于本地內(nèi)存的存在,所有線程看到的操作順序也可能會(huì)不一致,比如一個(gè)線程把寫共享變量保存在本地內(nèi)存中,在還沒有刷新到主內(nèi)存前,其它線程是不可見的,只有更新到主內(nèi)存后,其它線程才有可能看到。

JMM 對在正確同步的程序做了順序一致性的保證,也就是程序的執(zhí)行結(jié)果和該程序在順序一致性內(nèi)存模型中的執(zhí)行結(jié)果相同。

Happens-Before 規(guī)則

Happens-Before 規(guī)則是 JMM 中的核心概念,Happens-Before 概念最開始在 這篇論文 提出,其在論文中使用 Happens-Before 來定義分布式系統(tǒng)之間的偏序關(guān)系。在 JSR-133 中使用 Happens-Before 來指定兩個(gè)操作之間的執(zhí)行順序。

JMM 正是通過這個(gè)規(guī)則來保證跨線程的內(nèi)存可見性,Happens-Before 的含義是前面一個(gè)對共享變量的操作結(jié)果對該變量的后續(xù)操作是可見的,約束了編譯器的優(yōu)化行為,雖然允許編譯器優(yōu)化,但是優(yōu)化后的代碼必須要滿足 Happens-Before 規(guī)則,這個(gè)規(guī)則給工程師做了這個(gè)保證:同步的多線程程序是按照 Happens-Before 指定的順序來執(zhí)行的。目的就是為了在不改變程序(單線程或者正確同步的多線程程序)執(zhí)行結(jié)果的前提下,盡最大可能的提高程序執(zhí)行的效率

5.png

JSR-133 規(guī)范中定了如下 6 項(xiàng) Happens-Before 規(guī)則:

  1. 程序順序規(guī)則:一個(gè)線程中的每個(gè)操作,Happens-Before 該線程中的任意后續(xù)操作
  2. 監(jiān)視器鎖規(guī)則:對一個(gè)鎖的解鎖操作,Happens-Before 于后面對這個(gè)鎖的加鎖操作
  3. volatile 規(guī)則對一個(gè) volatile 類型的變量的寫操作,Happens-Before 與任意后面對這個(gè) volatile 變量的讀操作
  4. 傳遞性規(guī)則:如果操作 A Happens-Before 于操作 B,并且操作 B Happens-Before 于操作 C,則操作 A Happens-Before 于操作 C
  5. start() 規(guī)則:如果一個(gè)線程 A 執(zhí)行操作 threadB.start() 啟動(dòng)線程 B,那么線程 A 的 start() 操作 Happens-Before 于線程 B 的任意操作
  6. join() 規(guī)則:如果線程 A 執(zhí)行操作 threadB.join() 并成功返回,那么線程 B 中的任意操作 Happens-Before 于線程 A 從 threadB.join() 操作成功返回

JMM 的一個(gè)基本原則是:只要不改變單線程和正確同步的多線程的執(zhí)行結(jié)果,編譯器和處理器隨便怎么優(yōu)化都可以,實(shí)際上對于應(yīng)用開發(fā)人員對于兩個(gè)操作是否真的被重排序并不關(guān)心,真正關(guān)心的是執(zhí)行結(jié)果不能被修改。因此 Happens-Before 本質(zhì)上和 sa-if-serial 的語義是一致的,只是 sa-if-serial 只是保證在單線程下的執(zhí)行結(jié)果不被改變。

總結(jié)

本文主要介紹了內(nèi)存模型的相關(guān)基礎(chǔ)知識(shí)和相關(guān)概念,JMM 屏蔽了不同處理器內(nèi)存模型之間的差異,在不同的處理器平臺(tái)上給應(yīng)用開發(fā)人員抽象出了統(tǒng)一的 Java 內(nèi)存模型(JMM)。常見的處理器內(nèi)存模型比 JMM 的要弱,因此 JVM 會(huì)在生成字節(jié)碼指令時(shí)在適當(dāng)?shù)奈恢貌迦雰?nèi)存屏障(內(nèi)存屏障的類型會(huì)因處理器平臺(tái)而有所不同)來限制部分重排序。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。
  • 序言:七十年代末,一起剝皮案震驚了整個(gè)濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,967評論 6 531
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 98,273評論 3 415
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,870評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經(jīng)常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,742評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 71,527評論 6 407
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 55,010評論 1 322
  • 那天,我揣著相機(jī)與錄音,去河邊找鬼。 笑死,一個(gè)胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,108評論 3 440
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 42,250評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個(gè)月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 48,769評論 1 333
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 40,656評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 42,853評論 1 369
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,371評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 44,103評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,472評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,717評論 1 281
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個(gè)月前我還...
    沈念sama閱讀 51,487評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個(gè)殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 47,815評論 2 372

推薦閱讀更多精彩內(nèi)容