指令重排是编译器和CPU为优化性能主动调整无关指令顺序的行为，单线程下符合as-if-serial语义故安全，多线程下因可见性与有序性破坏导致NPE、半初始化对象等问题。
指令重排到底是什么，为什么单线程没问题、多线程就崩了
指令重排不是 bug，是编译器和 CPU 主动做的性能优化：它们会把看似“无关”的读写操作调换顺序，只要最终单线程执行结果不变（as-if-serial 语义）。比如 flag = true 和 resource = new Resource() 在无依赖时，JIT 可能先执行赋值再构造对象——这在单线程里完全安全，但放到多线程里，另一个线程可能看到 flag == true 却拿到一个未初始化完成的 resource，直接 NPE 或逻辑错乱。
常见错误现象：
- 懒汉式单例在多线程下返回 null 或半初始化对象
- 状态标志（如
isRunning）被设为 false 后，工作线程仍死循环不退出 - 配置加载后，部分线程读到旧值，部分读到新值
volatile 怎么靠内存屏障“锁住”执行顺序
volatile 不是加锁，而是插入内存屏障（Memory Barrier），强制约束指令的可见性和顺序。它在底层对应 CPU 的 lock 前缀指令（x86）或 ldarx/stwcx.（PowerPC），并配合 MESI 缓存一致性协议生效。
关键约束有三类：
立即学习“Java免费学习笔记（深入）”；
-
volatileWrite()前插入storeStoreBarrier：确保它前面所有普通写操作已落地，不会被拖到 volatile 写之后 -
volatileWrite()后插入storeLoadBarrier：防止后续任意读/写被提前到该 volatile 写之前 -
volatileRead()后插入loadLoadBarrier和loadStoreBarrier：保证该读取之后的操作，不会被重排到读之前
简单说：volatile 让 JVM 和 CPU “不敢动”它附近的指令顺序，从而守住你代码里隐含的因果逻辑。
为什么 volatile boolean flag = true; 能解决可见性，但 volatile int count++ 不行
可见性 ≠ 原子性。volatile 解决的是“改完别人能不能立刻看到”，不是“改这个动作本身能不能被拆开”。count++ 实际是三步：read → add → write，volatile 只能保证每一步的读/写都走主内存，但无法阻止三步之间被其他线程插队。
所以：
- 适合用 volatile 的场景：
boolean isShutdown、String configVersion、long lastHeartbeatTime—— 单次写入、多次读取，且写操作本身是原子的（基本类型赋值、引用赋值） - 不适合的场景：
count++、list.add(x)、map.put(k, v)—— 这些必须用synchronized、AtomicInteger或ReentrantLock
不用 volatile 时，JVM 和 CPU 怎么“悄悄”让你的代码失效
典型链路是：主线程修改 flag = true → 写入自己 L1 缓存 → 延迟刷回主内存 → 其他线程从自己缓存读 flag → 永远读到 false。JIT 甚至可能把 while(!flag) 优化成死循环（因为没看到任何写入影响它）。
更隐蔽的问题来自重排序：
class Singleton {
private static Singleton instance;
private static volatile boolean initialized = false;
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton(); // ← 可能被重排为：分配内存 → 赋值给 instance → 调用构造器
initialized = true; // ← volatile 写，带 storeLoadBarrier，挡住构造器延迟
}
}
}
return instance;
}
}
这里 volatile initialized 不是为了让它可见，而是用它的写屏障“卡住”构造器执行时机——这是很多人忽略的进阶用法。
真正容易被忽略的点：volatile 不能跨 volatile 变量建立 happens-before；两个 volatile 变量之间的操作，仍可能被重排。要严格保序，得用同一个 volatile 变量做“锚点”，或者上锁。
