指令重排序分三类：编译器重排序（单线程安全、多线程破坏初始化顺序）、CPU指令级并行重排序（乱序执行导致时序不确定性）、内存系统重排序（缓存与缓冲区引发可见性断裂），三者协同易致DCL单例中未初始化对象被误用。
编译器重排序：单线程安全，多线程易破假设
编译器在生成字节码或机器码时，会基于as-if-serial语义优化代码顺序——只要不改变单线程执行结果，就可调整无数据依赖的语句。比如：
- int a = 1;（操作A）
- int b = 2;（操作B）
- int c = a + b;（操作C）
A和B无依赖，可能被重排为B→A；但C依赖A、B，绝不会提前。这种重排对单线程完全透明，但在多线程下会打破开发者“先初始化再发布”的直觉。例如构造对象后才设标志位，编译器可能把标志位写入提前到对象字段赋值之前，导致其他线程看到未完全初始化的对象。
指令级并行重排序：CPU乱序执行放大时序不确定性
现代CPU通过流水线、多发射、寄存器重命名等技术实现指令级并行。只要两条指令不共享寄存器或内存地址，硬件就可能让后写的指令先执行。关键在于：这种重排发生在单个CPU核心内部，不跨核同步。典型风险场景是：
- 线程A：写普通变量a = 42 → 写volatile flag = true
- 线程B：读flag == true → 读a
由于a与flag无数据依赖，CPU可能把flag=true提前执行。线程B看到true后读a，却拿到旧值甚至默认值0——这不是bug，而是硬件合法优化的结果。
内存系统重排序：缓存与缓冲区导致可见性断裂
这是并发中最隐蔽也最普遍的问题来源。CPU写操作常先写入Store Buffer而非直接刷到主存；读操作也可能从L1缓存取旧值。于是出现：
- 线程A修改变量x，写入缓冲区但未同步到其他核缓存
- 线程B在同一时刻读x，命中本地缓存，得到过期值
这种现象不是指令顺序变了，而是不同线程看到的内存状态不一致。它常与前两类重排叠加：比如编译器把写操作提前，CPU又把它卡在缓冲区，最终导致其他线程既看不到新值，也读不到正确顺序。
三类重排共同作用的真实危害
它们很少单独作祟，往往协同引发严重问题。典型案例如双重检查锁定（DCL）单例：
- new Singleton()包含三步：分配内存→调用构造器→将引用赋给instance
- 编译器或CPU可能重排为：分配内存→赋引用→调用构造器
- 此时instance非null，但对象尚未初始化完成
- 另一线程读到非null instance，直接使用，触发NPE或逻辑错误
解决路径明确：用volatile修饰instance（插入内存屏障，禁止构造器与赋值间的重排），或改用静态内部类等更安全的初始化方式。
