volatile被稱之為輕量級的synchronized，即通過無鎖的方式保證可見性，而本文將通過自頂向下的方式深入剖析這個關鍵字的底層實現，希望對你有幫助。

共享變量操作不可見案例介紹

我們編寫一段多線程讀寫一個變量的代碼，t1一旦感知num被t2修改，就會結束循環，然而事實卻是這段代碼即使在t2完成修改之后，t1也像是感知不到變化一樣一直無限循環阻塞著：

private static int num = 0;

    public static void main(String[] args) throws InterruptedException {
        CountDownLatch countDownLatch = new CountDownLatch(2);

        Thread t1 = new Thread(() -> {
            while (num == 0) {

            }
            log.info("num已被修改為:1");
            countDownLatch.countDown();
        });


        Thread t2 = new Thread(() -> {
            try {
                Thread.sleep(2000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            num++;
            log.info("t2修改num為1");
            countDownLatch.countDown();
        });

        t1.start();
        t2.start();
        countDownLatch.await();

        log.info("執行結束");
    }

volatile保證可見性

于是我們將代碼增一個本文所引出的關鍵字volatile 加以修飾：

private volatile static int num = 0;

對應的我們給出輸出結果，如預期一樣線程修改完之后線程1就會感知到變化而結束循環：

23:54:04.040 [Thread-0] INFO MultiApplication - num已被修改為:1
23:54:04.040 [Thread-1] INFO MultiApplication - t2修改num為1
23:54:04.042 [main] INFO MultiApplication - 執行結束

詳解volatile工作原理

volatile底層實現和JMM內存模型息息相關，該模型規范了線程的本地變量(各個線程拿到共享變量num的副本)和主存(內存中的變量num)的關系，其規范通過happens-before等規約強制規范了JVM需要針對這幾個要求要做出不同的處理來配合處理器保證共享變量操作的可見性和有序性，這一點感興趣的讀者可以移步下面這篇文章了解一下JMM內存規范和避免指令重排序的實際落地實現：

按照JMM模型抽象的各種happens-before及其內存模型8大操作：volatile的變量的寫操作， happens-before后續讀該變量的代碼。

這就要求t1和t2修改num的時候，都必須從主存中先加載才能進行修改，以上述代碼為例，假設t1修改了num的值，完成后就必須將最新的結果寫回主存中，而t2收到這個修改的通知后必須從主內存中拉取最新的結果才能進行操作：

上述這個流程只是JMM模型的抽象，也就是JVM便于讓程序員理解的一種模型，不是實際的實現， 對應的我們通過jitwatch查看volatile修飾的變量num進行累加的代碼：

private volatile static int num = 0;

    public static void main(String[] args) throws InterruptedException {
        num++;
    }

從匯編碼可以看出，匯編指令用到了一個lock的關鍵字，這就是保證并發編程可見性的關鍵：

0x00000000038ca0a1: lock addl $0x0,(%rsp)  ;*putstatic num
                                           ; - org.example.Main::main@5 (line 10)
0x00000000038ca0a6: mov 0x68(%r10),%r11d
0x00000000038ca0aa: inc %r11d
0x00000000038ca0ad: mov %r11d,0x68(%r10)
0x00000000038ca0b1: lock addl $0x0,(%rsp)  ;*putstatic num

通過查IA-32架構軟件開發者手冊可知，Lock前綴的指令在多核處理器下會引發了兩件事情：

• 將當前變量num從當前處理器的緩存行(cache-line)寫回內存。
• 通知其他處理器該變量已被修改，其他處理器cache-line中的num值全部變為invalid(無效)。

這也就是我們Intel 64著名的MESI協議，將該實現代入我們的代碼，假設線程1的num被CPU-0的處理，線程2被CPU-1處理，實際上底層的實現是：

• t1獲取共享變量num的值，此時并沒有其他核心上的線程獲取，狀態為E(exclusive)。
• t2啟動也獲取到num的值，此時總線嗅探到另一個CPU也有這個變量的緩存，所以兩個CPU緩存行都設置為S(shard)。
• t2修改num的值，通過總線嗅探機制發起通知，t1的線程收到消息后，將緩存行變量設置為I(invalid)。
• t1需要輸出結果，因為看到自己變量是無效的，于是通知總線讓t1將結果寫回內存，自己重新加載。

更多關于MESI協議的實現細節，感興趣的讀者可以參考筆者的這篇文章：《CPU 緩存一致性問題深度解析》

volatile如何禁止指令重排序

而volatile不僅可以保證可見性，還可以避免指令重排序，底層同樣是通過JMM規約，禁止特定編譯器進行有風險的重排序，以及在生成字節序列時插入內存屏障避免CPU重排序解決問題。

我們不妨看一段雙重鎖校驗的單例模式代碼，代碼如下所示可以看到經過雙重鎖校驗后,會進行new Singleton();

public class Singleton {

    private static Singleton uniqueInstance;

    private Singleton() {
    }

    public  static Singleton getUniqueInstance() {
        //先判斷對象是否已經實例過，沒有實例化過才進入加鎖代碼
        if (uniqueInstance == null) {
            //類對象加鎖
            synchronized (Singleton.class) {
                if (uniqueInstance == null) {
                    uniqueInstance = new Singleton();
                }
            }
        }
        return uniqueInstance;
    }
}

這一操作，這個對象創建的操作乍一看是原子性的，實際上編譯后再執行的機器碼會將其分為3個動作:

• 為引用uniqueInstance分配內存空間
• 初始化uniqueInstance
• uniqueInstance指向分配的內存空間

所以如果沒有volatile 禁止指令重排序的話，1、2、3的順序操作很可能變成1、3、2，進而可能出現下面這種情況：

• 線程1執行步驟1分配內存空間。
• 線程1執行步驟3讓引用指向這個內存空間。
• 線程2進入邏輯判斷發現uniqueInstance不為空直接返回，導致外部操作異常。

極端情況下，這種情況可能導致線程2外部操作到的可能是未初始化的對象，導致一些業務上的操作異常：

所以針對這種情況，我們需要增加volatile 關鍵字讓禁止這種指令重排序：

private volatile  static Singleton uniqueInstance;

按照JMM的happens-before原則volatile的變量的寫操作， happens-before后續讀該變量的代碼，這就會使的volatile操作可能實現如下幾點：

• 第二個針對volatile寫操作時，不管第一個操作是任何操作，都不能發生重排序。
• 第一個針對volatile讀的操作，后續volatile任何操作都不能重排序。
• 第一個volatile寫操作，后續volatile讀，不能進行重排序。

基于這套規范，在編譯器生成字節碼時，就會通過內存屏障的方式告知處理器禁止特定的重排序：

• 每個volatile寫后插入storestore，讓第一個寫優先于第二個寫，避免重排序后的寫(可以理解未變量計算)順序重排序導致的計數結果異常。
• 每個volatile寫后插入storeload，讓第一個寫先于后續讀，避免讀取異常。
• 每個volatile讀后加個loadstore，讓第一個讀操作先于第二個寫，避免讀寫重排序的異常。
• 每個volatile讀后加個loadload，讓第一個讀先于第二個讀，避免讀取順序重排序的異常。

volatile無法保證原子性

我們不妨看看下面這段代碼，首先我們需要了解一下num++這個操作在底層是如何實現的:

• 讀取num的值
• 對num進行+1
• 寫回內存中

基于jitwatch，我們看到的對應的匯編碼如下:

0x00000000038ca096: mov 0x68(%r10),%r8d
0x00000000038ca09a: inc %r8d
0x00000000038ca09d: mov %r8d,0x68(%r10)

這里蠻補充一句，關于jitwatch的安裝使用，感興趣的讀者可以參考這篇文章：《初探 JITWatch 從零開始的流程優化之旅》

我們查看代碼的運行結果，可以看到最終的值不一定是10000，由此可以得出volatile并不能保證原子性

public class VolatoleAdd {
    private static int num = 0;


   public void increase() {
        num++;
    }


    public static void main(String[] args) {

        int size = 10000;
        CountDownLatch downLatch = new CountDownLatch(1);
        ExecutorService threadPool = Executors.newFixedThreadPool(size);
        VolatoleAdd volatoleAdd = new VolatoleAdd();
        for (int i = 0; i < size; i++) {
            threadPool.submit(() -> {
                try {
                    downLatch.await();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                volatoleAdd.increase();


            });
        }

        downLatch.countDown();
        threadPool.shutdown();

        while (!threadPool.isTerminated()) {

        }

        System.out.println(VolatoleAdd.num);//9998

    }
}

而對應的解決方案我們可以通過synchronized、原子類、或者Lock相關實現類解決問題。

并發編程中三個重要特性

即原子性、有序性、可見性：

• 原子性：一組操作要么全部都完成，要么全部失敗，Java就是基于synchronized或者各種Lock實現原則性。
• 可見性：線程對于某些變量的操作，對于后續操作該變量的線程是立即可見的。Java基于synchronized或者各種Lock、volatile實現可見性，例如聲明volatile變量這就意味著Java代碼在操作該變量時每次都會從主內存中加載。
• 有序性：指令重排序只能保證串行語義一致性，并不能保證多線程情況下也一致，Java常常使用volatile禁止指令進行重排序優化。