聊聊Volatile的實現(xiàn)原理？
在 Java 并發(fā)編程中，有 3 個最常用的關鍵字：synchronized、ReentrantLock 和 volatile。
雖然 volatile 并不像其他兩個關鍵字一樣，能保證線程安全，但 volatile 也是并發(fā)編程中最常見的關鍵字之一。例如，單例模式、CopyOnWriteArrayList 和 ConcurrentHashMap 中都離不開 volatile。
那么，問題來了，我們知道 synchronized 底層是通過監(jiān)視器 Monitor 實現(xiàn)的，ReentrantLock 底層是通過 AQS 的 CAS 實現(xiàn)的，那 volatile 的底層是如何實現(xiàn)的？
1.volatile 作用
在了解 volatile 的底層實現(xiàn)之前，我們需要先了解 volatile 的作用，因為 volatile 的底層實現(xiàn)和它的作用息息相關。
volatile 作用有兩個：保證內(nèi)存可見性和有序性（禁止指令重排序）。
（1）內(nèi)存可見性
說到內(nèi)存可見性問題就不得不提 Java 內(nèi)存模型，Java 內(nèi)存模型（Java Memory Model）簡稱為 JMM，主要是用來屏蔽不同硬件和操作系統(tǒng)的內(nèi)存訪問差異的，因為在不同的硬件和不同的操作系統(tǒng)下，內(nèi)存的訪問是有一定的差異得，這種差異會導致相同的代碼在不同的硬件和不同的操作系統(tǒng)下有著不一樣的行為，而 Java 內(nèi)存模型就是解決這個差異，統(tǒng)一相同代碼在不同硬件和不同操作系統(tǒng)下的差異的。
Java 內(nèi)存模型規(guī)定：所有的變量（實例變量和靜態(tài)變量）都必須存儲在主內(nèi)存中，每個線程也會有自己的工作內(nèi)存，線程的工作內(nèi)存保存了該線程用到的變量和主內(nèi)存的副本拷貝，線程對變量的操作都在工作內(nèi)存中進行。線程不能直接讀寫主內(nèi)存中的變量，如下圖所示：
然而，Java 內(nèi)存模型會帶來一個新的問題，那就是內(nèi)存可見性問題，也就是當某個線程修改了主內(nèi)存中共享變量的值之后，其他線程不能感知到此值被修改了，它會一直使用自己工作內(nèi)存中的“舊值”，這樣程序的執(zhí)行結果就不符合我們的預期了，這就是內(nèi)存可見性問題，我們用以下代碼來演示一下這個問題：
private static boolean flag = false;
public static void main(String[] args) {
Thread t1 = new Thread(new Runnable() {
@Override
public void run() {
while (!flag) {
}
System.out.println("終止執(zhí)行");
}
});
t1.start();
Thread t2 = new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("設置 flag=true");
flag = true;
}
});
t2.start();
}以上代碼我們預期的結果是，在線程 1 執(zhí)行了 1s 之后，線程 2 將 flag 變量修改為 true，之后線程 1 終止執(zhí)行，然而，因為線程 1 感知不到 flag 變量發(fā)生了修改，也就是內(nèi)存可見性問題，所以會導致線程 1 會永遠的執(zhí)行下去，最終我們看到的結果是這樣的：
如何解決以上問題呢？只需要給變量 flag 加上 volatile 修飾即可，具體的實現(xiàn)代碼如下：
private volatile static boolean flag = false;
public static void main(String[] args) {
Thread t1 = new Thread(new Runnable() {
@Override
public void run() {
while (!flag) {
}
System.out.println("終止執(zhí)行");
}
});
t1.start();
Thread t2 = new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("設置 flag=true");
flag = true;
}
});
t2.start();
}以上程序的執(zhí)行結果如下圖所示：
（2）有序性
有序性也叫做禁止指令重排序。
指令重排序是指編譯器或 CPU 為了優(yōu)化程序的執(zhí)行性能，而對指令進行重新排序的一種手段。
指令重排序的實現(xiàn)初衷是好的，但是在多線程執(zhí)行中，如果執(zhí)行了指令重排序可能會導致程序執(zhí)行出錯。指令重排序最典型的一個問題就發(fā)生在單例模式中，比如以下問題代碼：
public class Singleton {
private Singleton() {}
private static Singleton instance = null;
public static Singleton getInstance() {
if (instance == null) { // ①
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton(); // ②
}
}
}
return instance;
}
}以上問題發(fā)生在代碼 ② 這一行“instance = new Singleton();”，這行代碼看似只是一個創(chuàng)建對象的過程，然而它的實際執(zhí)行卻分為以下 3 步：
- 創(chuàng)建內(nèi)存空間。
- 在內(nèi)存空間中初始化對象 Singleton。
- 將內(nèi)存地址賦值給 instance 對象（執(zhí)行了此步驟，instance 就不等于 null 了）。
如果此變量不加 volatile，那么線程 1 在執(zhí)行到上述代碼的第 ② 處時就可能會執(zhí)行指令重排序，將原本是 1、2、3 的執(zhí)行順序，重排為 1、3、2。但是特殊情況下，線程 1 在執(zhí)行完第 3 步之后，如果來了線程 2 執(zhí)行到上述代碼的第 ① 處，判斷 instance 對象已經(jīng)不為 null，但此時線程 1 還未將對象實例化完，那么線程 2 將會得到一個被實例化“一半”的對象，從而導致程序執(zhí)行出錯，這就是為什么要給私有變量添加 volatile 的原因了。
要使以上單例模式變?yōu)榫€程安全的程序，需要給 instance 變量添加 volatile 修飾，它的最終實現(xiàn)代碼如下：
public class Singleton {
private Singleton() {}
// 使用 volatile 禁止指令重排序
private static volatile Singleton instance = null; // 【主要是此行代碼發(fā)生了變化】
public static Singleton getInstance() {
if (instance == null) { // ①
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton(); // ②
}
}
}
return instance;
}
}2.volatile 實現(xiàn)原理
volatile 實現(xiàn)原理和它的作用有關，我們首先先來看它的內(nèi)存可見性。
（1）內(nèi)存可見性實現(xiàn)原理
volatile 內(nèi)存可見性主要通過 lock 前綴指令實現(xiàn)的，它會鎖定當前內(nèi)存區(qū)域的緩存（緩存行），并且立即將當前緩存行數(shù)據(jù)寫入主內(nèi)存（耗時非常短），回寫主內(nèi)存的時候會通過 MESI 協(xié)議使其他線程緩存了該變量的地址失效，從而導致其他線程需要重新去主內(nèi)存中重新讀取數(shù)據(jù)到其工作線程中。
什么 MESI 協(xié)議？
MESI 協(xié)議，全稱為 Modified, Exclusive, Shared, Invalid，是一種高速緩存一致性協(xié)議。它是為了解決多處理器（CPU）在并發(fā)環(huán)境下，多個 CPU 緩存不一致問題而提出的。MESI 協(xié)議定義了高速緩存中數(shù)據(jù)的四種狀態(tài)：
- Modified（M）：表示緩存行已經(jīng)被修改，但還沒有被寫回主存儲器。在這種狀態(tài)下，只有一個 CPU 能獨占這個修改狀態(tài)。
- Exclusive（E）：表示緩存行與主存儲器相同，并且是主存儲器的唯一拷貝。這種狀態(tài)下，只有一個 CPU 能獨占這個狀態(tài)。
- Shared（S）：表示此高速緩存行可能存儲在計算機的其他高速緩存中，并且與主存儲器匹配。在這種狀態(tài)下，各個 CPU 可以并發(fā)的對這個數(shù)據(jù)進行讀取，但都不能進行寫操作。
- Invalid（I）：表示此緩存行無效或已過期，不能使用。
MESI 協(xié)議的主要用途是確保在多個 CPU 共享內(nèi)存時，各個 CPU 的緩存數(shù)據(jù)能夠保持一致性。當某個 CPU 對共享數(shù)據(jù)進行修改時，它會將這個數(shù)據(jù)的狀態(tài)從 S（共享）或 E（獨占）狀態(tài)轉變?yōu)?M（修改）狀態(tài)，并等待適當?shù)臅r機將這個修改寫回主存儲器。同時，它會向其他 CPU 廣播一個“無效消息”，使得其他 CPU 將自己緩存中對應的數(shù)據(jù)狀態(tài)轉變?yōu)镮（無效）狀態(tài)，從而在下次訪問這個數(shù)據(jù)時能夠從主存儲器或其他 CPU 的緩存中重新獲取正確的數(shù)據(jù)。
這種協(xié)議可以確保在多處理器環(huán)境中，各個 CPU 的緩存數(shù)據(jù)能夠正確、一致地反映主存儲器中的數(shù)據(jù)狀態(tài)，從而避免由于緩存不一致導致的數(shù)據(jù)錯誤或程序異常。
（2）有序性實現(xiàn)原理
volatile 的有序性是通過插入內(nèi)存屏障（Memory Barrier），在內(nèi)存屏障前后禁止重排序優(yōu)化，以此實現(xiàn)有序性的。
什么是內(nèi)存屏障？
內(nèi)存屏障（Memory Barrier 或 Memory Fence）是一種硬件級別的同步操作，它強制處理器按照特定順序執(zhí)行內(nèi)存訪問操作，確保內(nèi)存操作的順序性，阻止編譯器和 CPU 對內(nèi)存操作進行不必要的重排序。內(nèi)存屏障可以確保跨越屏障的讀寫操作不會交叉進行，以此維持程序的內(nèi)存一致性模型。
在 Java 內(nèi)存模型（JMM）中，volatile 關鍵字用于修飾變量時，能夠保證該變量的可見性和有序性。關于有序性，volatile 通過內(nèi)存屏障的插入來實現(xiàn)：
- 寫內(nèi)存屏障（Store Barrier / Write Barrier）：當線程寫入 volatile 變量時，JMM 會在寫操作前插入 StoreStore 屏障，確保在這次寫操作之前的所有普通寫操作都已完成。接著在寫操作后插入 StoreLoad 屏障，強制所有后來的讀寫操作都在此次寫操作完成之后執(zhí)行，這就確保了其他線程能立即看到 volatile 變量的最新值。
- 讀內(nèi)存屏障（Load Barrier / Read Barrier）：當線程讀取 volatile 變量時，JMM 會在讀操作前插入 LoadLoad 屏障，確保在此次讀操作之前的所有讀操作都已完成。而在讀操作后插入 LoadStore 屏障，防止在此次讀操作之后的寫操作被重排序到讀操作之前，這樣就確保了對 volatile 變量的讀取總是能看到之前對同一變量或其他相關變量的寫入結果。
通過這種方式，volatile 關鍵字有效地實現(xiàn)了內(nèi)存操作的順序性，從而保證了多線程環(huán)境下對 volatile 變量的操作遵循 happens-before 原則，確保了并發(fā)編程的正確性。
（3）簡單回答
因為內(nèi)存屏障的作用既能保證內(nèi)存可見性，同時又能禁止指令重排序。因此你也可以籠統(tǒng)的回答 volatile 是通過內(nèi)存屏障實現(xiàn)的。但是，回答的越細，面試的成績越高，面試的通過率也就越高。
