volatile的作用

1，保證可見性

2，保證cpu指令順序執行

上面兩個特性就不過多解釋了

當volatile 修飾 int i 時，為什麼不是執行緒安全呢？

如圖：

由上，我們可以得出以下結論。

1. read和load階段：從主存複製變數到當前執行緒工作記憶體；
2. use和assign階段：執行程式碼，改變共享變數值；
3. store和write階段：用工作記憶體資料重新整理主存對應變數的值。

       在多執行緒環境中，use和assign是多次出現的，但這一操作並不是原子性，也就是在read和load之後，如果主記憶體count變數發生修改之後，執行緒工作記憶體中的值由於已經載入，不會產生對應的變化，也就是私有記憶體和公共記憶體中的變數不同步，所以計算出來的結果會和預期不一樣，也就出現了非執行緒安全問題。

      對於用volatile修飾的變數，JVM虛擬機器只是保證從主記憶體載入到執行緒工作記憶體的值是最新的，例如執行緒1和執行緒2在進行read和load的操作中，發現主記憶體中count的值都是5，那麼都會載入這個最新的值。也就是說，volatile關鍵字解決的是變數讀時的可見性問題 ，但無法保證原子性，對於多個執行緒訪問同一個例項變數還是需要加鎖同步。

例如下面方法 ：
void f1() { i++; }

cpu指令如下

void f1();
Code:
0: aload_0
1: dup
2: getfield #2; //Field i:I
5: iconst_1
6: iadd
7: putfield #2; //Field i:I
10: return
 

可見i++執行了多部操作, 從變數i中讀取讀取i的值 -> 值+1 -> 將+1後的值寫回i中,這樣在多執行緒的時候執行情況就類似如下了

Thread1             Thread2
r1 = i;             r3 = i;               
r2 = r1 + 1;        r4 = r3 + 1;
i = r2;             i = r4;

這樣會造成的問題就是 r1, r3讀到的值都是 0, 最後兩個執行緒都將 1 寫入 i, 最後 i 等於 1, 但是卻進行了兩次自增操作

可知加了volatile和沒加volatile都無法解決非原子操作的執行緒同步問題。

正確使用 volatile 的模式

很多併發性專家事實上往往引導使用者遠離 volatile 變數，因為使用它們要比使用鎖更加容易出錯。然而，如果謹慎地遵循一些良好定義的模式，就能夠在很多場合內安全地使用 volatile 變數。要始終牢記使用 volatile 的限制 —— 只有在狀態真正獨立於程式內其他內容時才能使用 volatile —— 這條規則能夠避免將這些模式擴充套件到不安全的用例。

對於這裡我的理解是，volatile可以用於多執行緒。但是使用必須保證，同一時間只有一個執行緒對volatile修飾的物件進行修改。其他執行緒只是讀取 volatile修飾的物件值。