南瑾i1. Synchronized 与指令重排序的关系
在多线程编程中，指令重排序（Instruction Reordering）是一个经常被讨论的话题。作为Java开发者，我们经常使用synchronized关键字来保证线程安全，但很多人对synchronized能否禁止指令重排序存在疑问。
指令重排序是编译器和处理器为了提高程序性能而采取的一种优化手段。它会在不影响单线程程序执行结果的前提下，重新安排指令的执行顺序。但在多线程环境下，这种优化可能会导致意想不到的结果。
注意：指令重排序不是bug，而是一种合法的优化手段。问题在于我们如何正确理解和使用同步机制来避免它带来的线程安全问题。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. synchronized的内存语义
2.1 synchronized的基本作用
synchronized在Java中主要有三个作用：
- 互斥性：确保同一时刻只有一个线程可以执行同步代码块
- 可见性：保证一个线程修改共享变量后，其他线程能够立即看到修改
- 有序性：限制指令重排序对同步代码块的影响
2.2 synchronized的有序性保证
synchronized确实能够限制指令重排序，但这种限制是有特定范围的：
- 对于同步块内部的代码，编译器和处理器仍然可以进行重排序，只要不改变单线程执行的结果
- 对于同步块边界处的代码，有以下限制：
- 进入同步块（获取锁）前的操作不会被重排序到同步块内部
- 离开同步块（释放锁）后的操作不会被重排序到同步块内部
- 同步块内部的操作不会被重排序到同步块外部
这种限制是通过内存屏障（Memory Barrier）实现的。synchronized在获取锁和释放锁时都会插入特定的内存屏障指令。
3. synchronized与volatile的比较
3.1 有序性保证的差异
虽然synchronized和volatile都能提供有序性保证，但它们的机制有所不同：
| 特性 | synchronized | volatile |
|---|---|---|
| 作用范围 | 代码块级别 | 变量级别 |
| 互斥性 | 有 | 无 |
| 可见性 | 有 | 有 |
| 有序性 | 部分限制 | 完全限制 |
| 性能影响 | 较大 | 较小 |
3.2 使用场景选择
在实际开发中，我们应该根据具体需求选择合适的同步机制：
- 当需要保证复合操作的原子性时，使用synchronized
- 当只需要保证单个变量的可见性和有序性时，使用volatile
- 当需要同时保证复合操作的原子性和有序性时，可以结合使用两者
4. 实际案例分析
4.1 双重检查锁定模式
经典的DCL（Double-Checked Locking）问题很好地展示了synchronized和指令重排序的关系：
java复制public class Singleton {
private static Singleton instance;
public static Singleton getInstance() {
if (instance == null) { // 第一次检查
synchronized (Singleton.class) {
if (instance == null) { // 第二次检查
instance = new Singleton(); // 问题所在
}
}
}
return instance;
}
}
在这个例子中，即使使用了synchronized，仍然可能出现问题。因为instance = new Singleton()这个操作实际上包含三个步骤：
- 分配内存空间
- 初始化对象
- 将引用指向分配的内存
编译器和处理器可能会将步骤2和步骤3重排序，导致其他线程看到一个未完全初始化的对象。
4.2 解决方案
解决DCL问题有以下几种方法：
-
使用volatile修饰instance变量（Java 5+）
java复制private static volatile Singleton instance; -
使用静态内部类方式
java复制public class Singleton { private static class Holder { static final Singleton INSTANCE = new Singleton(); } public static Singleton getInstance() { return Holder.INSTANCE; } } -
直接使用synchronized方法（性能较差）
java复制public static synchronized Singleton getInstance() { if (instance == null) { instance = new Singleton(); } return instance; }
5. JMM（Java内存模型）视角
5.1 happens-before关系
从Java内存模型的角度看，synchronized建立了一系列happens-before关系：
- 同一个锁的解锁操作happens-before后续对这个锁的加锁操作
- 线程A在释放锁M之前的所有操作，对线程B在获取同一个锁M之后都是可见的
这些happens-before关系限制了指令重排序的可能性。
5.2 同步规则
JMM对synchronized的规定包括：
- 线程在进入同步块时，会清空工作内存，从主内存重新加载变量
- 线程在退出同步块时，会把工作内存中的修改刷新到主内存
- 同步块内部的指令不能"逃逸"到同步块外部执行
这些规则共同作用，限制了指令重排序的影响范围。
6. 性能考量
6.1 synchronized的开销
虽然synchronized提供了有序性保证，但它也带来了性能开销：
- 锁获取和释放的操作本身就有开销
- 内存屏障会限制处理器的优化能力
- 竞争激烈时会导致线程阻塞
6.2 优化建议
为了平衡正确性和性能，可以考虑以下优化：
- 减小同步块的范围，只同步必要的代码
- 使用更细粒度的锁（如ConcurrentHashMap的分段锁）
- 在低竞争场景下，考虑使用java.util.concurrent中的原子类
- 对于读多写少的场景，考虑使用读写锁（ReadWriteLock）
7. 常见误区
7.1 过度依赖synchronized
有些开发者认为只要加了synchronized，所有线程安全问题都会消失。实际上：
- synchronized不能解决所有并发问题（如死锁、活锁）
- 错误的同步范围仍然会导致问题
- 过度同步会严重影响性能
7.2 忽视指令重排序
另一个极端是完全忽视指令重排序的影响：
- 认为"在我的机器上运行正常"就等于代码正确
- 不理解可见性和有序性的区别
- 不熟悉happens-before规则
8. 最佳实践
8.1 同步策略选择
在实际项目中，建议：
- 首先考虑是否真的需要同步
- 优先使用不可变对象和线程安全集合
- 对于简单的状态维护，考虑使用原子变量
- 对于复杂的同步需求，再考虑使用synchronized或Lock
8.2 代码审查要点
在代码审查时，特别关注：
- 同步块是否覆盖了所有必要的操作
- 是否存在不必要的同步
- 是否有可能的指令重排序问题
- 锁的粒度是否合适
9. 测试与验证
9.1 并发测试方法
验证synchronized的正确性可以考虑：
- 使用压力测试模拟高并发场景
- 使用静态分析工具检查同步问题
- 在代码中插入断言验证不变式
9.2 重现指令重排序
虽然指令重排序难以稳定重现，但可以尝试：
- 在测试环境中禁用某些优化
- 增加测试的迭代次数
- 使用特殊的JVM参数（如-XX:+PrintAssembly）
10. 总结与建议
回到最初的问题：synchronized确实能在一定程度上限制指令重排序，但这种限制是有限的。它主要保证的是同步块边界处的有序性，而不是同步块内部的有序性。
对于需要严格有序性保证的场景，建议：
- 理解synchronized的局限性
- 必要时结合使用volatile
- 考虑使用更高层次的并发工具（如java.util.concurrent）
- 保持对JMM和happens-before规则的理解
在实际开发中，我通常会先使用更简单的并发控制机制（如不可变对象），只有在确实需要时才引入synchronized。对于关键的业务逻辑，建议进行充分的并发测试，而不仅仅是依赖语言特性提供的保证。