如何通过双重检查锁定（DCL）的原子性来理解为何在禁止指令重排中volatile关键字至关重要？

本文共计1038个文字，预计阅读时间需要5分钟。

很多人误以为 `volatile` 在 DCL (Double-Check Locking) 中是用来保证原子性的，这是典型误解。DCL 的原子性依赖于 `synchronized` 块——它包括了对象的创建和赋值过程，确保同一时刻只有一个线程能执行这部分代码。而 `volatile` 根本不提供复合操作的原子性保证，例如 `volatile++` 依然是不安全的。

它的真正作用在别处：防止 JVM 或 CPU 将对象初始化的三步指令（分配内存 → 调用构造函数 → 赋值给静态引用）乱序执行。没有 volatile，第 3 步（instance = memory）可能被提前到第 2 步（ctorInstance(memory)）之前，导致其他线程看到一个“已赋值但未初始化”的对象引用。

为什么 synchronized 不能完全替代 volatile？

synchronized 确实能保证临界区内的有序性，但它只约束块内代码；一旦线程 A 退出同步块，对 instance 的写入如果不加 volatile，就无法保证对线程 B 的“立即可见”+“顺序可见”。具体来说：

• 线程 A 在 synchronized 块内完成 instance = new Singleton()，但该写入可能滞留在 CPU 缓存中，未及时刷回主内存
• 线程 B 在块外读 instance != null，可能读到旧值（可见性问题）
• 更危险的是：即使线程 B 侥幸读到了非 null 的 instance，这个引用指向的对象可能尚未完成构造（重排序导致）

volatile 写会插入 storeload 内存屏障，强制把前面所有写操作刷新到主内存；volatile 读则插入 loadload + loadstore 屏障，确保后续读写不会被提前到读之前——这正是 DCL 第二次检查能安全使用的底层保障。

不加 volatile 时典型的错误现象

这种 bug 极难复现，但真实存在。常见表现包括：

• 某个线程调用 getInstance() 返回非 null 对象，但访问其字段时报 NullPointerException（字段仍是默认值，如 int 为 0、引用为 null）
• 对象部分初始化成功，比如构造函数中前几行执行了，后几行没执行，状态不一致
• 仅在高并发、多核 CPU、JIT 优化开启等特定条件下触发，本地测试常“一切正常”

这不是 JVM Bug，而是 JMM（Java 内存模型）允许的行为——只要不加同步语义，重排序就是合法的优化。

volatile 在 DCL 中的最小必要写法

必须同时满足两个条件才有效：

• 修饰的是那个被双重检查的静态引用字段：private static volatile Singleton instance;
• 该字段只用于“发布”对象，不参与任何复合操作（如 instance.field++）

示例关键片段：

private static volatile Singleton instance; public static Singleton getInstance() { if (instance == null) { // 第一次检查 synchronized (Singleton.class) { if (instance == null) { // 第二次检查 instance = new Singleton(); // 这里 new 的三步会被 volatile 约束顺序 } } } return instance; }

注意：如果把 volatile 错加在局部变量、方法参数或非发布字段上，完全无效；也别试图用 AtomicReference 替代——它虽有 volatile 语义，但 DCL 的语义依赖的是字段本身的 volatile 修饰，否则 JIT 仍可能重排构造过程。

最容易被忽略的一点：volatile 的禁止重排序效果，只作用于它所修饰的那个字段的读写操作及其前后指令。它不是全局开关，也不能“传染”给对象内部字段。所以对象自身的线程安全，还得靠设计保证。