看完這篇，還不懂JAVA記憶體模型(JMM)算我輸

JAVA旭陽發表於2022-12-06
Java記憶體模型

歡迎關注專欄【JAVA併發】

前言

開篇一個例子，我看看都有誰會？如果不會的，或者不知道原理的，還是老老實實看完這篇文章吧。

@Slf4j(topic = "c.VolatileTest")
public class VolatileTest {
    
    static boolean run = true;

    public static void main(String[] args) throws InterruptedException {
        Thread t = new Thread(() -> {
            while (run) {
                // do other things
            }
            
            // ?????? 這行會列印嗎？
            log.info("done .....");
        });
        t.start();
        
        Thread.sleep(1000);

       // 設定run = false
        run = false;
    }
}

main函式中新開個執行緒根據標位run迴圈，主執行緒中sleep一秒，然後設定run=false，大家認為會列印"done ......."嗎?

答案就是不會列印，為什麼呢？

JAVA併發三大特性

我們先來解釋下上面問題的原因，如下圖所示，

現代的CPU架構基本有多級快取機制，t執行緒會將run載入到快取記憶體中，然後主執行緒修改了主記憶體的值為false，導致快取不一致，但是t執行緒依然是從工作記憶體中的快取記憶體讀取run的值，最終無法跳出迴圈。

可見性

正如上面的例子，由於不做任何處理，一個執行緒能否立刻看到另外一個執行緒修改的共享變數值，我們稱為"可見性"。

如果在併發程式中，不做任何處理，那麼就會帶來可見性問題，具體如何處理，見後文。

有序性

有序性是指程式按照程式碼的先後順序執行。但是編譯器或者處理器出於效能原因，改變程式語句的先後順序，比如程式碼順序"a=1; b=2;"，但是指令重排序後，有可能會變成"b=2；a=1", 那麼這樣在併發情況下，會有問題嗎？

在單執行緒情況下，指令重排序不會有任何影響。但是在併發情況下，可能會導致一些意想不到的bug。比如下面的例子：

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

假設有兩個執行緒 A、B 同時呼叫 getInstance() 方法，正常情況下，他們都可以拿到instance例項。

但往往bug就在一些極端的異常情況，比如new Singleton() 這個操作，實際會有下面3個步驟：

  1. 分配一塊記憶體 M；

  2. 在記憶體 M 上初始化 Singleton 物件；

  3. 然後 M 的地址賦值給 instance 變數。

現在發生指令重排序，順序變為下面的方式：

  1. 分配一塊記憶體 M；

  2. 將 M 的地址賦值給 instance 變數；

  3. 最後在記憶體 M 上初始化 Singleton 物件。

最佳化後會導致什麼問題呢？我們假設執行緒 A 先執行 getInstance() 方法，當執行完指令 2 時恰好發生了執行緒切換，切換到了執行緒 B 上；如果此時執行緒 B 也執行 getInstance() 方法，那麼執行緒 B 在執行第一個判斷時會發現 instance != null ，所以直接返回 instance，而此時的 instance 是沒有初始化過的，如果我們這個時候訪問 instance 的成員變數就可能觸發空指標異常。

這就是併發情況下，有序性帶來的一個問題，這種情況又該如何處理呢？

當然，指令重排序並不會瞎排序，處理器在進行重排序時，必須要考慮指令之間的資料依賴性。

原子性

如上圖所示，在多執行緒的情況下，CPU資源會在不同的執行緒間切換。那麼這樣也會導致意向不到的問題。

比如你認為的一行程式碼：count += 1,實際上涉及了多條CPU指令：

  • 指令 1：首先，需要把變數 count 從記憶體載入到 CPU 的暫存器；
  • 指令 2：之後，在暫存器中執行 +1 操作；
  • 指令 3：最後，將結果寫入記憶體（快取機制導致可能寫入的是 CPU 快取而不是記憶體）。

作業系統做任務切換，可以發生在任何一條CPU 指令執行完。假設 count=0，如果執行緒 A 在指令 1 執行完後做執行緒切換，執行緒 A 和執行緒 B 按照下圖的序列執行，那麼我們會發現兩個執行緒都執行了 count+=1 的操作，但是得到的結果不是我們期望的 2，而是 1。

我們潛意識認為的這個count+=1操作是一個不可分割的整體，就像一個原子一樣，我們把一個或者多個操作在 CPU 執行的過程中不被中斷的特性稱為原子性。但實際情況就是不做任何處理的話，在併發情況下CPU進行切換，導致出現原子性的問題，我們一般透過加鎖解決，這個不是本文的重點。

Java記憶體模型真面目

前面講解併發的三大特性，其中原子性問題可以透過加鎖的方式解決，那麼可見性和有序性有什麼解決的方案呢？其實也很容易想到，可見性是因為快取導致，有序性是因為編譯最佳化指令重排序導致，那麼是不是可以讓程式設計師按需禁用快取以及編譯最佳化， 因為只有程式設計師知道什麼情況下會出現問題 。 順著這個思路，就提出了JAVA記憶體模型（JMM）規範。

Java 記憶體模型是 Java Memory Model（JMM），本身是一種抽象的概念，實際上並不存在，描述的是一組規則或規範，透過這組規範定義了程式中各個變數（包括例項欄位，靜態欄位和構成陣列物件的元素）的訪問方式。

預設情況下，JMM中的記憶體機制如下：

  • 系統存在一個主記憶體（Main Memory），Java 中所有變數都儲存在主存中，對於所有執行緒都是共享的
  • 每條執行緒都有自己的工作記憶體（Working Memory），工作記憶體中儲存的是主存中某些變數的複製
  • 執行緒對所有變數的操作都是先對變數進行複製，然後在工作記憶體中進行，不能直接操作主記憶體中的變數
  • 執行緒之間無法相互直接訪問，執行緒間的通訊（傳遞）必須透過主記憶體來完成

同時，JMM規範了 JVM 如何提供按需禁用快取和編譯最佳化的方法，主要是透過volatile、synchronized 和 final 三個關鍵字，那具體的規則是什麼樣的呢？

JMM 中的主記憶體、工作記憶體與 JVM 中的 Java 堆、棧、方法區等並不是同一個層次的記憶體劃分，這兩者基本上是沒有關係的。

Happens-Before規則

JMM本質上包含了一些規則，那這個規則就是大家有所耳聞的Happens-Before規則，大家都理解了些規則嗎？

Happens-Before規則，可以簡單理解為如果想要A執行緒發生在B執行緒前面，也就是B執行緒能夠看到A執行緒，需要遵循6個原則。如果不符合 happens-before 規則，JMM 並不能保證一個執行緒的可見性和有序性。

1.程式的順序性規則

在一個執行緒中，邏輯上書寫在前面的操作先行發生於書寫在後面的操作。

這個規則很好理解，同一個執行緒中他們是用的同一個工作快取，是可見的，並且多個操作之間有先後依賴關係，則不允許對這些操作進行重排序。

2. volatile 變數規則

指對一個 volatile 變數的寫操作， Happens-Before 於後續對這個 volatile 變數的讀操作。

怎麼理解呢？比如執行緒A對volatile變數進行寫操作，那麼執行緒B讀取這個volatile變數是可見的，就是說能夠讀取到最新的值。

3.傳遞性

這條規則是指如果 A Happens-Before B，且 B Happens-Before C，那麼 A Happens-Before C。

這個規則也比較容易理解，不展開討論了。

  1. 鎖的規則

這條規則是指對一個鎖的解鎖 Happens-Before於後續對這個鎖的加鎖，這裡的鎖要是同一把鎖, 而且用synchronized或者ReentrantLock都可以。

如下程式碼的例子：

synchronized (this) { // 此處自動加鎖
  // x 是共享變數, 初始值 =10
  if (this.x < 12) {
    this.x = 12; 
  }  
} // 此處自動解鎖
  • 假設 x 的初始值是 8，執行緒 A 執行完程式碼塊後 x 的值會變成 12（執行完自動釋放鎖）
  • 執行緒 B 進入程式碼塊時，能夠看到執行緒 A 對 x 的寫操作，也就是執行緒 B 能夠看到 x==12。

5.執行緒 start() 規則

主執行緒 A 啟動子執行緒 B 後，子執行緒 B 能夠看到主執行緒在啟動子執行緒 B 前的操作。

這個規則也很容易理解，執行緒 A 呼叫執行緒 B 的 start() 方法（即線上程 A 中啟動執行緒 B），那麼該 start() 操作 Happens-Before 於執行緒 B 中的任意操作。

6.執行緒 join() 規則

執行緒 A 中，呼叫執行緒 B 的 join() 併成功返回，那麼執行緒 B 中的任意操作 Happens-Before 於該 join() 操作的返回。

使用JMM規則

我們現在已經基本講清楚了JAVA記憶體模型規範，以及裡面關鍵的Happens-Before規則，那有啥用呢？回到前言的問題中，我們是不是可以使用目前學到的關於JMM的知識去解決這個問題。

方案一： 使用volatile

根據JMM的第2條規則，主執行緒寫了volatile修飾的run變數，後面的t執行緒讀取的時候就可以看到了。

方案二：使用鎖

利用synchronized鎖的規則，主執行緒釋放鎖，那麼後續t執行緒加鎖就可以看到之前的內容了。

小結：

volatile 關鍵字

  • 保證可見性
  • 不保證原子性
  • 保證有序性（禁止指令重排）

volatile 修飾的變數進行讀操作與普通變數幾乎沒什麼差別，但是寫操作相對慢一些，因為需要在原生程式碼中插入很多記憶體屏障來保證指令不會發生亂序執行，但是開銷比鎖要小。volatile的效能遠比加鎖要好。

synchronized 關鍵字

  • 保證可見性
  • 不保證原子性
  • 保證有序性

加了鎖之後，只能有一個執行緒獲得到了鎖，獲得不到鎖的執行緒就要阻塞，所以同一時間只有一個執行緒執行，相當於單執行緒，由於資料依賴性的存在，單執行緒的指令重排是沒有問題的。

執行緒加鎖前，將清空工作記憶體中共享變數的值，使用共享變數時需要從主記憶體中重新讀取最新的值；執行緒解鎖前，必須把共享變數的最新值重新整理到主記憶體中。

總結

本文講解了JAVA併發的3大特性，可見性、有序性和原子性。從而引出了JAVA記憶體模型規範，這主要是為了解決併發情況下帶來的可見性和有序性問題，主要就是定義了一些規則，需要我們程式設計師懂得這些規則，然後根據實際場景去使用，就是使用volatile、synchronized、final關鍵字，主要final關鍵字也會讓其他執行緒可見，並且保證有序性。那麼具體他們底層的實現是什麼，是如何保證可見和有序的，我們後面詳細講解。

如果本文對你有幫助的話，請留下一個贊吧
更多技術幹活和學習資料盡在個人公眾號——JAVA旭陽

相關文章