什麼是Java中的指令重排？詳情 - 執行順序,編譯器,多線程,MySQL,數據庫 wx690f565d7bc78 博客

一、指令重排的定義

在執行程序時，為了提高性能，編譯器和處理器常常會對指令進行重新排序。

編譯器重排：編譯器在不改變單線程程序語義的前提下，重新安排語句的執行順序。
處理器重排：CPU 採用了指令級並行技術，將多條指令重疊執行。如果不存在數據依賴性，處理器可以改變語句對應的機器指令的執行順序。

二、指令重排的背景和原因

指令重排的根本目的，是為了在不影響程序單線程執行結果的前提下，儘可能地利用 CPU 的運算資源，從而提升程序的整體運行效率。

你可以把它想象成一個聰明的餐廳廚師。如果菜單上同時來了兩個菜：一個是 “炒青菜”，另一個是 “清蒸魚”。

串行執行：廚師可能會先把魚蒸上（需要 10 分鐘），然後在這 10 分鐘裏什麼都不做，一直等魚蒸好，再去炒青菜（需要 2 分鐘）。總耗時 12 分鐘。這顯然效率很低。
重排並行執行：一個更高效的廚師會這樣做：他先把魚放進蒸箱，設置好時間。然後，在魚蒸着的這 10 分鐘裏，他轉身去炒青菜。這樣，當青菜炒好時，魚也差不多蒸好了。總耗時大約就是 10 分鐘。

這裏，“蒸魚” 和 “炒青菜” 這兩個任務之間沒有依賴關係（炒青菜不需要等魚蒸好才能開始），所以廚師可以改變它們的執行順序，實現並行處理，從而縮短了總時間。

Java 虛擬機（JVM）和 CPU 的指令重排，其思想與這位廚師如出一轍。它會在後台默默調整你的代碼執行順序，以達到最優的性能。

三、指令重排的類型

指令重排主要發生在三個層面：

編譯器重排：在編譯階段，Java 編譯器（如 javac）會對字節碼進行優化。
CPU 指令重排：即使編譯器不重排，CPU 在執行指令時，也可能會根據自身的流水線和調度策略，動態地調整指令的執行順序。
內存系統重排：現代計算機都有高速緩存（Cache）和寫緩衝區（Store Buffer）。這種架構會導致 “內存可見性” 問題。一個線程寫入的數據，可能不會立即被刷新到主內存，另一個線程讀取時可能看到的是舊值。從效果上看，這也像是指令執行順序被打亂了。

四、一個經典的例子：指令重排導致的併發問題

在單線程環境下，指令重排是 “透明” 的，我們無法感知到，也不會出現問題。但在多線程環境下，它可能會導致一些非常隱蔽且難以調試的 bug。

下面是一個非常經典的例子，它展示了指令重排如何破壞多線程程序的正確性。

我們有一個 Singleton 單例模式的實現：

java

運行

public class Singleton {
    private static Singleton instance;

    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) { // 1. 第一次檢查
            synchronized (Singleton.class) { // 2. 加鎖
                if (instance == null) { // 3. 第二次檢查
                    instance = new Singleton(); // 4. 創建實例
                }
            }
        }
        return instance;
    }
}

這是一個看似完美的 “雙重檢查鎖定”（Double-Checked Locking, DCL）實現。然而，它在多線程環境下是不安全的，其根源就在於 instance = new Singleton(); 這行代碼。

你可能會認為這是一個原子操作，但實際上，它可以被分解為以下三個步驟：

分配內存空間：memory = allocate()
初始化對象：ctorInstance(memory)
設置 instance 指向剛分配的內存地址：instance = memory

在單線程中，這三個步驟必須按 1->2->3 的順序執行。但在多線程環境下，編譯器或 CPU 可能會為了優化性能，將步驟 2 和步驟 3 的順序進行重排。重排後的執行順序可能是：

分配內存空間：memory = allocate()
設置 instance 指向內存地址：instance = memory (此時對象還未初始化！)
初始化對象：ctorInstance(memory)

現在，我們來看看重排後，兩個線程併發執行 getInstance() 會發生什麼：

時間點	線程 A	線程 B
T1	檢查 `instance` 為 `null`。	-
T2	獲取鎖。	-
T3	再次檢查 `instance` 為 `null`。	-
T4	執行 `instance = new Singleton()`，但指令被重排。 1. 分配內存。 2. 將 `instance` 指向該內存（此時 `instance` 不再是 `null`，但對象內容是空的）。	-
T5	-	檢查 `instance`，發現它不為 `null`。
T6	-	直接返回了這個未被完全初始化的 `instance` 對象！
T7	線程 A 繼續執行對象的初始化工作。	線程 B 開始使用一個 “半成品” 對象，可能導致程序崩潰或數據異常。

這個例子非常深刻地揭示了指令重排在併發編程中的風險。

五、如何解決指令重排問題？

Java 提供了 volatile 關鍵字來解決這個問題。

當一個變量被聲明為 volatile 時，它會禁止編譯器和 CPU 對其相關的指令進行重排序。更具體地説，它保證了：

可見性：一個線程對 volatile 變量的修改，會立即被其他線程看到。
有序性：volatile 變量的讀寫操作前後，會形成一個 “內存屏障”（Memory Barrier）。這相當於告訴 CPU：“在執行我後面的指令之前，必須先完成我前面所有 volatile 變量的讀寫操作。”

在上面的單例模式例子中，只需將 instance 變量聲明為 volatile，就可以修復這個併發 bug：

java

運行

public class Singleton {
    // 使用 volatile 關鍵字修飾
    private static volatile Singleton instance;

    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    // volatile 會禁止此處的指令重排
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

volatile 確保了 instance = new Singleton() 的三個步驟必須按 1->2->3 的順序執行。因此，線程 B 在 T5 時間點看到的 instance 要麼是 null，要麼是一個完全初始化好的對象，從而避免了風險。

除了 volatile，Java 內存模型（JMM）還通過 synchronized 關鍵字和 final 關鍵字在某些場景下提供了類似的內存屏障和有序性保證。

總結

是什麼？ 指令重排是 JVM 和 CPU 為優化性能而對指令執行順序進行的重新排列。
為什麼？ 為了最大化利用 CPU 資源，提升程序運行效率。
有何風險？ 在單線程中無害，但在多線程環境下，可能會破壞程序的正確性，導致難以預料的 bug。
如何應對？ 在併發編程中，當多個線程共享狀態時，應使用 volatile、synchronized 等關鍵字來顯式地保證內存可見性和操作有序性，從而規避指令重排帶來的風險。