Java內存模型及Java關鍵字 volatile的做用和使用說明

先來看看這個關鍵字是什麼意思：
volatile  [ˈvɒlətaɪl]
adj. 易變的，不穩定的;
從翻譯上來看，volatile表示這個關鍵字是極易發生改變的。
volatile是java語言中，最輕量級的併發同步機制。這個關鍵字有以下兩個做用：
一、任何對volatile變量的修改，java中的其餘線程均可以感知到
二、volatile會禁止指令衝排序優化
　　在詳細講解volatile關鍵字以前，須要對java的內存模型有所理解，不然很難深刻的認識到volatile的做用。java 內存能夠像以前講的那樣，劃分爲堆、棧、方法區等等。可是從結合物理設備的角度來看，內存模型的佈局設計以下：

　　之因此這樣設計內存模型，是由於：相對於cpu的處理速度來講，物理內存的IO操做耗時很是嚴重。這就形成了cpu線程快速計算結束後，須要浪費大量的時間來等待內存IO的操做。爲了減小這種等待，java內存模型引入了工做內存的概念。工做內存主要是利用cpu或內存的寄存器、高速緩存等部分進行數據緩衝，減小cpu線程在內存IO期間的等待。
在java內存模型中，線程任何與數據有關的操做，都與而且只與工做內存相關。當線程需(防盜鏈接：本文首發自http://www.cnblogs.com/jilodream/ )要操做數據時，虛擬機會首先從主內存中讀取數據，而後放置一份拷貝的數據到工做內存中。接着java線程讀取工做內存中的拷貝數據，並操做獲得一個全新的數據，然將將這個數據放回到工做內存中，覆蓋原有的值。
　　這樣作能夠充分利用物理硬件的優點：
　　(1)主內存，存儲區域大，可是速度不行，適於存儲，不適於快速讀寫
　　(2)工做內存、存儲空間小，可是速度快，適於快速讀寫，不適於存儲
同時還避免了Java線程讀寫主內存中數據同步問題。由於主內存對於各個Java線程都是可見的。若是java線程併發操做，就會致使主內存中的數據須要進行同步保護，不然就會出現錯誤的語義。
　　可是這樣作仍然會有一個問題：工做內存中的數據是拷貝數據。在Java線程操做的過程當中，主內存中的數據可能已經發生改變，Java線程至關因而在用過期的值在計算和回寫。這個問題就是數據稱之爲「同步」的含義所在，也是鎖要處理的可見性的問題（之後有文章我會專門講這個問題）。
如何解決這個問題呢？
　　只能是經過「鎖」的形式來處理。volatile關鍵字的做用之一，就是造成這樣一個「鎖」：
　　若是一個變量被定義了volatile，那麼每次Java線程在寫入這個變量時，都會加入一個「lock addl $Ox0"的操做指令。這樣會造成一個「內存屏障」，當cpu將這條指令寫入到主內存時，會告訴其餘存有這份指令的工做內存加一個標識。表示這個變量已經發生了變化，當前工做內存中存儲的拷貝數據已通過時（這個過程被稱之爲內核CacheInvalidate)。當其餘線程須要使用該變量來操做時，系統會由於這個標識斷定當前工做內存中的數據已通過時。從而主動刷新主內存中的值到本身下邊的工做內存中。因爲在整個過程當中，系統已經在線程操做數據以前，提早刷新了變量的值，因此線程沒法看到已通過時的數據的。所以從表現上來看，能夠認爲是不存在數據不一致的問題。
　　這裏須要專門強調下long、double型。對於內存模型中定義的指令來講，操做的數據都是32位的。若是數據是64位，那麼就須要兩次指令操做。對於虛擬機中64位數據類型：double、long型，就會由於須要兩次操做的時間差，致使其餘線程拿到的是一種修改的中間值。
　　可是volatile的內存屏障專門對這裏進行了處理，以保證這種中間值不會出如今其餘cpu的工做內存中。同時目前商業的虛擬機已經都對這個問題專門進行了處理：對64位數據的讀寫也採用原子操做。爲的就是防止long double這兩個經常使用類型，因爲沒有增長volatile關鍵字，而致使在工做內存中出現奇怪的值。
　　volatile的另一個做用是禁止指令重排序的優化
　　cpu線程在執行指令的過程當中，爲了保證速度更快，指令之間的順序每每是經過優化重排序之後的順序。爲了保證重排序的指令不會有任何的歧義而僅僅是在速度上有所提高，系統會保證指令優化之後執行的結果是一致的。也就是你所得到的結果與沒優化得到到的結果是同樣的，不存在差別。可是因爲指令順序發生了變化，因此係統是沒法保證這個過程當中，其餘的線程獲取到的數據是能正確表明當前狀態的。這裏最經典的就是單例模式下，實例初始化的問題。請參見文章：設計模式之單例模式 的第3個方法。
因爲指令重排，系統會在變量沒有初始化結束前，就已經給instance變量(防盜鏈接：本文首發自http://www.cnblogs.com/jilodream/ )賦予地址。這時候其餘線程獲取到的變量就是有問題的：instance!=null,可是裏邊的值卻沒有初始化完成。這裏就須要使用volatile關鍵字禁止指令重排序：只有在實例初始化完畢後，才賦予變量instance引用。
　　另一個常見的例子是：
　　線程B在刷新線程A的處理結果時，可能因爲線程A尚未對變量初始化完畢，卻提早刷新了變量，致使了線程B所獲取到的變量的狀態是錯誤的。
所以在定義多線程可見變量時，前邊必定要加volatile關鍵字，保證該變量不會被由於指令順序被優化，而致使其餘線程獲取到的值是無心義的。
關於Java語言的有序性在《深刻理解Java虛擬機》中有一句話，總結的很是好：若是在本線程內觀察，全部的操做都是有序的。若是在一個其它線程觀察本線程，則全部的操做都是無序的。
　　前邊是指，不管虛擬機怎麼優化指令，當前線程在執行的語義和結果上都應該是一致的。（「線程內表現爲串行的語義"Within-Thread-As-If-Serial-Semantics)。後邊是指指令會發生重排，其它線程中獲取到的值，不能表明什麼。
其實volatile的這兩個做用是互相關聯的：正是因爲volatile須要保證變量的可見性，所以不能將系統無序的中間指令結果反映到主內存中，讓其它線程拿去使用可見，因此須要禁止掉指令重排序。保證拿到的結果是反映出當前的執行狀態的。（這裏涉及到一個happens-before原則的概念，我會在後邊的文章中介紹）
volatile存在的問題
　　說了volatile的兩個做用，volatile也有自身的不足。那就是volatile不能保證原子性：
舉個前文講過的例子，volatile變量值被修改之後，會直接刷新到主內存中，而且其餘線程能感知到。可是其餘線程繼續使用這個變量進行計算時，卻不能保證其一直是最新的值。舉個經典例子

1 volatile int a=0；
2 int add()
3 {
4     a++;
5 }

　　兩個線程t1，t2前後執行add)方法，變量a發生了自增。可是a變量的最終結果多是1也多是2。這取決於t2讀取變量a的值是在第一個線程刷新a到主內存以前，仍是主內存以後。
a++操做最終在執行時，會執行三條指令:
一、從主內存中讀取a值
二、a=a+1
三、寫入a的值到主內存中
　　當t1執行完第二步時，假如此時t2也讀取了a的值，則：主內存a=0；t1工做內存爲a=1；t2工做內存爲a=0；接下來t1執行回寫a操做，可是t2因爲已經讀取了a的值在工做內存中，所以t2在執行了a++操做後，仍然會回寫a=1到主內存中，這時儘管t1回寫後，生成內存屏障，可是t2已經讀取完畢，不會在自增階段再主動刷新。(防盜鏈接：本文首發自http://www.cnblogs.com/jilodream/ )不然若是須要執行連續的多條指令，每次都要主動刷新變量，一旦發生變化就重頭開始，這顯然是不可能的。這種狀況就須要程序員經過代碼本身來保證沒有問題。
這裏咱們能夠發現a變量不會由於volatile關鍵字，而使得自身的指令在外界看來是原子的。
所以volatile的使用存在以下限制場景：
　　一、volatile能夠寫入，可是寫入的值不該該依賴舊值
　　二、在確認某個狀態的不變性時，不能將volatile變量做爲因子。
　　這兩點在《java併發編程實戰》、《深刻理解java虛擬機》中都有提到相似的語義。第一點比較容易理解。第二點比較抽象，這裏解釋一下：就是說volatile適合於判斷是否已經改變了，而不適合判斷是否還沒改變，由於volatile變量發生改變，則必定發生了變化，volatile沒有發生變化，則不能說明必定沒有發生變化。
如前文，a若是仍然等於0.此時不能認爲：一、add方法沒有被調用過二、總體沒有被改變過。