JVM-JMM記憶體模型

本文章參考：黑馬程式員JVM

• 很多人將【java 記憶體結構】與【java 記憶體模型】傻傻分不清，【java 記憶體模型】是 Java Memory Model（JMM）的意思，
• 簡單的說，JMM 定義了一套在多執行緒讀寫共享資料時（成員變數、陣列）時，對資料的可見性、有序性、和原子性的規則和保障

1. 原子性

1-1 問題決議

提出問題：兩個執行緒對初始值為 0 的靜態變數一個做自增，一個做自減，各做 5000 次，結果是 0 嗎？

public class Demo1 {
    static int i = 0;

    public static void main(String[] args) throws InterruptedException {

        Thread t1 = new Thread(() -> {
            for (int j = 0; j < 50000; j++) {
                i++;
            }
        });
        Thread t2 = new Thread(() -> {
            for (int j = 0; j < 50000; j++) {
                i--;
            }
        });
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println(i);

    }
}

以上的結果可能是正數、負數、零，為什么呢？因為 Java 中對靜態變數的自增，自減并不是原子操作，

例如對于 i++ 而言（i 為靜態變數），實際會產生如下的 JVM 位元組碼指令：

getstatic i // 獲取靜態變數i的值
iconst_1 // 準備常量1
iadd // 加法
putstatic i // 將修改后的值存入靜態變數i

而對應 i-- 也是類似：

getstatic i // 獲取靜態變數i的值
iconst_1 // 準備常量1
isub // 減法
putstatic i // 將修改后的值存入靜態變數i

而 Java 的記憶體模型如下，完成靜態變數的自增，自減需要在主存和執行緒記憶體中進行資料交換：

如果是單執行緒以上 8 行代碼是順序執行（不會交錯）沒有問題：

// 假設i的初始值為0
getstatic i // 執行緒1-獲取靜態變數i的值 執行緒內i=0
iconst_1 // 執行緒1-準備常量1
iadd // 執行緒1-自增 執行緒內i=1
putstatic i // 執行緒1-將修改后的值存入靜態變數i 靜態變數i=1
getstatic i // 執行緒1-獲取靜態變數i的值 執行緒內i=1
iconst_1 // 執行緒1-準備常量1
isub // 執行緒1-自減 執行緒內i=0
putstatic i // 執行緒1-將修改后的值存入靜態變數i 靜態變數i=0

但多執行緒下這 8 行代碼可能交錯運行（為什么會交錯？思考一下）： 出現負數的情況：

// 假設i的初始值為0
getstatic i // 執行緒1-獲取靜態變數i的值 執行緒內i=0
getstatic i // 執行緒2-獲取靜態變數i的值 執行緒內i=0
iconst_1 // 執行緒1-準備常量1
iadd // 執行緒1-自增 執行緒內i=1
putstatic i // 執行緒1-將修改后的值存入靜態變數i 靜態變數i=1
iconst_1 // 執行緒2-準備常量1
isub // 執行緒2-自減 執行緒內i=-1
putstatic i // 執行緒2-將修改后的值存入靜態變數i 靜態變數i=-1

出現正數的情況：

// 假設i的初始值為0
getstatic i // 執行緒1-獲取靜態變數i的值 執行緒內i=0
getstatic i // 執行緒2-獲取靜態變數i的值 執行緒內i=0
iconst_1 // 執行緒1-準備常量1
iadd // 執行緒1-自增 執行緒內i=1
iconst_1 // 執行緒2-準備常量1
isub // 執行緒2-自減 執行緒內i=-1
putstatic i // 執行緒2-將修改后的值存入靜態變數i 靜態變數i=-1
putstatic i // 執行緒1-將修改后的值存入靜態變數i 靜態變數i=1

1-2 解決方法

（1）synchronized（同步關鍵字）

語法：

synchronized( 物件 ) {
    要作為原子操作代碼
}

用 synchronized 解決并發問題：

public class Demo1 {
    static int i = 0;
    static Object obj = new Object();

    public static void main(String[] args) throws InterruptedException {

        Thread t1 = new Thread(() -> {
            for (int j = 0; j < 50000; j++) {
                synchronized (obj) {
                    i++;
                }

            }
        });
        Thread t2 = new Thread(() -> {
            for (int j = 0; j < 50000; j++) {
                synchronized (obj) {
                    i--;
                }
            }
        });
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println(i);//輸出為0
    }
}

為什么需要這里的 obj 物件呢？

我們可以這樣理解：可以把 obj 想象成一個房間，執行緒 t1，t2 想象成兩個人，

當執行緒 t1 執行到 synchronized(obj) 時就好比 t1 進入了這個房間，并反手鎖住了門，在門內執行 count++ 代碼，

這時候如果 t2 也運行到了 synchronized(obj) 時，它發現門被鎖住了，只能在門外等待，

當 t1 執行完 synchronized{} 塊內的代碼，這時候才會解開門上的鎖，從 obj 房間出來，t2 執行緒這時才可以進入 obj 房間，反鎖住門，執行它的 count-- 代碼，

怎么從JVM角度理解呢？（這里參考《Java并發編程的藝術》里的一段話）

從JVM規范中可以看到Synchonized在JVM里的實作原理，JVM基于進入和退出Monitor物件來實作方法同步和代碼塊同步，但兩者的實作細節不一樣，代碼塊同步是使用monitorenter 和monitorexit指令實作的， monitorenter指令是在編譯后插入到同步代碼塊的開始位置，而monitorexit是插入到方法結束處和例外處，JVM要保證每個monitorenter必須有對應的monitorexit與之配對，任何物件都有一個monitor與之關聯，當且一個monitor被持有后，它將處于鎖定狀態，執行緒執行到monitorenter 指令時，將會嘗試獲取物件所對應的monitor的所有權，即嘗試獲得物件的鎖，

2.可見性

2-1 退不出的回圈

先來看一個現象，main 執行緒對 run 變數的修改對于 t 執行緒不可見，導致了 t 執行緒無法停止：

static boolean run = true;
public static void main(String[] args) throws InterruptedException {
    Thread t = new Thread(()->{
        while(run){
            // ....
        }
    });
    t.start();
    Thread.sleep(1000);
    run = false; // 執行緒t不會如預想的停下來
}

為什么會這樣？

1. 初始狀態， t 執行緒剛開始從主記憶體讀取了 run 的值到作業記憶體，

   

2. 因為 t 執行緒要頻繁從主記憶體中讀取 run 的值，JIT 編譯器會將 run 的值快取至自己作業記憶體中的高速快取中，減少對主存中 run 的訪問，提高效率

3. 1 秒之后，main 執行緒修改了 run 的值，并同步至主存，而 t 是從自己作業記憶體中的高速快取中讀取這個變數的值，結果永遠是舊值

   

2-2 解決辦法

（1）volatile（易變關鍵字）

它可以用來修飾成員變數和靜態成員變數，他可以避免執行緒從自己的作業快取中查找變數的值，必須到主存中獲取它的值，執行緒操作 volatile 變數都是直接操作主存，保證了共享變數的可見性，但不能保證原子性

public class Demo1 {
    volatile static boolean run = true;

    public static void main(String[] args) throws InterruptedException {
        Thread t = new Thread(() -> {
            while (run) {
// ....
            }
        });
        t.start();
        Thread.sleep(1000);
        run = false; // 執行緒t不會如預想的停下來
    }

}

注意：

synchronized 陳述句塊既可以保證代碼塊的原子性，也同時保證代碼塊內變數的可見性，但 缺點是synchronized是屬于重量級操作，性能相對更低

如果在前面示例的死回圈中加入 System.out.println() 會發現即使不加 volatile 修飾符，執行緒 t 也 能正確看到對 run 變數的修改了，想一想為什么？

進入println原始碼：

public void println(int x) {
    synchronized (this) {
        print(x);
        newLine();
    }
}

可以看出加了synchronized，保證了每次run變數都會從主存中獲取

3.有序性

3-1 詭異的結果

看下面一個栗子：

int num = 0;
boolean ready = false;
// 執行緒1 執行此方法
public void actor1(I_Result r) {
    if(ready) {
        r.r1 = num + num;
    } else {
        r.r1 = 1;
    }
}
// 執行緒2 執行此方法
public void actor2(I_Result r) {
    num = 2;
    ready = true;
}

看到這里可能聰明的小伙伴會想到有下面三種情況：

情況1：執行緒1 先執行，這時 ready = false，所以進入 else 分支結果為 1

情況2：執行緒2 先執行 num = 2，但沒來得及執行 ready = true，執行緒1 執行，還是進入 else 分支，結果為1

情況3：執行緒2 執行到 ready = true，執行緒1 執行，這回進入 if 分支，結果為 4（因為 num 已經執行過了）

但其實還有可能為0哦！😲

有可能還是：執行緒 2 執行 ready=true ，切換到執行緒1 ，進入if分支，相加為0，在切回執行緒 2 執行 num=2

這種現象就是指令重排

3-2 解決方法

volatile 修飾的變數，可以禁用指令重排

@JCStressTest
@Outcome(id = {"1", "4"}, expect = Expect.ACCEPTABLE, desc = "ok")
@Outcome(id = "0", expect = Expect.ACCEPTABLE_INTERESTING, desc = "!!!!")
@State
public class ConcurrencyTest {
    int num = 0;
    volatile boolean ready = false;//可以禁用指令重排
    @Actor
    public void actor1(I_Result r) {
        if(ready) {
            r.r1 = num + num;
        } else {
            r.r1 = 1;
        }
    }
    @Actor
    public void actor2(I_Result r) {
        num = 2;
        ready = true;
    }
}

3-3 有序性理解

同一執行緒內，JVM會在不影響正確性的前提下，可以調整陳述句的執行順序，看看下面的代碼：

static int i;
static int j;
// 在某個執行緒內執行如下賦值操作
i = ...; // 較為耗時的操作
j = ...;

可以看到，至于是先執行 i 還是 先執行 j ，對最終的結果不會產生影響，所以，上面代碼真正執行時， 既可以是

i = ...; // 較為耗時的操作
j = ...;

也可以是

j = ...;
i = ...; // 較為耗時的操作

這種特性稱之為指令重排，多執行緒下指令重排會影響正確性，例如著名的 double-checked locking 模式實作單例

public class Singleton {
    private Singleton() {
    }

    private static Singleton INSTANCE = null;

    public static Singleton getInstance() {
        //實體沒創建，才會進入內部的 synchronized 代碼塊
        if (INSTANCE == null) {
            //可能第一個執行緒在synchronized 代碼塊還沒創建完物件時，第二個執行緒已經到了這一步，所以里面還需要加上判斷
            synchronized (Singleton.class) {
                //也許有其他執行緒已經創建實體，所以再判斷一次
                if (INSTANCE == null) {
                    INSTANCE = new Singleton();
                }
            }
        }
        return INSTANCE;
    }
}

以上的實作特點是：

• 懶惰實體化
• 首次使用 getInstance() 才使用 synchronized 加鎖，后續使用時無需加鎖

上面的代碼看似已經很完美了，但是在多執行緒環境下還是會有指令重排問題！

INSTANCE = new Singleton() 對應的位元組碼為：

0: new #2 // class cn/itcast/jvm/t4/Singleton
3: dup
4: invokespecial #3 // Method "<init>":()V
7: putstatic #4 // Field INSTANCE:Lcn/itcast/jvm/t4/Singleton;

其中4 7 兩步順序不是固定的，也許 jvm 會優化為：先將參考地址賦值給 INSTANCE 變數后，再執行構造方法，如果兩個執行緒 t1,t2 按如下時間順序執行：

時間1 t1 執行緒執行到 INSTANCE = new Singleton();
時間2 t1 執行緒分配空間，為Singleton物件生成了參考地址（0 處）
時間3 t1 執行緒將參考地址賦值給 INSTANCE，這時 INSTANCE != null（7 處）
時間4 t2 執行緒進入getInstance() 方法，發現 INSTANCE != null（synchronized塊外），直接
回傳 INSTANCE
時間5 t1 執行緒執行Singleton的構造方法（4 處）

這時 t1 還未完全將構造方法執行完畢，如果在構造方法中要執行很多初始化操作，那么 t2 拿到的是將 是一個未初始化完畢的單例

對 INSTANCE 使用 volatile 修飾即可，可以禁用指令重排，但要注意在 JDK 5 以上的版本的 volatile 才 會真正有效

3-4 happens-before

happens-before 規定了哪些寫操作對其它執行緒的讀操作可見，它是可見性與有序性的一套規則總結，拋開以下 happens-before 規則，JMM 并不能保證一個執行緒對共享變數的寫，對于其它執行緒對該共享變數的讀可見

• 執行緒解鎖 m 之前對變數的寫，對于接下來對 m 加鎖的其它執行緒對該變數的讀可見

  static int x;
  static Object m = new Object();
  new Thread(()->{
      synchronized(m) {
          x = 10;
      }
  },"t1").start();
  new Thread(()->{
      synchronized(m) {
          System.out.println(x);
      }
  },"t2").start()
  

• 執行緒對 volatile 變數的寫，對接下來其它執行緒對該變數的讀可見

  volatile static int x;
  new Thread(()->{
      x = 10;
  },"t1").start();
  new Thread(()->{
      System.out.println(x);
  },"t2").start();
  

• 執行緒 start 前對變數的寫，對該執行緒開始后對該變數的讀可見

  static int x;
  x = 10;
  new Thread(()->{
      System.out.println(x);
  },"t2").start();
  

• 執行緒結束前對變數的寫，對其它執行緒得知它結束后的讀可見（比如其它執行緒呼叫 t1.isAlive() 或 t1.join()等待它結束）

  static int x;
  Thread t1 = new Thread(()->{
      x = 10;
  },"t1");
  t1.start();
  t1.join();
  System.out.println(x);
  

• 執行緒 t1 打斷 t2（interrupt）前對變數的寫，對于其他執行緒得知 t2 被打斷后對變數的讀可見（通 過t2.interrupted 或 t2.isInterrupted）

  static int x;
  public static void main(String[] args) {
      Thread t2 = new Thread(()->{
          while(true) {
              if(Thread.currentThread().isInterrupted()) {
                  System.out.println(x);//0
                  break;
              }
          }
      },"t2");
      t2.start();
      new Thread(()->{
          try {
              Thread.sleep(1000);
          } catch (InterruptedException e) {
              e.printStackTrace();
          }
          x = 10;
          t2.interrupt();
      },"t1").start();
      while(!t2.isInterrupted()) {
          Thread.yield();
      }
      System.out.println(x);//0
  }
  

• 對變數默認值（0，false，null）的寫，對其它執行緒對該變數的讀可見

• 具有傳遞性，如果 x hb-> y 并且 y hb-> z 那么有 x hb-> z

以上變數都是指共享變數即成員變數或靜態資源變數

4.CAS與原子類

4-1 CAS

CAS 即 Compare and Swap ，它體現的一種樂觀鎖的思想

比如多個執行緒要對一個共享的整型變數執行 +1 操作：

// 需要不斷嘗試
while(true) {
    int 舊值 = 共享變數 ; // 比如拿到了當前值 0
    int 結果 = 舊值 + 1; // 在舊值 0 的基礎上增加 1 ，正確結果是 1
    /*
	這時候如果別的執行緒把共享變數改成了 5，本執行緒的正確結果 1 就作廢了，這時候
	compareAndSwap 回傳 false，重新嘗試，直到：
	compareAndSwap 回傳 true，表示我本執行緒做修改的同時，別的執行緒沒有干擾
	*/
    if( compareAndSwap ( 舊值, 結果 )) {
        // 成功，退出回圈
    }
    //不一樣，繼續回圈嘗試
}

獲取共享變數時，為了保證該變數的可見性，需要使用 volatile 修飾，結合 CAS 和 volatile 可以實作無鎖并發，適用于競爭不激烈、多核 CPU 的場景下，

• 因為沒有使用 synchronized，所以執行緒不會陷入阻塞，這是效率提升的因素之一
• 但如果競爭激烈，可以想到重試必然頻繁發生，反而效率會受影響

CAS 底層依賴于一個 Unsafe 類來直接呼叫作業系統底層的 CAS 指令，下面是直接使用 Unsafe 物件進行執行緒安全保護的一個例子：

public class TestCAS {
    public static void main(String[] args) throws InterruptedException {
        DataContainer dc = new DataContainer();
        int count = 5;
        Thread t = new Thread(() -> {
            for (int i = 0; i < count; i++) {
                dc.increase();
            }
        });
        t.start();
        t.join();
        System.out.println(dc.getData());
    }
}

class DataContainer {
    private volatile int data;
    static final Unsafe unsafe;
    static final long DATA_OFFSET;

    static {
        try {
            // Unsafe 物件不能直接呼叫，只能通過反射獲得
            Field theUnsafe = Unsafe.class.getDeclaredField("theUnsafe");
            theUnsafe.setAccessible(true);
            unsafe = (Unsafe) theUnsafe.get(null);
        } catch (NoSuchFieldException | IllegalAccessException e) {
            throw new Error(e);
        }
        try {
            // data 屬性在 DataContainer 物件中的偏移量，用于 Unsafe 直接訪問該屬性
            DATA_OFFSET =
                    unsafe.objectFieldOffset(DataContainer.class.getDeclaredField("data"));
        } catch (NoSuchFieldException e) {
            throw new Error(e);
        }
    }

    public void increase() {
        int oldValue;
        while (true) {
            // 獲取共享變數舊值，可以在這一行加入斷點，修改 data 除錯來加深理解
            oldValue = data;
            // cas 嘗試修改 data 為 舊值 + 1，如果期間舊值被別的執行緒改了，回傳 false
            if (unsafe.compareAndSwapInt(this, DATA_OFFSET, oldValue, oldValue +
                    1)) {
                return;
            }
        }
    }

    public void decrease() {
        int oldValue;
        while (true) {
            oldValue = data;
            if (unsafe.compareAndSwapInt(this, DATA_OFFSET, oldValue, oldValue -
                    1)) {
                return;
            }
        }
    }

    public int getData() {
        return data;
    }
}

4-2 樂觀鎖與悲觀鎖

• CAS 是基于樂觀鎖的思想：最樂觀的估計，不怕別的執行緒來修改共享變數，就算改了也沒關系，我吃虧點再重試唄，
• synchronized 是基于悲觀鎖的思想：最悲觀的估計，得防著其它執行緒來修改共享變數，我上了鎖你們都別想改，我改完了解開鎖，你們才有機會

4-3 原子操作類

juc（java.util.concurrent）中提供了原子操作類，可以提供執行緒安全的操作，例如：AtomicInteger、 AtomicBoolean等，它們底層就是采用 CAS 技術 + volatile 來實作的， 可以使用 AtomicInteger 改寫之前的例子：

public class TestCAS {
    //創建原子整數物件
    private static AtomicInteger i = new AtomicInteger(0);

    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(() -> {
            for (int j = 0; j < 5000; j++) {
                i.getAndIncrement(); //獲取并且自增 i++
            }
        });
        Thread t2 = new Thread(() -> {
            for (int j = 0; j < 5000; j++) {
                i.getAndDecrement(); //獲取并且自減 i--
            }
        });
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println(i);//0
    }
}

5.synchronized 優化

Java HotSpot 虛擬機中，每個物件都有物件頭（包括 class 指標和 Mark Word），Mark Word 平時存盤這個物件的哈希碼 、 分代年齡 ，當加鎖時，這些資訊就根據情況被替換為標記位 、 執行緒鎖記錄指標 、 重量級鎖指標 、 執行緒ID 等內容

5-1 輕量級鎖

如果一個物件雖然有多執行緒訪問，但多執行緒訪問的時間是錯開的（也就是沒有競爭），那么可以使用輕量級鎖來優化，這就好比：

學生（執行緒 A）用課本占座，上了半節課，出門了（CPU時間到），回來一看，發現課本沒變，說明有競爭，繼續上他的課， 如果這期間有其它學生（執行緒 B）來了，會告知（執行緒A）有并發訪問，執行緒A 隨即升級為重量級鎖，進入重量級鎖的流程，

而重量級鎖就不是那么用課本占座那么簡單了，可以想象執行緒 A 走之前，把座位用一個鐵柵欄圍起來，假設有兩個方法同步塊，利用同一個物件加鎖

static Object obj = new Object();
public static void method1() {
    synchronized( obj ) {
        // 同步塊 A
        method2();
    }
}
public static void method2() {
    synchronized( obj ) {
        // 同步塊 B
    }
}

每個執行緒都的堆疊幀都會包含一個鎖記錄的結構，內部可以存盤鎖定物件的 Mark Word

5-2 鎖膨脹

如果在嘗試加輕量級鎖的程序中，CAS 操作無法成功，這時一種情況就是有其它執行緒為此物件加上了輕量級鎖（有競爭），這時需要進行鎖膨脹，將輕量級鎖變為重量級鎖，

5-3 重量鎖

重量級鎖競爭的時候，還可以使用自旋來進行優化，如果當前執行緒自旋成功（即這時候持鎖執行緒已經退出了同步塊，釋放了鎖），這時當前執行緒就可以避免阻塞，

在 Java 6 之后自旋鎖是自適應的，比如物件剛剛的一次自旋操作成功過，那么認為這次自旋成功的可能性會高，就多自旋幾次；反之，就少自旋甚至不自旋，總之，比較智能，

5-4 偏向鎖

輕量級鎖在沒有競爭時(就自己這個執行緒)，每次重入仍然需要執行CAS操作，Java 6中引入了偏向鎖來做進一步優化：只有第一次使用CAS將執行緒ID設定到物件的Mark Word頭，之后發現這個執行緒ID是自己的就表示沒有競爭，不用重新CAS

• 撤銷偏向需要將持鎖執行緒升級為輕量級鎖，這個程序中所有執行緒需要暫停（STW）
• 訪問物件的 hashCode 也會撤銷偏向鎖
• 如果物件雖然被多個執行緒訪問，但沒有競爭，這時偏向了執行緒 T1 的物件仍有機會重新偏向 T2，重偏向會重置物件的 Thread ID
• 撤銷偏向和重偏向都是批量進行的，以類為單位
• 如果撤銷偏向到達某個閾值，整個類的所有物件都會變為不可偏向的
• 可以主動使用 -XX:-UseBiasedLocking 禁用偏向鎖

5-5 其他優化

（1）減少上鎖時間

同步代碼塊中盡量短

（2）減少鎖的粒度

將一個鎖拆分為多個鎖提高并發度，例如：

• ConcurrentHashMap
• LongAdder 分為 base 和 cells 兩部分，沒有并發爭用的時候或者是 cells 陣列正在初始化的時候，會使用 CAS 來累加到base，有并發爭用，會初始化 cells 陣列，陣列有多少個 cell，就允許有多少執行緒并行修改，最后將陣列中每個 cell 累加，再加上 base 就是最終的值
• LinkedBlockingQueue 入隊和出隊使用不同的鎖，相對于LinkedBlockingArray只有一個鎖效率要高

（3）鎖粗化

多次回圈進入同步塊不如同步塊內多次回圈，另外 JVM 可能會做如下優化，把多次 append 的加鎖操作粗化為一次（因為都是對同一個物件加鎖，沒必要重入多次）

new StringBuffer().append("a").append("b").append("c");

（4）鎖消除

JVM 會進行代碼的逃逸分析，例如某個加鎖物件是方法內區域變數，不會被其它執行緒所訪問到，這時候就會被即時編譯器忽略掉所有同步操作，

（5）讀寫分離

如果撤銷偏向到達某個閾值，整個類的所有物件都會變為不可偏向的

• 可以主動使用 -XX:-UseBiasedLocking 禁用偏向鎖

最后喜歡的小伙伴別忘了一鍵三連哦🎈🎈🎈