Java代碼：

instance=new Singleton();//instance是volatile變量

匯編代碼：

0x01a3de1d: movb >0x01a3de1d: movb $0x0,0x1104800(%esi);0x01a3de24: lock addl >addl $0x0,(%esp);<>

有volatile變量修飾的共享變量進行寫操作的時候會多第二行匯編代碼，通過查IA-32架構軟件開發者手冊可知，lock前綴的指令在多核處理器下會引發了兩件事情。

• 將當前處理器緩存行的數據會寫回到系統內存。
• 這個寫回內存的操作會引起在其他CPU里緩存了該內存地址的數據無效。

處理器為了提高處理速度，不直接和內存進行通訊，而是先將系統內存的數據讀到內部緩存（L1,L2或其他）后再進行操作，但操作完之后不知道何時會寫到內存，如果對聲明了Volatile變量進行寫操作，JVM就會向處理器發送一條Lock前綴的指令，將這個變量所在緩存行的數據寫回到系統內存。但是就算寫回到內存，如果其他處理器緩存的值還是舊的，再執行計算操作就會有問題，所以在多處理器下，為了保證各個處理器的緩存是一致的，就會實現緩存一致性協議，每個處理器通過嗅探在總線上傳播的數據來檢查自己緩存的值是不是過期了，當處理器發現自己緩存行對應的內存地址被修改，就會將當前處理器的緩存行設置成無效狀態，當處理器要對這個數據進行修改操作的時候，會強制重新從系統內存里把數據讀到處理器緩存里。

小貼士：

這兩件事情在IA-32軟件開發者架構手冊的第三冊的多處理器管理章節（第八章）中有詳細闡述。

Lock前綴指令會引起處理器緩存回寫到內存。Lock前綴指令導致在執行指令期間，聲言處理器的 LOCK# 信號。在多處理器環境中，LOCK# 信號確保在聲言該信號期間，處理器可以獨占使用任何共享內存。（因為它會鎖住總線，導致其他CPU不能訪問總線，不能訪問總線就意味著不能訪問系統內存），但是在最近的處理器里，LOCK＃信號一般不鎖總線，而是鎖緩存，畢竟鎖總線開銷比較大。在8.1.4章節有詳細說明鎖定操作對處理器緩存的影響，對于Intel486和Pentium處理器，在鎖操作時，總是在總線上聲言LOCK#信號。

但在P6和最近的處理器中，如果訪問的內存區域已經緩存在處理器內部，則不會聲言LOCK#信號。相反地，它會鎖定這塊內存區域的緩存并回寫到內存，并使用緩存一致性機制來確保修改的原子性，此操作被稱為“緩存鎖定”，緩存一致性機制會阻止同時修改被兩個以上處理器緩存的內存區域數據。

一個處理器的緩存回寫到內存會導致其他處理器的緩存無效。IA-32處理器和Intel 64處理器使用MESI（修改，獨占，共享，無效）控制協議去維護內部緩存和其他處理器緩存的一致性。在多核處理器系統中進行操作的時候，IA-32 和Intel 64處理器能嗅探其他處理器訪問系統內存和它們的內部緩存。它們使用嗅探技術保證它的內部緩存，系統內存和其他處理器的緩存的數據在總線上保持一致。例如在Pentium和P6 family處理器中，如果通過嗅探一個處理器來檢測其他處理器打算寫內存地址，而這個地址當前處理共享狀態，那么正在嗅探的處理器將無效它的緩存行，在下次訪問相同內存地址時，強制執行緩存行填充。

volatile使用誤區

volatile很容易被誤用，用來進行原子性操作。

與使用 synchronized相比，聲明一個 volatile 字段的區別在于沒有涉及到鎖操作。但特別的是對 volatile 字段進行“ ++ ”這樣的讀寫操作不會被當做原子操作執行。同時測試了字符串拼接的操作，也是不安全的。下文中有代碼已經證實 volatile 關鍵字修飾的變量在多線程寫的情況下不安全。

public class Counter {
//    public volatile static int count=0;


    public volatilestatic StringBuilder count=new StringBuilder("aa");


    public static void inc(String a){
        //這里延遲1毫秒，使得結果明顯
        try {
            Thread.sleep(1);
        } catch (InterruptedExceptione) {


        }
            count .append(a+"-");


    }


    public static void main(String[]args) {
        //同時啟動1000個線程，去進行i++計算，看看實際結果
        for (int i=1; i <=1000; i++) {
            int finalI=i;
            new Thread(new Runnable(){
                @Override
                publicvoid run() {
                   Counter.inc(String.valueOf(finalI));
                }
            }).start();
        }
        //這里每次運行的值都有可能不同,可能為1000
        System.out.println("運行結果:Counter.count=" + Counter.count);
    }
}

運行結果還是沒有我們期望的 aa-XX-1000，下面我們分析一下原因。

在 java 垃圾回收整理一文中，描述了 jvm 運行時刻內存的分配。其中有一個內存區域是 jvm 虛擬機棧，每一個線程運行時都有一個線程棧，線程棧保存了線程運行時候變量值信息。當線程訪問某一個對象時候值的時候，首先通過對象的引用找到對應在堆內存的變量的值，然后把堆內存變量的具體值 load 到線程本地內存中，建立一個變量副本，之后線程就不再和對象在堆內存變量值有任何關系，變量的具體值 load 到線程本地內存中，建立一個變量副本，之后線程就不再和對象在堆內存變量值有任何關系，而是直接修改副本變量的值，在修改完之后的某一個時刻（線程退出之前），自動把線程變量副本的值回寫到對象在堆中變量。這樣在堆中的對象的值就產生變化了。下面一幅圖描述這些交互。

read and load 從主存復制變量到當前工作內存

use and assign 執行代碼，改變共享變量值

store and write 用工作內存數據刷新主存相關內容， 其中 use and assign 可以多次出現，但是這一些操作并不是原子性，也就是在 read load 之后，如果主內存 count 變量發生修改之后，線程工作內存中的值由于已經加載，不會產生對應的變化，所以計算出來的結果會和預期不一樣。

對于 volatile 修飾的變量， jvm 虛擬機只是保證從主內存加載到線程工作內存的值是最新的。

例如假如線程 1 ，線程 2 在進行 read,load 操作中，發現主內存中 count 的值都是 5 ，那么都會加載這個最新的值

在線程 1 堆 count 進行修改之后，會 write 到主內存中，主內存中的 count 變量就會變為 6

線程 2 由于已經進行 read,load 操作，在進行運算之后，也會更新主內存 count的變量值為 6

導致兩個線程及時用 volatile 關鍵字修改之后，還是會存在并發的情況。

暫且不管在多線程下對 volatile 修飾的變量進行修改是否安全的，但是在多線程下對 volatile 修飾的變量進行讀操作是安全的，后一點是無可非議的。所以有了以下的結論： volatile 的適用場景當只有一個線程可以修改字段的值，其它線程可以隨時讀取，那么把字段聲明為 volatile 是合理的。

對性能的影響

內存屏障作為另一個CPU級的指令，沒有鎖那樣大的開銷，可以看之前文章

Disruptor為什么會如此快 - (一)鎖的成本的實驗結果。內核并沒有在多個線程間干涉和調度。

Disruptor如何使用內存屏障

下圖是Disruptor的AbsttactSequencer源碼截圖。

把Sequence定義為volatile 類型，供多線程共享。從截圖可以看出gatingSequences在對象實例化時進行了初始化(寫操作)，多處進行讀操作。這個與先前得出的結論頗為相似：volatile 的適用場景當只有一個線程可以修改字段的值，其它線程可以隨時讀取，那么把字段聲明為 volatile 是合理的。

小結

1、內存屏障是CPU指令，它允許你對數據什么時候對其他進程可見作出假設。在Java世界里，使用volatile關鍵字來實現內存屏障。使用volatile意味著不用被迫選擇加鎖，并且還能獲得性能的提升。

2、volatile的適用場景：當只有一個線程可以修改字段的值，其它線程可以隨時讀取，那么把字段聲明為 volatile 是合理的。

如果此文能幫小伙伴答疑解惑，請關注「架構那些事兒」

你的關注就是我的動力！