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

歡迎關註專欄【JAVA併發】前言開篇一個例子，我看看都有誰會？如果不會的，或者不知道原理的，還是老老實實看完這篇文章吧。 @Slf4j(topic = "c.VolatileTest") public class VolatileTest { static boolean run = true; ...

歡迎關註專欄【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個步驟：

分配一塊記憶體 M；
在記憶體 M 上初始化 Singleton 對象；
然後 M 的地址賦值給 instance 變數。

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

分配一塊記憶體 M；
將 M 的地址賦值給 instance 變數；
最後在記憶體 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。

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

鎖的規則

這條規則是指對一個鎖的解鎖 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關鍵字也會讓其他線程可見，並且保證有序性。那麼具體他們底層的實現是什麼，是如何保證可見和有序的，我們後面詳細講解。