Volatile可能是面試裏面必問的一個話題吧，對他的認知很多朋友也僅限於會用階段，今天我們換個角度去看看。
先來跟着丙丙來看一段demo的代碼：
你會發現，永遠都不會輸出有點東西這一段代碼，按道理線程改了flag變量，主線程也能訪問到的呀？
爲會出現這個情況呢？那我們就需要聊一下另外一個東西了。
JMM（JavaMemoryModel）
JMM：Java內存模型，是java虛擬機規範中所定義的一種內存模型，Java內存模型是標準化的，屏蔽掉了底層不同計算機的區別（注意這個跟JVM完全不是一個東西，只有還有小夥伴搞錯的）。
那正式聊之前，丙丙先大概科普一下現代計算機的內存模型吧。
現代計算機的內存模型
其實早期計算機中cpu和內存的速度是差不多的，但在現代計算機中，cpu的指令速度遠超內存的存取速度，由於計算機的存儲設備與處理器的運算速度有幾個數量級的差距，所以現代計算機系統都不得不加入一層讀寫速度儘可能接近處理器運算速度的高速緩存（Cache）來作爲內存與處理器之間的緩衝。
將運算需要使用到的數據複製到緩存中，讓運算能快速進行，當運算結束後再從緩存同步回內存之中，這樣處理器就無須等待緩慢的內存讀寫了。
基於高速緩存的存儲交互很好地解決了處理器與內存的速度矛盾，但是也爲計算機系統帶來更高的複雜度，因爲它引入了一個新的問題：緩存一致性（CacheCoherence）。
在多處理器系統中，每個處理器都有自己的高速緩存，而它們又共享同一主內存（MainMemory）。
然後我們可以聊一下JMM了。
JMM
Java內存模型(JavaMemoryModel)描述了Java程序中各種變量(線程共享變量)的訪問規則，以及在JVM中將變量，存儲到內存和從內存中讀取變量這樣的底層細節。
JMM有以下規定：
所有的共享變量都存儲於主內存，這裏所說的變量指的是實例變量和類變量，不包含局部變量，因爲局部變量是線程私有的，因此不存在競爭問題。
每一個線程還存在自己的工作內存，線程的工作內存，保留了被線程使用的變量的工作副本。
線程對變量的所有的操作(讀，取)都必須在工作內存中完成，而不能直接讀寫主內存中的變量。
不同線程之間也不能直接訪問對方工作內存中的變量，線程間變量的值的傳遞需要通過主內存中轉來完成。
本地內存和主內存的關係：
正是因爲這樣的機制，才導致了可見性問題的存在，那我們就討論下可見性的解決方案。
可見性的解決方案
加鎖
爲啥加鎖可以解決可見性問題呢？
因爲某一個線程進入synchronized代碼塊前後，線程會獲得鎖，清空工作內存，從主內存拷貝共享變量最新的值到工作內存成爲副本，執行代碼，將修改後的副本的值刷新回主內存中，線程釋放鎖。
而獲取不到鎖的線程會阻塞等待，所以變量的值肯定一直都是最新的。
Volatile修飾共享變量
開頭的代碼優化完之後應該是這樣的：
Volatile做了啥？
每個線程操作數據的時候會把數據從主內存讀取到自己的工作內存，如果他操作了數據並且寫會了，他其他已經讀取的線程的變量副本就會失效了，需要都數據進行操作又要再次去主內存中讀取了。
volatile保證不同線程對共享變量操作的可見性，也就是說一個線程修改了volatile修飾的變量，當修改寫回主內存時，另外一個線程立即看到最新的值。
是不是看着加一個關鍵字很簡單，但實際上他在背後含辛茹苦默默付出了不少，我從計算機層面的緩存一致性協議解釋一下這些名詞的意義。
之前我們說過當多個處理器的運算任務都涉及同一塊主內存區域時，將可能導致各自的緩存數據不一致，舉例說明變量在多個CPU之間的共享。
如果真的發生這種情況，那同步回到主內存時以誰的緩存數據爲準呢？
爲了解決一致性的問題，需要各個處理器訪問緩存時都遵循一些協議，在讀寫時要根據協議來進行操作，這類協議有MSI、MESI（IllinoisProtocol）、MOSI、Synapse、Firefly及DragonProtocol等。
聊一下Intel的MESI吧
MESI（緩存一致性協議）
當CPU寫數據時，如果發現操作的變量是共享變量，即在其他CPU中也存在該變量的副本，會發出信號通知其他CPU將該變量的緩存行置爲無效狀態，因此當其他CPU需要讀取這個變量時，發現自己緩存中緩存該變量的緩存行是無效的，那麼它就會從內存重新讀取。
至於是怎麼發現數據是否失效呢？
嗅探
每個處理器通過嗅探在總線上傳播的數據來檢查自己緩存的值是不是過期了，當處理器發現自己緩存行對應的內存地址被修改，就會將當前處理器的緩存行設置成無效狀態，當處理器對這個數據進行修改操作的時候，會重新從系統內存中把數據讀到處理器緩存裏。
嗅探的缺點不知道大家發現了沒有？
總線風暴
由於Volatile的MESI緩存一致性協議，需要不斷的從主內存嗅探和cas不斷循環，無效交互會導致總線帶寬達到峯值。
所以不要大量使用Volatile，至於什麼時候去使用Volatile什麼時候使用鎖，根據場景區分。
我們再來聊一下指令重排序的問題
禁止指令重排序
什麼是重排序?
爲了提高性能，編譯器和處理器常常會對既定的代碼執行順序進行指令重排序。
重排序的類型有哪些呢？源碼到最終執行會經過哪些重排序呢？
一個好的內存模型實際上會放鬆對處理器和編譯器規則的束縛，也就是說軟件技術和硬件技術都爲同一個目標，而進行奮鬥：在不改變程序執行結果的前提下，儘可能提高執行效率。
JMM對底層儘量減少約束，使其能夠發揮自身優勢。
因此，在執行程序時，爲了提高性能，編譯器和處理器常常會對指令進行重排序。
一般重排序可以分爲如下三種：
-
編譯器優化的重排序。編譯器在不改變單線程程序語義的前提下，可以重新安排語句的執行順序;
-
指令級並行的重排序。現代處理器採用了指令級並行技術來將多條指令重疊執行。如果不存在數據依賴性，處理器可以改變語句對應機器指令的執行順序;
-
內存系統的重排序。由於處理器使用緩存和讀/寫緩衝區，這使得加載和存儲操作看上去可能是在亂序執行的。
這裏還得提一個概念，as-if-serial。
as-if-serial
不管怎麼重排序，單線程下的執行結果不能被改變。
編譯器、runtime和處理器都必須遵守as-if-serial語義。
那Volatile是怎麼保證不會被執行重排序的呢？
內存屏障
java編譯器會在生成指令系列時在適當的位置會插入內存屏障指令來禁止特定類型的處理器重排序。
爲了實現volatile的內存語義，JMM會限制特定類型的編譯器和處理器重排序，JMM會針對編譯器制定volatile重排序規則表：
需要注意的是：volatile寫是在前面和後面分別插入內存屏障，而volatile讀操作是在後面插入兩個內存屏障。
寫
讀
上面的我提過重排序原則，爲了提高處理速度，JVM會對代碼進行編譯優化，也就是指令重排序優化，併發編程下指令重排序會帶來一些安全隱患：如指令重排序導致的多個線程操作之間的不可見性。
如果讓程序員再去了解這些底層的實現以及具體規則，那麼程序員的負擔就太重了，嚴重影響了併發編程的效率。
從JDK5開始，提出了happens-before的概念，通過這個概念來闡述操作之間的內存可見性。
happens-before
如果一個操作執行的結果需要對另一個操作可見，那麼這兩個操作之間必須存在happens-before關係。
volatile域規則：對一個volatile域的寫操作，happens-before於任意線程後續對這個volatile域的讀。
如果現在我的變了flag變成了false，那麼後面的那個操作，一定要知道我變了。
聊了這麼多，我們要知道Volatile是沒辦法保證原子性的，一定要保證原子性，可以使用其他方法。
無法保證原子性
就是一次操作，要麼完全成功，要麼完全失敗。
假設現在有N個線程對同一個變量進行累加也是沒辦法保證結果是對的，因爲讀寫這個過程並不是原子性的。
要解決也簡單，要麼用原子類，比如AtomicInteger，要麼加鎖(記得關注Atomic的底層)。
應用
單例有8種寫法，我說一下里面比較特殊的一種，涉及Volatile的。
大家可能好奇爲啥要雙重檢查？如果不用Volatile會怎麼樣？
我先講一下禁止指令重排序的好處。
對象實際上創建對象要進過如下幾個步驟：
-
分配內存空間。
-
調用構造器，初始化實例。
-
返回地址給引用
上面我不是說了嘛，是可能發生指令重排序的，那有可能構造函數在對象初始化完成前就賦值完成了，在內存裏面開闢了一片存儲區域後直接返回內存的引用，這個時候還沒真正的初始化完對象。
但是別的線程去判斷instance！=null，直接拿去用了，其實這個對象是個半成品，那就有空指針異常了。
可見性怎麼保證的？
因爲可見性，線程A在自己的內存初始化了對象，還沒來得及寫回主內存，B線程也這麼做了，那就創建了多個對象，不是真正意義上的單例了。
上面提到了volatile與synchronized，那我聊一下他們的區別。
volatile與synchronized的區別
volatile只能修飾實例變量和類變量，而synchronized可以修飾方法，以及代碼塊。
volatile保證數據的可見性，但是不保證原子性(多線程進行寫操作，不保證線程安全);而synchronized是一種排他(互斥)的機制。
volatile用於禁止指令重排序：可以解決單例雙重檢查對象初始化代碼執行亂序問題。
volatile可以看做是輕量版的synchronized，volatile不保證原子性，但是如果是對一個共享變量進行多個線程的賦值，而沒有其他的操作，那麼就可以用volatile來代替synchronized，因爲賦值本身是有原子性的，而volatile又保證了可見性，所以就可以保證線程安全了。
總結
-
volatile修飾符適用於以下場景：某個屬性被多個線程共享，其中有一個線程修改了此屬性，其他線程可以立即得到修改後的值，比如booleanflag;或者作爲觸發器，實現輕量級同步。
-
volatile屬性的讀寫操作都是無鎖的，它不能替代synchronized，因爲它沒有提供原子性和互斥性。因爲無鎖，不需要花費時間在獲取鎖和釋放鎖_上，所以說它是低成本的。
-
volatile只能作用於屬性，我們用volatile修飾屬性，這樣compilers就不會對這個屬性做指令重排序。
-
volatile提供了可見性，任何一個線程對其的修改將立馬對其他線程可見，volatile屬性不會被線程緩存，始終從主 存中讀取。
-
volatile提供了happens-before保證，對volatile變量v的寫入happens-before所有其他線程後續對v的讀操作。
-
volatile可以使得long和double的賦值是原子的。
-
volatile可以在單例雙重檢查中實現可見性和禁止指令重排序，從而保證安全性。