【Java并發】1. Java執行緒記憶體模型JMM及volatile相關知識-有解無憂

Java招聘知識合集：https://www.cnblogs.com/spzmmd/tag/Java招聘知識合集/
該系列用于匯集Java招聘需要的知識點

JMM

并發編程的三大特性：可見性(volatile)、有序性(volatile)、原子性(synchronized)

JMM跟CPU快取模型相似，是基于CPU快取模型來建立的，是標準化的，屏蔽了不同計算機的區別
JMM隸屬于JVM，定義了執行緒與主記憶體間的抽象關系，執行緒間的共享變數存放于主記憶體
每個執行緒均有私有作業記憶體(JMM抽象概念，實際不存在)，作業記憶體包含了該執行緒讀寫共享變數的副本，如果需要使得變數其他執行緒可訪問，需要加volatile修飾
執行緒實際操作的資料均為其作業記憶體的變數副本，所以會出現多執行緒里相同變數無法同步

JMM八大原子操作及volatile的可見性原理

JMM八大原子操作是：lock（鎖定）、unlock（解鎖）、read（讀取）、load（載入）、use（使用）、assign（賦值）、store（存盤）、write（寫入），
有如下案例，當flag有volatile修飾時，執行main函式，將輸出"flag值已改"；無volatile修飾時則A執行緒一直死回圈

public class Demo {
  // 沒有volatile修飾時，B執行緒對flag的改動，A執行緒是不可見的
  // 有volatile修飾時，B執行緒對flag的改動對A執行緒同樣可見
  private static boolean flag = false;
  public static void setFlag(){
    flag = true;
  }

  public static void main(String[] args){
    // A 執行緒，死回圈檢查flag的值，如果發生改變，則退出死回圈
    new Thread(() -> {
      while(!flag);
      System.out.println("flag值已改");
    }).start();
    // B 執行緒，改變flag的值
    new Thread(() -> {
      setFlag();
    }).start();
  }
}

在不加volatile修飾時，執行緒A的JMM操作流程
- 主記憶體里有共享變數flag=false
- read操作：將變數從主記憶體里讀取到執行緒的作業記憶體中
- load操作：將read讀取的值從作業記憶體放到作業記憶體里的副本變數中
- use操作：將副本變數傳遞給cpu使用(例子里A執行緒需要對falg進行取反操作，即使用use從副本變數里取得flag到cpu，再進行取反計算)
- 由于A執行緒在死回圈里，所以每次回圈檢查flag的值時，均會直接從副本變數里取得flag值
在不加volatile修飾時，執行緒B的JMM操作流程
- 主記憶體里有共享變數flag=false
- read操作：將變數從主記憶體里讀取到執行緒的作業記憶體中
- load操作：將read讀取的值從作業記憶體放到作業記憶體里的副本變數中
- use操作：將副本變數傳遞給cpu使用
- assign操作：B執行緒將flag設定為了true，此時觸發assign操作，將cpu計算所得值賦值給作業記憶體里的變數副本中
- store操作：將作業記憶體里的共享變數傳入主記憶體
- write操作：將store傳送的值寫道主記憶體變數里，至此主記憶體內flag=true
- 所以B執行緒對共享變數的修改，無法同步到A執行緒

圖片來自網路

volatile實作共享變數可見的原理
- 了解JVM的都知道volatile具備兩個特殊規則：
  - read、load、use動作必須連續出現
    這三個操作將資料從主記憶體讀取到cpu
  - assign、store、write動作必須連續出現
    這三個操作將資料從cpu寫回到主記憶體，也即是賦值陳述句會馬上更新到主記憶體中去
- 對變數加了volatile指令后，編譯成的匯編指令里會給賦值陳述句加入lock前綴指令，作用如下：
  - 被volatile修飾的變數，在某執行緒里其資料在作業記憶體中但凡出現變動，將被立即寫回主記憶體(相當于JMM操作assign、store、write必須連續出現)
  - 開啟快取一致性協議，資料回寫主記憶體的操作會引起其他執行緒里對應快取資料立即失效(作業記憶體里的對應變數失效)，此時其他執行緒需要重新從主記憶體讀取變數，這樣就確保了其他執行緒讀取到了最新的資料
  - 提供記憶體屏障功能，使lock指令前后的指令不能重新排序(volatile有序性的原理)

volatile的有序性原理

指令重排序

在不影響單執行緒執行結果(多執行緒不保證)的情況下，計算機為了優化性能，會對機器指令進行重新排序優化，重排序遵循as-if-serial和happens-before原則
- as-if-serial：重排序不影響單執行緒執行結果
- happens-before：定義了一些規則來遵循
物件半初始化問題

對于雙重檢查鎖單例模式，如下代碼，在執行lazy = new Singleton();陳述句時，是有可能被指令重排序的，假設A執行緒由于重排序，在未初始化完成的情況下，先給lazy賦值了，恰巧賦值后B執行緒也執行getInstance方法，獲取到了不為null的lazy變數，而這時候A執行緒卻并沒有初始化完畢單例物件，則B執行緒將使用半初始化的單例物件，造成錯誤，這就是經典的物件半初始化問題
對于此問題，只需要在單例變數lazy宣告時用volatile修飾即可解決，因為volatile禁止指令重排序
```
public class Singleton { 
  private volatile static Singleton lazy = null; 
  private Singleton(){} 
  public static Singleton getInstance(){ 
    if(lazy == null){ 
      synchronized (Singleton.class){ 
        if(lazy == null){ 
          //1.分配記憶體給這個物件 
          //2.初始化物件 
          //3.設定 lazy 指向剛分配的記憶體地址
          lazy = new Singleton(); 
        } 
      } 
    }
    return lazy; 
  } 
}
```
volatile關鍵字通過“記憶體屏障”來防止指令被重排序，記憶體屏障底層依舊是通過匯編的lock來實作的
- JMM記憶體屏障規范
  - LoadLoad：[Load1;LoadLoad;Load2] 保證load1的讀操作在load2及后續讀操作前執行
  - StoreStore：保證Store1寫操作已重繪至主記憶體，才進行后續的Store操作
  - LoadStore：保證Load1讀取結束后，后續的Store才進行
  - StoreLoad：保證Store1寫操作已重繪到主記憶體后，才進行后續的Load操作
- JVM要求volatile需要執行的記憶體屏障規范
  - 在每個volatile寫操作的前面插入一個 StoreStore 屏障，
  - 在每個volatile寫操作的后面插入一個 StoreLoad 屏障，
  - 在每個volatile讀操作的后面插入一個 LoadLoad 屏障，
  - 在每個volatile讀操作的后面插入一個 LoadStore 屏障，

交流&聯系

QQ群
歡迎加入Java交流群(qq群號: 776241689 )
歡迎關注公眾號"后端技術學習分享"獲取更多技術文章！
PS：小到Java后端技術、計算機基礎知識，大到微服務、Service Mesh、大資料等，都是本人研究的方向，我將定期在公眾號中分享技術干貨，希望以我一己之力，拋磚引玉，幫助朋友們提升技術能力，共同進步！
博客
- 掘金
- CSDN
- 博客園

原創不易，轉載請在開頭著名文章來源和作者，如果我的文章對您有幫助，請點贊/收藏/關注鼓勵支持一下吧??????

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/276898.html

標籤：Java

上一篇：合并兩個有序鏈表--參考歸并排序

下一篇：java 獲取properties的幾種方式