我們在上一篇文章講到，synchronized關鍵字保證了代碼同步性，同時有利於實現程序的安全性，但是同時也帶來性能下降的弊端！所以，如果不是必要的我們應該避免使用synchronized關鍵字，在一些情況下可以採用其他方式作爲替代！其中之一就是volatile。
1、什麼是緩存一致性？
關於緩存一致性，我在第一章就簡要的介紹過。緩存一致性的出現是因爲計算機內存模型導致的：爲了解決CPU的運算速度和內存讀取速度的巨大差異性，在主內存和CPU之間加了一層高速緩存，每個CPU都有各自的高速緩存，但是這就帶來共享數據由不同線程讀取到自身私有的高速緩存中時，分別操作並返回到高速緩存從而帶來共享數據被修改的數據出現重複或者覆蓋的現象，這個也就是我們從上層看到的多線程的線程安全帶來的問題！在計算機底層稱之爲緩存一致性問題，爲了解決緩存一致性問題，主要通過下面兩種方式：
···1）通過在總線加LOCK#鎖的方式
···2）通過緩存一致性協議
這2種方式都是硬件層面上提供的方式。
在早期的CPU當中，是通過在總線上加LOCK#鎖的形式來解決緩存不一致的問題。因爲CPU和其他部件進行通信都是通過總線來進行的，如果對總線加LOCK#鎖的話，也就是說阻塞了其他CPU對其他部件訪問（如內存），從而使得只能有一個CPU能使用這個變量的內存。比如上面例子中 如果一個線程在執行 i = i +1，如果在執行這段代碼的過程中，在總線上發出了LCOK#鎖的信號，那麼只有等待這段代碼完全執行完畢之後，其他CPU才能從變量i所在的內存讀取變量，然後進行相應的操作。這樣就解決了緩存不一致的問題。
但是會有一個問題，由於在鎖住總線期間，其他CPU無法訪問內存，導致效率低下。所以就出現了緩存一致性協議。最出名的就是Intel 的MESI協議，MESI協議保證了每個緩存中使用的共享變量的副本是一致的。它核心的思想是：當CPU寫數據時，如果發現操作的變量是共享變量，即在其他CPU中也存在該變量的副本，會發出信號通知其他CPU將該變量的緩存行置爲無效狀態，因此當其他CPU需要讀取這個變量時，發現自己緩存中緩存該變量的緩存行是無效的，那麼它就會從內存重新讀取。
而volatile的設計原則就類似“緩存一致性”協議！
2、可見性、原子性、指令重排性？
在併發編程中有三個很重要的概念：可見性、原子性、指令重排性！這三個概念我前面的文章也已經簡略的敘述過了，這裏引用網上的一個講的很好例子Java併發編程：volatile關鍵字解析再來說明一下：
1.原子性
即一個操作或者多個操作 要麼全部執行並且執行的過程不會被任何因素打斷，要麼就都不執行。一個很經典的例子就是銀行賬戶轉賬問題：
比如從賬戶A向賬戶B轉1000元，那麼必然包括2個操作：從賬戶A減去1000元，往賬戶B加上1000元。
試想一下，如果這2個操作不具備原子性，會造成什麼樣的後果。假如從賬戶A減去1000元之後，操作突然中止。然後又從B取出了500元，取出500元之後，再執行 往賬戶B加上1000元 的操作。這樣就會導致賬戶A雖然減去了1000元，但是賬戶B沒有收到這個轉過來的1000元。所以這2個操作必須要具備原子性才能保證不出現一些意外的問題。
2.可見性
可見性是指當多個線程訪問同一個變量時，一個線程修改了這個變量的值，其他線程能夠立即看得到修改的值。
舉個簡單的例子，看下面這段代碼：
//線程1執行的代碼
int i = 0;
i = 10;
//線程2執行的代碼
j = i;假若執行線程1的是CPU1，執行線程2的是CPU2。由上面的分析可知，當線程1執行 i =10這句時，會先把i的初始值加載到CPU1的高速緩存中，然後賦值爲10，那麼在CPU1的高速緩存當中i的值變爲10了，卻沒有立即寫入到主存當中。
此時線程2執行 j = i，它會先去主存讀取i的值並加載到CPU2的緩存當中，注意此時內存當中i的值還是0，那麼就會使得j的值爲0，而不是10.
這就是可見性問題，線程1對變量i修改了之後，線程2沒有立即看到線程1修改的值。
3.有序性
有序性：即程序執行的順序按照代碼的先後順序執行。舉個簡單的例子，看下面這段代碼：
int i = 0;
boolean flag = false;
i = 1; //語句1
flag = true; //語句2上面代碼定義了一個int型變量，定義了一個boolean類型變量，然後分別對兩個變量進行賦值操作。從代碼順序上看，語句1是在語句2前面的，那麼JVM在真正執行這段代碼的時候會保證語句1一定會在語句2前面執行嗎？不一定，爲什麼呢？這裏可能會發生指令重排序（Instruction Reorder）。
下面解釋一下什麼是指令重排序，一般來說，處理器爲了提高程序運行效率，可能會對輸入代碼進行優化，它不保證程序中各個語句的執行先後順序同代碼中的順序一致，但是它會保證程序最終執行結果和代碼順序執行的結果是一致的。
比如上面的代碼中，語句1和語句2誰先執行對最終的程序結果並沒有影響，那麼就有可能在執行過程中，語句2先執行而語句1後執行。
但是要注意，雖然處理器會對指令進行重排序，但是它會保證程序最終結果會和代碼順序執行結果相同，那麼它靠什麼保證的呢？再看下面一個例子：
int a = 10; //語句1
int r = 2; //語句2
a = a + 3; //語句3
r = a*a; //語句4這段代碼有4個語句，那麼可能的一個執行順序是： 語句1 語句2 語句3 語句4；
那麼可不可能是這個執行順序呢： 語句2 語句1 語句4 語句3？
不可能，因爲處理器在進行重排序時是會考慮指令之間的數據依賴性，如果一個指令Instruction 2必須用到Instruction 1的結果，那麼處理器會保證Instruction 1會在Instruction 2之前執行。雖然重排序不會影響單個線程內程序執行的結果，但是多線程呢？下面看一個例子：
//線程1:
context = loadContext(); //語句1
inited = true; //語句2
//線程2:
while(!inited ){
sleep()
}
doSomethingwithconfig(context);上面代碼中，由於語句1和語句2沒有數據依賴性，因此可能會被重排序。假如發生了重排序，在線程1執行過程中先執行語句2，而此是線程2會以爲初始化工作已經完成，那麼就會跳出while循環，去執行doSomethingwithconfig(context)方法，而此時context並沒有被初始化，就會導致程序出錯。從上面可以看出，指令重排序不會影響單個線程的執行，但是會影響到線程併發執行的正確性。
也就是說，要想併發程序正確地執行，必須要保證原子性、可見性以及有序性。只要有一個沒有被保證，就有可能會導致程序運行不正確。
3、volatile做到了哪些層面？
volatile實現了三個原則中的兩個：可見性和禁止指令重排性！因爲上述已經對這兩個概念已經講得很清楚了，這裏只對可見性再次通過實例講解一下！被volatile修飾的變量，任何線程修改過後都會立即被同步到主內存中，當另一個線程去向自己的緩存中取用數據的時候，發現上次被緩存的數據是共享數據且已經被修改，於是會導致該緩存無效從而去取用主內存中的數據。這有什麼用呢？舉個例子：
//線程1
boolean stop = false;
while(!stop){
doSomething();
}
//線程2
stop = true;這個例子在實際編程中應用的很廣泛，通過標誌位來控制某些邏輯的實現，我們爲了達到的目的是這樣的：當線程2運行的時候，線程1的循環應立即停止！但是實際情況真的是這樣嗎？我們可以把程序寫完整驗證一下：
public class VolatileTest {
private static boolean stop;
public static void main(String[] args) throws InterruptedException {
Thread[] threads = new Thread[10];
for(int i=0;i<10;i++){
threads[i] = new Thread(new Runnable() {
@Override
public void run() {
stop = false;
while (!stop) {
System.out.println(Thread.currentThread().getName() + ",flag.stop爲" + stop + "，繼續運行");
}
System.out.println(Thread.currentThread().getName() + ",flag.stop爲" + stop + "，停止運行");
}
});
threads[i].start();
}
Thread threadflag = new Thread(new Runnable() {
@Override
public void run() {
stop = true;
System.out.println(Thread.currentThread().getName() + ",flag.stop爲" + stop + "，即將終止運行........");
}
},"threadFlag");
threadflag.start();
}
}程序邏輯同樣很簡單，開啓10個循環線程，理論上當ThreadFlag線程運行的時候，10個線程應該立即結束，但是在我的測試中運行5次後（實際測試次數不一定每次都是同樣的）線程9一直在循環中而沒有被停止！這就說明，線程ThreadFlag的賦值操作並沒有對線程9生效，線程9一直讀取的還是自己緩存中的數據！當把flag變量加上volatile後，一方面被改變的變量會立即同步到主內存中，另一方面會強制是線程中共享變量的緩存在其他線程修改後失效，所以必須從主內存加載新的數據值，所以這種bug就會消失了。
4、volatile的實現原理是什麼？
是什麼決定了volatile的這種特性呢？我們通過JIT的彙編代碼來看一下（摘自《深入理解JVM虛擬機》）：
“觀察加入volatile關鍵字和沒有加入volatile關鍵字時所生成的彙編代碼發現，加入volatile關鍵字時，會多出一個lock前綴指令，lock前綴指令實際上相當於一個內存屏障（也成內存柵欄），內存屏障會提供3個功能：
···1）它確保指令重排序時不會把其後面的指令排到內存屏障之前的位置，也不會把前面的指令排到內存屏障的後面；即在執行到內存屏障這句指令時，在它前面的操作已經全部完成；
···2）它會強制將對緩存的修改操作立即寫入主存；
···3）如果是寫操作，它會導致其他CPU中對應的緩存行無效。
5、爲什麼volatile可見性不保證線程安全？
一個很容易令人迷惑的情況是，爲什麼volatile的可見性不能保證線程安全呢？簡要的回答就是：因爲volatile不能保證原子性！但是實際數據操作中很多不是原子性操作，例如i++等！舉個例子：
public class Test {
public volatile int inc = 0;
public void increase() {
inc++;
System.out.println(inc);
}
public static void main(String[] args) {
final Test test = new Test();
for(int i=0;i<10;i++){
new Thread(){
public void run() {
for(int j=0;j<1000;j++)
test.increase();
};
}.start();
}
}我們期望得到的結果是10000，但是運行不到10次下來我們發現，竟然出現最後結果9999;原因就是i++不具有原子性，這在第一篇文章也已經有敘述，把字節碼指令編譯的結果從第一篇文章拿來一下可以看到i++被拆分了四條命令：
源碼：
public class Yuanzi {
static int a = 0;
public static void main(String[] args) {
a ++;
}
}字節碼：
public static void main(java.lang.String[]);
Code:
0: getstatic #2 // Field a:I
3: iconst_1
4: iadd
5: putstatic #2 // Field a:I
8: return
static {};
Code:
0: iconst_0
1: putstatic #2 // Field a:I
4: return
}這回，我們這裏結合volatile來說明一下爲什麼可見性不能保證線程安全，因爲你可能回問：如果inc++的值立即同步到主內存並使得其他線程中緩存失效，那麼理論上應該不會出現緩存不一致的情況下！
假設某一時刻主內存的數據inc = 10：
···1、A線程先運行，執行inc++，但是由於inc++實際分爲四條指令，所以先A先執行第一條指令getstatic ，即從主內存加載inc = 10到自己的緩存中，然後阻塞；
···2、B線程開始運行，然後同樣加載到自己緩存中inc = 10，然後inc++，假設運行完成，並同步會主內存，inc=11。隨即阻塞；
···3、線程A開始運行，因爲已經讀取了inc的值，所以只能保證下一次讀取的時候從主內存中讀取，但是此次的inc的值（getstatic 棧頂的值）其實已經過期了，但是同樣做了inc++的操作，同步到主內存，這個時候inc=11;
所以還是出現了線程安全的問題！那麼怎麼才能保證inc++是原子性操作呢？答案就是Automatic類！這在下一章會講到！