双重检查锁（DCL）旧版写法指JDK 1.5前未用volatile修饰instance的实现：先判空、加锁、再判空、new对象；其核心缺陷是new非原子操作，JVM可能重排序构造初始化与引用赋值，导致其他线程获取到半初始化对象。
什么是双重检查锁（DCL）的旧版写法
双重检查锁常用于单例模式，目的是在保证线程安全的前提下避免每次获取实例都加锁。JDK 1.5 之前的典型写法如下：
class Singleton {
private static Singleton instance;
public static Singleton getInstance() {
if (instance == null) { // 第一次检查
synchronized (Singleton.class) {
if (instance == null) { // 第二次检查
instance = new Singleton(); // 问题核心所在
}
}
}
return instance;
}
}
JDK 1.5 之前的关键缺陷：对象构造未完成就“可见”
问题不在于锁本身，而在于 new Singleton() 这行代码在底层并非原子操作，它包含三步：
- 在堆内存中分配对象空间
- 调用构造方法初始化对象字段
- 将 instance 引用指向该内存地址（即赋值）
在 JDK 1.5 之前，JVM 和 CPU 允许对第 2 步和第 3 步进行重排序。也就是说，可能先完成分配和赋值（instance 不再为 null），但构造方法还没执行完——此时对象处于“半初始化”状态。
另一个线程若恰好在此时通过第一次检查（instance != null），就会直接返回这个未初始化完毕的对象，后续调用其方法极易触发 NullPointerException 或读到默认值（如 0、null）。
为什么 volatile 能修复这个问题（JDK 1.5+）
将 instance 声明为 volatile 后，它同时解决两个问题：
- 可见性：确保 instance 的最新值对所有线程立即可见
- 禁止重排序：volatile 写操作具有“happens-before”语义，禁止编译器和处理器把构造函数的初始化步骤重排到引用赋值之后
修正后的写法：
private static volatile Singleton instance;
为什么只加 synchronized 不够
虽然 synchronized 保证了临界区的互斥，但它只约束进入锁内的线程行为。一旦某个线程完成 instance = new Singleton() 并释放锁，其他线程在锁外读取 instance 时，仍可能因缓存未刷新或指令重排而看到“部分构造”的对象。
换句话说：synchronized 解决了原子性与互斥，但不自动保障发布对象的可见性与构造完整性；而 volatile 在此处补上了最关键的内存屏障（memory barrier）作用。
