Java 內存模型(JVM)

Posted on by

前言

在並發編程中，當多個線程同時訪問同一個共享的可變變量時，會產生不確定的結果，所以要編寫線程安全的代碼，其本質上是對這些可變的共享變量的訪問操作進行管理。導致這種不確定結果的原因就是可見性、有序性和原子性問題，Java 為解決可見性和有序性問題引入瞭 Java 內存模型，使用互斥方案（其核心實現技術是鎖）來解決原子性問題。這篇先來看看解決可見性、有序性問題的 Java 內存模型（JMM）。

一、什麼是 Java 內存模型

Java 內存模型定義如下：

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

通常，在線程之間的通訊方式有共享內存和消息傳遞兩種，很明顯，Java 采用的是第一種即共享的內存模型，在共享的內存模型裡，多線程之間共享程序的公共狀態，通過讀-寫內存的方式來進行隱式通訊。

從抽象的角度來看，JMM 其實是定義瞭線程和主內存之間的關系，首先，多個線程之間的共享變量存儲在主內存之中，同時每個線程都有一個自己私有的本地內存，本地內存中存儲著該線程讀或寫共享變量的副本（註意：本地內存是 JMM 定義的抽象概念，實際上並不存在）。抽象模型如下圖所示：

在這個抽象的內存模型中，在兩個線程之間的通信（共享變量狀態變更）時，會進行如下兩個步驟：

  1. 線程 A 把在本地內存更新後的共享變量副本的值，刷新到主內存中。
  2. 線程 B 在使用到該共享變量時，到主內存中去讀取線程 A 更新後的共享變量的值，並更新線程 B 本地內存的值。

JMM 本質上是在硬件（處理器）內存模型之上又做瞭一層抽象，使得應用開發人員隻需要瞭解 JMM 就可以編寫出正確的並發代碼，而無需過多瞭解硬件層面的內存模型。

二、為什麼需要 Java 內存模型

在日常的程序開發中，為一些共享變量賦值的場景會經常碰到，假設一個線程為整型共享變量 count 做賦值操作（count = 9527;），此時就會有一個問題，其它讀取該共享變量的線程在什麼情況下獲取到的變量值為 9527 呢？如果缺少同步的話，會有很多因素導致其它讀取該變量的線程無法立即甚至是永遠都無法看到該變量的最新值。

比如緩存就可能會改變寫入共享變量副本提交到主內存的次序，保存在本地緩存的值，對於其它線程是不可見的；編譯器為瞭優化性能，有時候會改變程序中語句執行的先後順序，這些因素都有可能會導致其它線程無法看到共享變量的最新值。

在文章開頭，提到瞭 JMM 主要是為瞭解決可見性和有序性問題，那麼首先就要先搞清楚，導致可見性和有序性問題發生的本質原因是什麼？現在的服務絕大部分都是運行在多核 CPU 的服務器上，每顆 CPU 都有自己的緩存，這時 CPU 緩存與內存的數據就會有一致性問題瞭，當一個線程對共享變量的修改，另外一個線程無法立刻看到。導致可見性問題的本質原因是緩存。

有序性是指代碼實際的執行順序和代碼定義的順序一致，編譯器為瞭優化性能，雖然會遵守 as-if-serial 語義（不管怎麼重排序，在單線程下的執行結果不能改變），不過有時候編譯器及解釋器的優化也可能引發一些問題。比如：雙重檢查來創建單實例對象。下面是使用雙重檢查來實現延遲創建單例對象的代碼：

/**
 * @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 代碼隻有一行，應該是無法就行重排序的，實際上其編譯後的實際指令是如下三步：

  1. 分配對象的內存空間
  2. 初始化對象
  3. 設置 instance 指向剛剛已經分配的內存地址

上面的第 2 步和第 3 步如果改變執行順序也不會改變單線程的執行結果，也就是說可能會發生重排序，下圖是一種多線程並發執行的場景：

此時線程 B 獲取到的 instance 是沒有初始化過的，如果此來訪問 instance 的成員變量就可能觸發空指針異常。導致有序性問題的本質原因是編譯器優化。那你可能會想既然緩存和編譯器優化是導致可見性問題和有序性問題的原因，那直接禁用掉不就可以徹底解決這些問題瞭嗎，但是如果這麼做瞭的話，程序的性能可能就會受到比較大的影響瞭。

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

三、順序一致性內存模型

順序一致性模型是一個理想化後的理論參考模型，處理器和編程語言的內存模型的設計都是參考的順序一致性模型理論。其有如下兩大特性：

  1. 一個線程中的所有操作必須按照程序的順序來執行
  2. 所有的線程都隻能看到一個單一的執行操作順序，不管程序是否同步

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

順序一致性模型有一個單一的全局內存，這個全局內存可以通過左右搖擺的開關可以連接到任意一個線程，每個線程都必須按照程序的順序來執行內存的讀和寫操作。該理想模型下，任務時刻都隻能有一個線程可以連接到內存，當多個線程並發執行時，就可以通過開關就可以把多個線程的讀和寫操作串行化。

順序一致性模型中，所有操操作完全按照順序串行執行，但是在 JMM 中就沒有這個保證瞭，未同步的程序在 JMM 中不僅程序的執行順序是無序的，而且由於本地內存的存在，所有線程看到的操作順序也可能會不一致，比如一個線程把寫共享變量保存在本地內存中，在還沒有刷新到主內存前，其它線程是不可見的，隻有更新到主內存後，其它線程才有可能看到。

JMM 對在正確同步的程序做瞭順序一致性的保證，也就是程序的執行結果和該程序在順序一致性內存模型中的執行結果相同。

四、Happens-Before 規則

Happens-Before 規則是 JMM 中的核心概念，Happens-Before 概念最開始在 這篇論文 提出，其在論文中使用 Happens-Before 來定義分佈式系統之間的偏序關系。在 JSR-133 中使用 Happens-Before 來指定兩個操作之間的執行順序。

JMM 正是通過這個規則來保證跨線程的內存可見性，Happens-Before 的含義是前面一個對共享變量的操作結果對該變量的後續操作是可見的，約束瞭編譯器的優化行為，雖然允許編譯器優化，但是優化後的代碼必須要滿足 Happens-Before 規則，這個規則給工程師做瞭這個保證：同步的多線程程序是按照 Happens-Before 指定的順序來執行的。目的就是為瞭在不改變程序（單線程或者正確同步的多線程程序）執行結果的前提下，盡最大可能的提高程序執行的效率。

JSR-133 規范中定瞭如下 6 項 Happens-Before 規則：

  1. 程序順序規則：一個線程中的每個操作，Happens-Before 該線程中的任意後續操作
  2. 監視器鎖規則：對一個鎖的解鎖操作，Happens-Before 於後面對這個鎖的加鎖操作
  3. volatile 規則：對一個 volatile 類型的變量的寫操作，Happens-Before 與任意後面對這個 volatile 變量的讀操作
  4. 傳遞性規則：如果操作 A Happens-Before 於操作 B，並且操作 B Happens-Before 於操作 C，則操作 A Happens-Before 於操作 C
  5. start() 規則：如果一個線程 A 執行操作 threadB.start() 啟動線程 B，那麼線程 A 的 start() 操作 Happens-Before 於線程 B 的任意操作
  6. join() 規則：如果線程 A 執行操作 threadB.join() 並成功返回，那麼線程 B 中的任意操作 Happens-Before 於線程 A 從 threadB.join() 操作成功返回

JMM 的一個基本原則是：隻要不改變單線程和正確同步的多線程的執行結果，編譯器和處理器隨便怎麼優化都可以，實際上對於應用開發人員對於兩個操作是否真的被重排序並不關心，真正關心的是執行結果不能被修改。因此 Happens-Before 本質上和 sa-if-serial 的語義是一致的，隻是 sa-if-serial 隻是保證在單線程下的執行結果不被改變。

總結：
本文主要介紹瞭內存模型的相關基礎知識和相關概念，JMM 屏蔽瞭不同處理器內存模型之間的差異，在不同的處理器平臺上給應用開發人員抽象出瞭統一的 Java 內存模型（JMM）。常見的處理器內存模型比 JMM 的要弱，因此 JVM 會在生成字節碼指令時在適當的位置插入內存屏障（內存屏障的類型會因處理器平臺而有所不同）來限制部分重排序。更多關於Java 內存模型的資料請關註WalkonNet其它相關文章！,希望大傢以後多多支持WalkonNet！

推薦閱讀：