Java volatile 關鍵字深度解析：內存語義、指令重排與最佳實踐場景

volatile 內存語義核心

volatile 保證兩項關鍵語義：

1. 可見性：寫入 volatile 變數的值對其他執行緒立即可見。
2. 有序性：禁止指令重排序，確保 volatile 讀寫前後的操作不會被編譯器/處理器跨越邊界移動。

注意：volatile 不保證原子性（如 volatile int i; i++; 非原子）。

JMM 重排序規則表

Java 記憶體模型 (JMM) 針對編譯器制定嚴格規則：

• 第二操作為 volatile 寫 → 禁止重排序（確保前序操作不被移至寫入之後）。
• 第一操作為 volatile 讀 → 禁止重排序（確保後續操作不被移至讀取之前）。
• volatile 寫後接 volatile 讀 → 禁止重排序。

內存屏障插入策略（保守策略）

為實現上述語義，JMM 在字節碼生成階段插入屏障：

x86 平台優化

x86 僅允許「寫-讀」重排，因此：

• 省略 LoadLoad、LoadStore、StoreStore 屏障。
• 僅在 volatile 寫前保留 StoreLoad（lock addl $0,0(%esp)）。
• 結論：x86 上 volatile 寫開銷遠大於讀。

JSR-133 為何強化 volatile？

舊模型允許 volatile 與普通變數重排，導致「寫-讀」不具備監視器釋放-獲取語義。JSR-133 禁止此類重排，使 volatile 具備與鎖相同的內存語義，提供輕量級執行緒通訊機制。

適用場景（需同時滿足）

1. 寫入操作不依賴當前值（如 flag = true、非 i++）。
2. 變數不參與不變式約束（不與其他變數組成邏輯關聯）。

經典實戰場景

1. 狀態標誌位

volatile boolean initialized = false;
// Thread 1
context = loadContext();
initialized = true; // 釋放語義，確保 context 可見

// Thread 2
while (!initialized) { Thread.sleep(100); }
doSomethingWithConfig(context); // 獲取語義，保證看到最新 context

2. 雙重檢查鎖單例

public class Singleton {
    private volatile static Singleton instance;
    private Singleton() {}
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null)
                    instance = new Singleton(); // volatile 禁止指令重排，防止半初始化
            }
        }
        return instance;
    }
}

volatile vs synchronized 選型建議

⚠️ 切記：volatile 無法替代 synchronized，濫用會導致難以排查的並發 Bug。