Java中volatile为什么能禁止指令重排序
因为volatile写操作会插入一个“StoreStore”和“StoreLoad”内存屏障，编译器不能把其后的读写提到它前面，处理器也不能将屏障后的内存操作重排到屏障前。这不是靠Java语言本身“保证”，而是JVM对volatile字段的读写翻译成带屏障的机器指令（如x86下的lock addl $0,0(%rsp)）。
常见错误现象：volatile修饰了flag，但没用在关键路径上——比如只在初始化后设一次，却忘了在读取共享对象前也加volatile读；或者误以为volatile能保证复合操作原子性（如counter++）。
使用场景：状态标志、双重检查锁中的单例引用、发布不可变对象的引用。
注意点：
立即学习“Java免费学习笔记（深入）”；
-
volatile不阻止其他非volatile字段的重排序，所以不能靠它“捎带”保护多个字段 - 在ARM或Alpha等弱序CPU上，
volatile开销比x86明显，别滥用 - JDK 9起，
VarHandle的getVolatile/setVolatile语义等价，但更灵活
构造函数内this逸出导致重排序问题
即使构造函数里最后一行才赋值this，编译器或处理器仍可能把对象字段的初始化重排到this被发布之后——只要字段还没被其他线程看到，这种重排就是合法的。一旦发生逸出（比如在构造器里启动线程、注册监听器、存入静态容器），其他线程就可能看到未完全初始化的对象。
典型错误代码：
public class BadInit {
private int x = 1;
private final int y = 2;
public BadInit() {
// this逸出：启动线程时，x可能还是0，y可能未赋值（final字段除外，有特殊保障）
new Thread(() -> System.out.println(x)).start();
}
}
解决办法只有两个：
- 彻底避免在构造器中发布
this（包括隐式发布，如匿名内部类捕获this） - 如果必须发布，确保所有字段在发布前已初始化完毕，且用
final修饰关键字段（JMM对final字段有额外重排序限制）
happens-before规则失效的常见误用
很多人以为只要满足happens-before规则，就一定不会看到重排序结果。但实际中，规则只约束“同步动作之间”的可见性，对规则之外的代码不提供任何保证。比如synchronized块内修改变量A，块外读A——如果读操作不在另一个synchronized块里，也不通过volatile读，那它就不在happens-before链上。
容易踩的坑：
- 用
ReentrantLock.lock()但忘记unlock()，导致后续线程无法建立happens-before关系 - 把
volatile读写当成“全局内存栅栏”，其实它只约束与它直接相关的读写顺序 - 认为
Thread.start()和Thread.run()自动构成happens-before——其实是start()和新线程第一个动作之间才有，不是和整个run()方法体
如何验证代码是否真被重排序了
纯靠代码逻辑很难确认重排序是否发生，因为它是硬件/编译器在特定条件下触发的瞬态行为。但可以借助工具缩小怀疑范围：
- 用JITWatch看热点方法是否被C2编译，再查生成的汇编里是否有字段访问被提前或延后
- 用jcstress（Java Concurrency Stress Test）跑并发压力测试，它内置大量重排序敏感用例，比如
FinalFieldTest能暴露final字段未正确初始化的问题 - 在Linux上用
perf record -e cycles,instructions观察不同线程间访存延迟突增，间接提示内存序异常
最实在的办法，是把疑似有问题的字段全标成volatile或套进synchronized，再压测对比行为变化——如果问题消失，基本就是重排序惹的祸。不过得小心，这可能掩盖真正的问题根源。
重排序从来不是孤立发生的，它总和内存可见性、线程调度、JIT优化交织在一起。调试时盯着“哪条指令被挪了位置”意义不大，重点得看数据依赖链断在哪一环。
