原文地址：http://www.cnn6.net/html/java/2017729/202415.html
我們瞭解了synchronized是一個重量級的鎖，雖然JVM對它做了很多優化，而下面介紹的volatile則是輕量級的synchronized。如果一個變量使用volatile，則它比使用synchronized的成本更加低，因爲它不會引起線程上下文的切換和調度。Java語言規範對volatile的定義如下：
Java編程語言允許線程訪問共享變量，爲了確保共享變量能被準確和一致地更新，線程應該確保通過排他鎖單獨獲得這個變量。
上面比較繞口，通俗點講就是說一個變量如果用volatile修飾了，則Java可以確保所有線程看到這個變量的值是一致的，如果某個線程對volatile修飾的共享變量進行更新，那麼其他線程可以立馬看到這個更新，這就是所謂的線程可見性。
volatile雖然看起來比較簡單，使用起來無非就是在一個變量前面加上volatile即可，但是要用好並不容易（LZ承認我至今仍然使用不好，在使用時仍然是模棱兩可）。
內存模型相關概念
理解volatile其實還是有點兒難度的，它與Java的內存模型有關，所以在理解volatile之前我們需要先了解有關Java內存模型的概念，這裏只做初步的介紹，後續LZ會詳細介紹Java內存模型。
操作系統語義
計算機在運行程序時，每條指令都是在CPU中執行的，在執行過程中勢必會涉及到數據的讀寫。我們知道程序運行的數據是存儲在主存中，這時就會有一個問題，讀寫主存中的數據沒有CPU中執行指令的速度快，如果任何的交互都需要與主存打交道則會大大影響效率，所以就有了CPU高速緩存。CPU高速緩存爲某個CPU獨有，只與在該CPU運行的線程有關。
有了CPU高速緩存雖然解決了效率問題，但是它會帶來一個新的問題：數據一致性。在程序運行中，會將運行所需要的數據複製一份到CPU高速緩存中，在進行運算時CPU不再也主存打交道，而是直接從高速緩存中讀寫數據，只有當運行結束後纔會將數據刷新到主存中。舉一個簡單的例子：
|
1
|
i++i++ |
當線程運行這段代碼時，首先會從主存中讀取i( i = 1)，然後複製一份到CPU高速緩存中，然後CPU執行 + 1 （2）的操作，然後將數據（2）寫入到告訴緩存中，最後刷新到主存中。其實這樣做在單線程中是沒有問題的，有問題的是在多線程中。如下：
假如有兩個線程A、B都執行這個操作（i++），按照我們正常的邏輯思維主存中的i值應該=3，但事實是這樣麼？分析如下：
兩個線程從主存中讀取i的值（1）到各自的高速緩存中，然後線程A執行+1操作並將結果寫入高速緩存中，最後寫入主存中，此時主存i==2,線程B做同樣的操作，主存中的i仍然=2。所以最終結果爲2並不是3。這種現象就是緩存一致性問題。
解決緩存一致性方案有兩種：
-
通過在總線加LOCK#鎖的方式
-
通過緩存一致性協議
但是方案1存在一個問題，它是採用一種獨佔的方式來實現的，即總線加LOCK#鎖的話，只能有一個CPU能夠運行，其他CPU都得阻塞，效率較爲低下。
第二種方案，緩存一致性協議（MESI協議）它確保每個緩存中使用的共享變量的副本是一致的。其核心思想如下：當某個CPU在寫數據時，如果發現操作的變量是共享變量，則會通知其他CPU告知該變量的緩存行是無效的，因此其他CPU在讀取該變量時，發現其無效會重新從主存中加載數據。
Java內存模型
上面從操作系統層次闡述瞭如何保證數據一致性，下面我們來看一下Java內存模型，稍微研究一下Java內存模型爲我們提供了哪些保證以及在Java中提供了哪些方法和機制來讓我們在進行多線程編程時能夠保證程序執行的正確性。
在併發編程中我們一般都會遇到這三個基本概念：原子性、可見性、有序性。我們稍微看下volatile
原子性
原子性：即一個操作或者多個操作 要麼全部執行並且執行的過程不會被任何因素打斷，要麼就都不執行。
原子性就像數據庫裏面的事務一樣，他們是一個團隊，同生共死。其實理解原子性非常簡單，我們看下面一個簡單的例子即可：
|
1
2
3
4
|
i
= 0;
---1j
= i ; ---2i++;
---3i
= j + 1;
---4 |
上面四個操作，有哪個幾個是原子操作，那幾個不是？如果不是很理解，可能會認爲都是原子性操作，其實只有1纔是原子操作，其餘均不是。
1—在Java中，對基本數據類型的變量和賦值操作都是原子性操作；
2—包含了兩個操作：讀取i，將i值賦值給j
3—包含了三個操作：讀取i值、i + 1 、將+1結果賦值給i；
4—同三一樣
在單線程環境下我們可以認爲整個步驟都是原子性操作，但是在多線程環境下則不同，Java只保證了基本數據類型的變量和賦值操作纔是原子性的（注：在32位的JDK環境下，對64位數據的讀取不是原子性操作*，如long、double）。要想在多線程環境下保證原子性，則可以通過鎖、synchronized來確保。
volatile是無法保證複合操作的原子性
可見性
可見性是指當多個線程訪問同一個變量時，一個線程修改了這個變量的值，其他線程能夠立即看得到修改的值。
在上面已經分析了，在多線程環境下，一個線程對共享變量的操作對其他線程是不可見的。
Java提供了volatile來保證可見性。
當一個變量被volatile修飾後，表示着線程本地內存無效，當一個線程修改共享變量後他會立即被更新到主內存中，當其他線程讀取共享變量時，它會直接從主內存中讀取。
當然，synchronize和鎖都可以保證可見性。
有序性
有序性：即程序執行的順序按照代碼的先後順序執行。
在Java內存模型中，爲了效率是允許編譯器和處理器對指令進行重排序，當然重排序它不會影響單線程的運行結果，但是對多線程會有影響。
Java提供volatile來保證一定的有序性。最著名的例子就是單例模式裏面的DCL（雙重檢查鎖）。這裏LZ就不再闡述了。
剖析volatile原理
JMM比較龐大，不是上面一點點就能夠闡述的。上面簡單地介紹都是爲了volatile做鋪墊的。
volatile可以保證線程可見性且提供了一定的有序性，但是無法保證原子性。在JVM底層volatile是採用“內存屏障”來實現的。
上面那段話，有兩層語義
-
保證可見性、不保證原子性
-
禁止指令重排序
第一層語義就不做介紹了，下面重點介紹指令重排序。
在執行程序時爲了提高性能，編譯器和處理器通常會對指令做重排序：
-
編譯器重排序。編譯器在不改變單線程程序語義的前提下，可以重新安排語句的執行順序；
-
處理器重排序。如果不存在數據依賴性，處理器可以改變語句對應機器指令的執行順序；
指令重排序對單線程沒有什麼影響，他不會影響程序的運行結果，但是會影響多線程的正確性。既然指令重排序會影響到多線程執行的正確性，那麼我們就需要禁止重排序。那麼JVM是如何禁止重排序的呢？這個問題稍後回答，我們先看另一個原則happens-before，happen-before原則保證了程序的“有序性”，它規定如果兩個操作的執行順序無法從happens-before原則中推到出來，那麼他們就不能保證有序性，可以隨意進行重排序。其定義如下：
-
同一個線程中的，前面的操作 happen-before 後續的操作。（即單線程內按代碼順序執行。但是，在不影響在單線程環境執行結果的前提下，編譯器和處理器可以進行重排序，這是合法的。換句話說，這一是規則無法保證編譯重排和指令重排）。
-
監視器上的解鎖操作 happen-before 其後續的加鎖操作。（Synchronized 規則）
-
對volatile變量的寫操作 happen-before 後續的讀操作。（volatile 規則）
-
線程的start() 方法 happen-before 該線程所有的後續操作。（線程啓動規則）
-
線程所有的操作 happen-before 其他線程在該線程上調用 join 返回成功後的操作。
-
如果 a happen-before b，b happen-before c，則a happen-before c（傳遞性）。
我們着重看第三點volatile規則：對volatile變量的寫操作 happen-before 後續的讀操作。爲了實現volatile內存語義，JMM會重排序，其規則如下：
對happen-before原則有了稍微的瞭解，我們再來回答這個問題JVM是如何禁止重排序的？
觀察加入volatile關鍵字和沒有加入volatile關鍵字時所生成的彙編代碼發現，加入volatile關鍵字時，會多出一個lock前綴指令。lock前綴指令其實就相當於一個內存屏障。內存屏障是一組處理指令，用來實現對內存操作的順序限制。volatile的底層就是通過內存屏障來實現的。下圖是完成上述規則所需要的內存屏障：
volatile暫且下分析到這裏，JMM體系較爲龐大，不是三言兩語能夠說清楚的，後面會結合JMM再一次對volatile深入分析。
總結
volatile看起來簡單，但是要想理解它還是比較難的，這裏只是對其進行基本的瞭解。volatile相對於synchronized稍微輕量些，在某些場合它可以替代synchronized，但是又不能完全取代synchronized，只有在某些場合才能夠使用volatile。使用它必須滿足如下兩個條件：
-
對變量的寫操作不依賴當前值；
-
該變量沒有包含在具有其他變量的不變式中。
volatile經常用於兩個兩個場景：狀態標記兩、double check
