在Java里指令重排是什么_Java并发底层原理说明_技术教程

指令重排不是bug，是编译器和CPU为提升性能对无依赖语句的合法调序；多线程下可能导致可见性问题，如DCL单例失效，需用volatile、synchronized或final保障正确性。

指令重排不是bug，是CPU和编译器的“省时间操作”

Java里的指令重排，本质是编译器（javac / JIT）和CPU为了不干等、多干活，悄悄调换你代码里**没有依赖关系**的语句执行顺序。它在单线程下完全合法——结果不变，但跑得更快。比如：

int a = 1;
int b = 2;
int c = a + b;

a = 1 和 b = 2 没有数据依赖，JIT 或 CPU 完全可能先执行后者；但 c = a + b 一定在它们之后，因为依赖 a 和 b 的值。

问题出在多线程：当多个线程共享变量时，这种“省时间”可能让一个线程看到“半初始化”的对象，或读到未刷新的值。

最典型的坑：双重检查锁（DCL）单例失效

下面这段看似安全的单例代码，在无 volatile 时，极大概率因指令重排崩溃：

public class Singleton {
    private static Singleton instance;
    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton(); // ← 这行实际分三步：1. 分配内存 2. 初始化对象 3. 赋值给 instance
                }
            }
        }
        return instance;
    }
}

JIT 可能把第2步（初始化）和第3步（赋值）重排，导致 instance 非空但内部字段仍是默认值（如 null 或 0）。另一个线程拿到这个“半成品”，一用就 NullPointerException。

✅ 正确做法：把 instance 声明为 volatile ——它强制插入内存屏障，禁止对这个变量的读写重排序
⚠️ 注意：synchronized 块内只保证块内有序，不阻止块外的重排；必须靠 volatile 锁住赋值这一步
❌ 不要以为加了锁就万事大吉：锁只管临界区，不管对象构造过程本身的可见性

禁止重排的三种手段，适用场景完全不同

不是所有场景都该用 volatile，也不是所有同步都要上锁：

volatile：适合“一写多读”、无复合操作的标志位，如 running = false、ready = true；不能用于 count++ 这类非原子操作
synchronized：适合需要原子性 + 可见性 + 互斥的临界区；它隐式插入读写屏障，但开销比 volatile 大得多
final 字段：对象构造完成后，final 字段值对其他线程立即可见——这是 JMM 对构造函数的特殊保障，但仅限于构造时一次性赋值

例如，一个不可变配置类：

public class Config {
    private final String url;
    private final int timeout;
    public Config(String url, int timeout) {
        this.url = url;      // ← final 保证其他线程看到的是初始化后的值
        this.timeout = timeout;
    }
}