Volatile與Java內存模型
被volatile修改的變量有2大特點
特點
- 可見性
- 有序性---排序要求，禁止重排
volatile的內存語義
- 當寫一個volatile變量時，JMM會把該線程對應的本地內存中的共享變量值立即刷新回主內存中。
- 當讀一個volatile變量時，JMM會把該線程對應的本地內存設置為無效，直接從主內存中讀取。
- 所以volatile的寫內存語義是直接刷新到主內存中，讀的內存語義是直接從主內存中讀取。
內存屏障
是什么
內存屏障（是一類同步屏障指令，是CPU或編譯器在對內存隨機訪問的操作中的一個同步點，使得此點之前的所有讀寫操作都執行后才可以開始執行此點之后的操作），避免代碼重排序。內存屏障其實就是一種JVM指令，Java內存模型的重排規則會要求Java編譯器在生成JVM指令時插入特定的內存屏障指令，通過這些內存屏障指令，volatile實現了Java內存模型中的可見性和有序性，但volatile無法保證原子性。
內存屏障之前的所有寫操作都要回寫到主內存，
內存屏障之后的所有讀操作都能獲得內存屏障之前的所有寫操作的最新結果(實現了可見性)。
因此重排序時，不允許把內存屏障之后的指令重排序到內存屏障之前。
一句話：對一個 volatile 域的寫, happens-before 于任意后續對這個 volatile 域的讀，也叫寫后讀。
面試中經常問到的，volatile憑什么可以保證可見性和有序性？？？靠的就是內存屏障 (Memory Barriers / Fences)
內存屏障的底層是什么?怎么實現的？
通過C++源碼分析 Unsafe.class / Unsafe.java / Unsafe.cpp / OrderAccess.hpp /
orderAccess_linux_x86.inline.hpp 其底層依托的就是 cpu的四個屏障指令。(底層系統級別的指令)
happens-before 之 volatile 變量規則
- 當第一個操作為volatile讀時，不論第二個操作是什么，都不能重排序。這個操作保證了volatile讀之后的操作不會被重排到volatile讀之前。
- 當第二個操作為volatile寫時，不論第一個操作是什么，都不能重排序。這個操作保證了volatile寫之前的操作不會被重排到volatile寫之后。
- 當第一個操作為volatile寫時，第二個操作為volatile讀時，不能重排。
JMM 就將內存屏障插?策略分為 4 種
寫
- 在每個 volatile 寫操作的前?插??個 StoreStore 屏障
- 在每個 volatile 寫操作的后?插??個 StoreLoad 屏障
讀
- 在每個 volatile 讀操作的后?插??個 LoadLoad 屏障
- 在每個 volatile 讀操作的后?插??個 LoadStore 屏障
volatile特性
保證可見性
保證不同線程對這個變量進行操作時的可見性，即變量一旦改變所有線程立即可見。
舉個栗子
public class VolatileSeeDemo{
static boolean flag = true; //不加volatile，沒有可見性
//static volatile boolean flag = true; //加了volatile，保證可見性
public static void main(String[] args){
new Thread(() -> {
System.out.println(Thread.currentThread().getName()+"\t come in");
while (flag){
}
System.out.println(Thread.currentThread().getName()+"\t flag被修改為false,退 出.....");
},"t1").start();
//暫停2秒鐘后讓main線程修改flag值
try { TimeUnit.SECONDS.sleep(2); } catch (InterruptedException e) { e.printStackTrace();}
flag = false;
System.out.println("main線程修改完成");
}
}不加volatile，沒有可見性，程序無法停止，加了volatile，保證可見性，程序可以停止。
原理解釋：
線程t1中為何看不到被主線程main修改為false的flag的值？
問題可能:
1. 主線程修改了flag之后沒有將其刷新到主內存，所以t1線程看不到。
2. 主線程將flag刷新到了主內存，但是t1一直讀取的是自己工作內存中flag的值，沒有去主內存中更新獲取flag最新的值。
我們的訴求：
1.線程中修改了工作內存中的副本之后，立即將其刷新到主內存；
2.工作內存中每次讀取共享變量時，都去主內存中重新讀取，然后拷貝到工作內存。
解決：
使用volatile修飾共享變量，就可以達到上面的效果，被volatile修改的變量有以下特點：
1. 線程中讀取的時候，每次讀取都會去主內存中讀取共享變量最新的值，然后將其復制到工作內存
2. 線程中修改了工作內存中變量的副本，修改之后會立即刷新到主內存
volatile變量的讀寫過程
前面學習JMM的時候我們已經了解了：關于主內存與工作內存之間具體的交互協議（即一個變量如何從主內存拷貝到工作內存、如何從工作內存同步回主內存之類的實現細節）
Java內存模型中定義了以下8種操作來完成，虛擬機實現時必須保證下面提及的每一種操作都是原子的、不可再分的。現在我們結合volatile關鍵字再來看一下。
read(讀取)→load(加載)→use(使用)→assign(賦值)→store(存儲)→write(寫入)→lock(鎖定)→unlock(解鎖)
read: 作用于主內存，將變量的值從主內存傳輸到工作內存，主內存到工作內存
load: 作用于工作內存，將read從主內存傳輸的變量值放入工作內存變量副本中，即數據加載
use: 作用于工作內存，將工作內存變量副本的值傳遞給執行引擎，每當JVM遇到需要該變量的字節碼指令時會執行該操作
assign: 作用于工作內存，將從執行引擎接收到的值賦值給工作內存變量，每當JVM遇到一個給變量賦值字節碼指令時會執行該操作
store: 作用于工作內存，將賦值完畢的工作變量的值寫回給主內存
write: 作用于主內存，將store傳輸過來的變量值賦值給主內存中的變量
由于上述只能保證單條指令的原子性，針對多條指令的組合性原子保證，沒有大面積加鎖，所以，JVM提供了另外兩個原子指令：
lock: 作用于主內存，將一個變量標記為一個線程獨占的狀態，只是寫時候加鎖，就只是鎖了寫變量的過程。
unlock: 作用于主內存，把一個處于鎖定狀態的變量釋放，然后才能被其他線程占用
不保證原子性
volatile變量的復合操作(如i++)不具有原子性
舉個栗子
class MyNumber {
volatile int number = 0;
public void addPlusPlus() {
number++;
}
}
public class VolatileNoAtomicDemo {
public static void main(String[] args) throws InterruptedException {
MyNumber myNumber = new MyNumber();
for (int i = 1; i <=10; i++) {
new Thread(() -> {
for (int j = 1; j <= 1000; j++) {
myNumber.addPlusPlus();
}
},String.valueOf(i)).start();
}
//暫停幾秒鐘線程
try { TimeUnit.SECONDS.sleep(1); } catch (InterruptedException e) { e.printStackTrace(); }
System.out.println(Thread.currentThread().getName() + "\t" + myNumber.number);
}
}從i++的字節碼角度說明
原子性指的是一個操作是不可中斷的，即使是在多線程環境下，一個操作一旦開始就不會被其他線程影響。i++; 不具備原子性，該操作是先讀取值，然后寫回一個新值，相當于原來的值加上1，分3步完成
如果第二個線程在第一個線程讀取舊值和寫回新值期間讀取i的域值，那么第二個線程就會與第一個線程一起看到同一個值，并執行相同值的加1操作，這也就造成了線程安全失敗，因此對于add方法必須使用synchronized修飾，以便保證線程安全。
結論
多線程環境下，"數據計算"和"數據賦值"操作可能多次出現，即操作非原子。若數據在加載之后，若主內存count變量發生修改之后，由于線程工作內存中的值在此前已經加載，從而不會對變更操作做出相應變化，即私有內存和公共內存中變量不同步，進而導致數據不一致。
對于volatile變量，JVM只是保證從主內存加載到線程工作內存的值是最新的，也就是數據加載時是最新的。由此可見volatile解決的是變量讀時的可見性問題，但無法保證原子性，對于多線程修改共享變量的場景必須使用加鎖同步。
面試題：為什么volatile不能保證原子性？
拿 i++的JVM的字節碼，i++分成三步，工作內存和主內存之間進行讀取寫入的時候，在在use和assign之間依然有極小的間隙期，在間隙期的時候是非原子操作。
read-load-use 和 assign-store-write 成為了兩個不可分割的原子操作，但是在use和assign之間依然有極小的一段真空期，有可能變量會被其他線程讀取，導致數據出現錯誤。
無論在哪一個時間點主內存的變量和任一工作內存的變量的值都是相等的。這個特性也就導致了volatile變量不適合參與到依賴當前值的運算。
指令禁重排
說明
重排序
重排序是指編譯器和處理器為了優化程序性能而對指令序列進行重新排序的一種手段，有時候會改變程序語句的先后順序
- 不存在數據依賴關系，可以重排序；
- 存在數據依賴關系，禁止重排序
但重排后的指令絕對不能改變原有的串行語義！這點在并發設計中必須要重點考慮！
重排序的分類和執行流程
- 編譯器優化的重排序： 編譯器在不改變單線程串行語義的前提下，可以重新調整指令的執行順序
- 指令級并行的重排序： 處理器使用指令級并行技術來講多條指令重疊執行，若不存在數據依賴性，處理器可以改變語句對應機器指令的執行順序
- 內存系統的重排序： 由于處理器使用緩存和讀/寫緩沖區，這使得加載和存儲操作看上去可能是亂序執行
數據依賴性：若兩個操作訪問同一變量，且這兩個操作中有一個為寫操作，此時兩操作間就存在數據依賴性。
存在數據依賴關系，禁止重排序===> 重排序發生，會導致程序運行結果不同。
編譯器和處理器在重排序時，會遵守數據依賴性，不會改變存在依賴關系的兩個操作的執行,但不同處理器和不同線程之間的數據性不會被編譯器和處理器考慮，其只會作用于單處理器和單線程環境。
底層實現是通過內存屏障
四大屏障的插入情況
- 在每一個volatile寫操作前面插入一個StoreStore屏障
- StoreStore屏障可以保證在volatile寫之前，其前面的所有普通寫操作都已經刷新到主內存中。
- 在每一個volatile寫操作后面插入一個StoreLoad屏障
- StoreLoad屏障的作用是避免volatile寫與后面可能有的volatile讀/寫操作重排序
- 在每一個volatile讀操作后面插入一個LoadLoad屏障
- LoadLoad屏障用來禁止處理器把上面的volatile讀與下面的普通讀重排序。
- 在每一個volatile讀操作后面插入一個LoadStore屏障
- LoadStore屏障用來禁止處理器把上面的volatile讀與下面的普通寫重排序。
如何正確使用volatile
- 單一賦值可以，but含復合運算賦值不可以(i++之類)
- volatile int a = 10
- volatile boolean flag = false
- 狀態標志，判斷業務是否結束
- 開銷較低的讀，寫鎖策略
/**
* 使用：當讀遠多于寫，結合使用內部鎖和 volatile 變量來減少同步的開銷
* 理由：利用volatile保證讀取操作的可見性；利用synchronized保證復合操作的原子性
*/
public class UseVolatileDemo{
private volatile int value;
public int getValue(){
return value; //利用volatile保證讀取操作的可見性
}
public synchronized int increment(){
return value++; //利用synchronized保證復合操作的原子性
}
}- DCL雙端鎖的發布
- 單例模式
總結
內存屏障是什么
內存屏障：是一種屏障指令，它是的cpu 或 編譯器 對屏障指令的 前 和 后 所發出的內存操作 執行一個排序的約束。也叫內存柵欄 或 柵欄指令。
內存屏障能干嘛
- 阻止屏障兩邊的指令重排序
- 寫數據時加入屏障，強制將線程私有工作內存的數據刷回主物理內存
- 讀數據時加入屏障，線程私有工作內存的數據失效，重新到主物理內存中獲取最新數據
內存屏障四大指令
- 在每一個volatile寫操作前面插入一個StoreStore屏障
- 在每一個volatile寫操作后面插入一個StoreLoad屏障
- 在每一個volatile讀操作后面插入一個LoadLoad屏障
- 在每一個volatile讀操作后面插入一個LoadStore屏障\
為什么我們寫了一個volatile關鍵字系統底層加入內存屏障？兩者怎么關聯的?
字節碼層面
ACC_VOLATILE 關鍵字
volatile可見性
volatile禁重排
寫指令
讀指令
一句話總結
