上篇文章我們講了synchronized的用法和實現原理，我們總愛說synchronized是重量級鎖，volatile是輕量級鎖。為什么volatile是輕量級鎖，體現在哪些方面？以及volatile的作用和實現原理是怎樣的？本篇帶你一塊學習一下。

1. volatile是什么？

volatile是Java提供的一種輕量級的同步機制。與synchronized修飾方法、代碼塊不同，volatile只用來修飾變量。并且與synchronized、ReentrantLock等重量級鎖不同的是，volatile更輕量級，因為它不會引起線程上下文的切換和調度。

2. volatile的作用

說volatile作用之前，先說一下并發編程的三大特性：原子性、可見性和有序性。

• 原子性

即一個或者多個操作作為一個整體，要么全部執行，要么都不執行，并且操作在執行過程中不會被線程調度機制打斷；而且這種操作一旦開始，就一直運行到結束，中間不會有任何上下文切換。

• 可見性

可見性是指當多個線程訪問同一個變量時，一個線程修改了這個變量的值，其他線程能夠立即看得到修改的值。

• 有序性

為了提高程序的執行效率，編譯器會對編譯后的指令進行重排序，即代碼的編寫順序不一定就是代碼的執行順序。

并發編程中只有同時滿足這三大特性，才能保證程序正確的執行。而volatile的只保證了可見性和有序性，不保證原子性。

volatile的作用只有兩個：

• 保證內存的可見性
• 禁止JVM內存重排序（保證有序性）

在并發多線程情況下，為什么會有可見性問題？如果不做控制，為什么一個線程修改了共享變量的值，其他線程不能立即看到？這就需要聊到JMM（Java內存模型，Java Memory Model）。

3. JMM是什么

JMM（Java內存模型，Java Memory Model）定義程序訪問變量的規范，為了屏蔽不同操作系統之間的差異。

由于Java共享變量是存儲在主內存中，而Java線程無法直接訪問主內存中數據，只能把主內存中的數據讀到本地內存（相當于拷貝一份副本），修改完本地內存的數據，再寫回主內存。而此時另一個線程也把主內存的數據拷貝到自己私有的本地內存中，雖然線程1已經修改了主內存從數據，線程2卻無法感知到，所以就出現了內存可見性問題。

4. 可見性問題

JMM定義的這套模型，會有可見性問題。當線程1修改了本地內存的數據，并刷會主內存中，其他線程中本地內存的數據并沒有變化。也就是一個線程修改了共享變量的值，其他線程無法立即感知到。

像上圖的流程，兩個線程都把count=0的變量拷貝到自己私有的本地內存中，線程1把count的值修改為1，并寫回主內存，而線程2本地內存的count值還是0。

那么volatile是怎么解決可見性問題呢？

volatile主要通過匯編lock前綴指令，它會鎖定當前內存區域的緩存（緩存行），并且立即將當前緩存行數據寫入主內存（耗時非常短），回寫主內存的時候會通過MESI協議使其他線程緩存了該變量的地址失效，從而導致其他線程需要重新去主內存中重新讀取數據到其工作線程中。

什么是MESI協議？

MESI協議（Modified Exclusive Shared Or Invalid）是各處理器訪問緩存時都遵循一致性協議。核心思想是：

當CPU寫數據時，如果發現操作的變量是共享變量，即在其他CPU中也存在該變量的副本，會發出信號通知其他CPU將該變量的緩存行置為無效狀態，因此當其他CPU需要讀取這個變量時，發現自己緩存中緩存該變量的緩存行是無效的，那么它就會從內存重新讀取。

MESI分別代表緩存行數據所處的四種狀態，通過對這四種狀態的切換，來達到對緩存數據進行管理的目的。

而MESI協議是通過總線嗅探技術實現的：

總線嗅探是通過CPU偵聽總線上發生的數據交換操作，當總線上發生了數據操作，那么總線就會廣播對應的通知，CPU收到通知后，再根據本地的情況進行響應。

5. 有序性問題

虛擬機在進行代碼編譯時，對改變順序后不會對最終結果造成影響的代碼，虛擬機不一定會按我們寫的代碼順序運行，有可能進行重排序。實際上雖然重排后不會對變量值有影響，但會造成線程安全問題。

重排序又可以分為三種：

• 編譯器優化的重排序。編譯器在不改變單線程程序語義的前提下，可以重新安排語句的執行順序
• 指令級并行的重排序。現代CPU采用了指令級并行技術來將多條指令重疊執行。對于不存在數據依賴的指令，CPU可以改變語句對應機器指令的執行順序
• 內存系統的重排序。由于CPU使用三級緩存結構，這使得數據加載和存儲操作看上去可能是在亂序執行的

不過重排序也不是隨便重排的，發生指令重排序的前提是：在單線程下不影響執行結果、對沒有數值依賴的代碼進行重排序。這就是as-if-serial語義。在多線程情況下有一套更具體的規則，那就是happens-before原則。

happens-before由以下八大原則組成：

• 程序次序規則：一個線程內，按照代碼順序，書寫在前面的操作先行發生于書寫在后面的操作（線程的執行結果有序）
• 鎖定規則：一個unlock操作先行發生于后面對同一個鎖的lock操作
• volatile變量規則：對一個volatile變量的寫操作先行發生于后面對這個變量的讀操作
• 傳遞規則：如果操作A先行發生于操作B，操作B先行發生于操作C，則可以得出操作A先行發生于操作C
• 線程啟動規則：Thread對象的start()方法先行發生于該線程的其他任何操作
• 線程中斷規則：對線程中斷方法interrupt()的調用先行發生于被中斷線程檢測到中斷事件的發生
• 線程終結規則：線程中所有操作先行發生于線程的終止檢測。通過Thread.join()方法結束、Thread.isAlive()方法的返回值等手段檢測到線程已經終止執行。比如在A線程中調用B.join()方法，B線程執行完成后，B對共享變量的修改，對A來說是可見的

對象終結規則：一個對象的初始化方法完成先行發生于該對象的finalize()方法的開始

如果兩個操作不滿足上述八大原則中的任意一個，那么這兩個操作就沒有順序保證，虛擬機可以對這兩個操作進行重排序。如果操作A happens-before 操作B，那么A在內存所做的修改對B都是可見的。

而volatile是通過插入內存屏障（Memory Barrier），在內存屏障前后禁止重排序優化，以此實現有序性。

內存屏障有兩個作用：一是保證特定操作的執行順序，二是保證某些變量的內存可見性。

volatile內存語義的實現： JMM 針對編譯器制定的 volatile 重排序規則表

編譯器在生成字節碼時，會在指令序列中插入內存屏障來禁止特定類型的處理器重排序：

• 在每個volatile寫操作的前面插入一個StoreStore屏障
• 在每個volatile寫操作的后面插入一個StoreLoad屏障
• 在每個volatile讀操作的后面插入一個LoadLoad屏障
• 在每個volatile讀操作的后面插入一個LoadStore屏障

6. volatile應用場景

volatile可以保證可見性和有序性，但無法保證原子性。所以它的應用場景就不如synchronized廣泛，主要有兩個場景：一是做狀態變量，二是做需要重新賦值的共享對象。

比如：第二種場景常見的就有修飾單例模式的對象。

public class Singleton {
  // 使用volatile修飾，賦值后，其他線程能立即感知到
    private static volatile Singleton instance;

    private Singleton(){
    }

    public static Singleton getInstance(){
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }

}

還有就是CopyOnWriteArrayList的底層實現就是用volatile修飾的數組，因為CopyOnWriteArrayList每次修改數據后都會數組重新賦值，而不是只修改數據中的一個值，這樣才能保證了CopyOnWriteArrayList的數據安全性。