總結
0-synchronized關鍵字的作用已經涵蓋了volatile所提供的作用
1-volatile 只能保證多線程對一個公用變量進行操作時的“可見性” 2-volatile 不能保證數據在多線程下“寫”的線程安全 3-volatile 最適用的場景：一個線程寫，多個線程讀
synchronized 和 volatile 的區別是什么？
作用：
synchronized 表示只有一個線程可以獲取作用對象的鎖，執行代碼，阻塞其他線程。
volatile 表示變量在 CPU 的寄存器中是不確定的，必須從主存中讀取。保證多線程環境下變量的可見性；禁止指令重排序。
區別：
- synchronized關鍵字實現的功能涵蓋了volatile，功能更強大，也更重量級。
- synchronized 可以作用於變量、方法、對象；volatile 只能作用於變量。
- synchronized 可以保證線程間的有序性（猜測是無法保證線程內的有序性，即線程內的代碼可能被 CPU 指令重排序）、原子性和可見性；volatile 只保證了可見性和有序性，無法保證原子性。
- synchronized 線程阻塞，volatile 線程不阻塞。
易錯：為什么synchronized代碼塊里的變量，不加上volatile關鍵字？
- 一個線程出synchronized同步代碼塊的時候，會把操作的結果刷回主存。下一個線程進synchronized同步代碼塊的時候，會再從主存讀取。
- 可以看出synchronized關鍵字的作用已經涵蓋了volatile所提供的作用，synchronized而且更強大，所以也更重量級。
- 也因此我們說，volatile是Java提供的一種輕量級的同步機制（不是輕量級的同步鎖）
---------------------------------
變量的內存可見性
volatile是Java提供的一種輕量級的同步機制，在並發編程中，它也扮演着比較重要的角色。同synchronized相比（synchronized通常稱為重量級鎖），volatile更輕量級，相比使用synchronized所帶來的龐大開銷，倘若能恰當的合理的使用volatile，自然是美事一樁。
為了能比較清晰徹底的理解volatile，我們一步一步來分析。首先來看看如下代碼
public class TestVolatile {
boolean status = false;
/**
* 狀態切換為true
*/
public void changeStatus(){
status = true;
}
/**
* 若狀態為true，則running。
*/
public void run(){
if(status){
System.out.println("running....");
}
}
}
上面這個例子，在多線程環境里，假設線程A執行changeStatus()方法后,線程B運行run()方法，可以保證輸出"running....."嗎？
答案是NO!
這個結論會讓人有些疑惑，可以理解。因為倘若在單線程模型里，先運行changeStatus方法，再執行run方法，自然是可以正確輸出"running...."的；但是在多線程模型中，是沒法做這種保證的。因為對於共享變量status來說，線程A的修改，對於線程B來講，是"不可見"的。也就是說，線程B此時可能無法觀測到status已被修改為true。那么什么是可見性呢？
所謂可見性，是指當一條線程修改了共享變量的值，新值對於其他線程來說是可以立即得知的。很顯然，上述的例子中是沒有辦法做到內存可見性的。
Java內存模型
為什么出現這種情況呢，我們需要先了解一下JMM（java內存模型）
java虛擬機有自己的內存模型（Java Memory Model，JMM），JMM可以屏蔽掉各種硬件和操作系統的內存訪問差異，以實現讓java程序在各種平台下都能達到一致的內存訪問效果。
JMM決定一個線程對共享變量的寫入何時對另一個線程可見，JMM定義了線程和主內存之間的抽象關系：共享變量存儲在主內存(Main Memory)中，每個線程都有一個私有的本地內存（Local Memory），本地內存保存了被該線程使用到的主內存的副本拷貝，線程對變量的所有操作都必須在工作內存中進行，而不能直接讀寫主內存中的變量。這三者之間的交互關系如下
需要注意的是，JMM是個抽象的內存模型，所以所謂的本地內存，主內存都是抽象概念，並不一定就真實的對應cpu緩存和物理內存。當然如果是出於理解的目的，這樣對應起來也無不可。
大概了解了JMM的簡單定義后，問題就很容易理解了，對於普通的共享變量來講，比如我們上文中的status，線程A將其修改為true這個動作發生在線程A的本地內存中，此時還未同步到主內存中去；而線程B緩存了status的初始值false，此時可能沒有觀測到status的值被修改了，所以就導致了上述的問題。那么這種共享變量在多線程模型中的不可見性如何解決呢？比較粗暴的方式自然就是加鎖，但是此處使用synchronized或者Lock這些方式太重量級了，有點炮打蚊子的意思。比較合理的方式其實就是volatile
volatile具備兩種特性，第一就是保證共享變量對所有線程的可見性。將一個共享變量聲明為volatile后，會有以下效應：
1.當寫一個volatile變量時，JMM會把該線程對應的本地內存中的變量強制刷新到主內存中去；
2.這個寫會操作會導致其他線程中的緩存無效。
上面的例子只需將status聲明為volatile，即可保證在線程A將其修改為true時，線程B可以立刻得知
volatile boolean status = false;
留意復合類操作
但是需要注意的是，我們一直在拿volatile和synchronized做對比，僅僅是因為這兩個關鍵字在某些內存語義上有共通之處，volatile並不能完全替代synchronized，它依然是個輕量級鎖，在很多場景下，volatile並不能勝任。看下這個例子：
package test;
import java.util.concurrent.CountDownLatch;
/**
* Created by chengxiao on 2017/3/18.
*/
public class Counter {
public static volatile int num = 0;
//使用CountDownLatch來等待計算線程執行完
static CountDownLatch countDownLatch = new CountDownLatch(30);
public static void main(String []args) throws InterruptedException {
//開啟30個線程進行累加操作
for(int i=0;i<30;i++){
new Thread(){
public void run(){
for(int j=0;j<10000;j++){
num++;//自加操作
}
countDownLatch.countDown();
}
}.start();
}
//等待計算線程執行完
countDownLatch.await();
System.out.println(num);
}
}
執行結果：
224291
針對這個示例，一些同學可能會覺得疑惑，如果用volatile修飾的共享變量可以保證可見性，那么結果不應該是300000么?
問題就出在num++這個操作上，因為num++不是個原子性的操作，而是個復合操作。我們可以簡單講這個操作理解為由這三步組成:
1.讀取
2.加一
3.賦值
所以，在多線程環境下，有可能線程A將num讀取到本地內存中，此時其他線程可能已經將num增大了很多，線程A依然對過期的num進行自加，重新寫到主存中，最終導致了num的結果不合預期，而是小於30000。
解決num++操作的原子性問題
針對num++這類復合類的操作，可以使用java並發包中的原子操作類原子操作類是通過循環CAS的方式來保證其原子性的。
/**
* Created by chengxiao on 2017/3/18.
*/
public class Counter {
//使用原子操作類
public static AtomicInteger num = new AtomicInteger(0);
//使用CountDownLatch來等待計算線程執行完
static CountDownLatch countDownLatch = new CountDownLatch(30);
public static void main(String []args) throws InterruptedException {
//開啟30個線程進行累加操作
for(int i=0;i<30;i++){
new Thread(){
public void run(){
for(int j=0;j<10000;j++){
num.incrementAndGet();//原子性的num++,通過循環CAS方式
}
countDownLatch.countDown();
}
}.start();
}
//等待計算線程執行完
countDownLatch.await();
System.out.println(num);
}
}
執行結果
300000
關於原子類操作的基本原理，會在后面的章節進行介紹，此處不再贅述。
禁止指令重排序
volatile還有一個特性：禁止指令重排序優化。
重排序是指編譯器和處理器為了優化程序性能而對指令序列進行排序的一種手段。但是重排序也需要遵守一定規則：
1.重排序操作不會對存在數據依賴關系的操作進行重排序。
比如：a=1;b=a; 這個指令序列，由於第二個操作依賴於第一個操作，所以在編譯時和處理器運行時這兩個操作不會被重排序。
2.重排序是為了優化性能，但是不管怎么重排序，單線程下程序的執行結果不能被改變
比如：a=1;b=2;c=a+b這三個操作，第一步（a=1)和第二步(b=2)由於不存在數據依賴關系，所以可能會發生重排序，但是c=a+b這個操作是不會被重排序的，因為需要保證最終的結果一定是c=a+b=3。
重排序在單線程模式下是一定會保證最終結果的正確性，但是在多線程環境下，問題就出來了，來開個例子，我們對第一個TestVolatile的例子稍稍改進，再增加個共享變量a
public class TestVolatile {
int a = 1;
boolean status = false;
/**
* 狀態切換為true
*/
public void changeStatus(){
a = 2;//1
status = true;//2
}
/**
* 若狀態為true，則running。
*/
public void run(){
if(status){//3
int b = a+1;//4
System.out.println(b);
}
}
}
假設線程A執行changeStatus后，線程B執行run，我們能保證在4處，b一定等於3么？
答案依然是無法保證！也有可能b仍然為2。上面我們提到過，為了提供程序並行度，編譯器和處理器可能會對指令進行重排序，而上例中的1和2由於不存在數據依賴關系，則有可能會被重排序，先執行status=true再執行a=2。而此時線程B會順利到達4處，而線程A中a=2這個操作還未被執行，所以b=a+1的結果也有可能依然等於2。
使用volatile關鍵字修飾共享變量便可以禁止這種重排序。若用volatile修飾共享變量，在編譯時，會在指令序列中插入內存屏障來禁止特定類型的處理器重排序
volatile禁止指令重排序也有一些規則，簡單列舉一下：
1.當第二個操作是voaltile寫時，無論第一個操作是什么，都不能進行重排序
2.當地一個操作是volatile讀時，不管第二個操作是什么，都不能進行重排序
3.當第一個操作是volatile寫時，第二個操作是volatile讀時，不能進行重排序