双重检查锁实现单例需用volatile修饰实例，防止指令重排序导致线程看到未初始化对象；标准写法含两次null检查与synchronized块；推荐静态内部类或枚举替代。
用双重检查锁（Double-Checked Locking）实现线程安全的单例，核心是减少同步开销，同时保证实例只被创建一次且可见性正确。关键在于 volatile 修饰实例变量，防止指令重排序导致其他线程看到未初始化完成的对象。
为什么需要 volatile
在没有 volatile 时，JVM 可能将单例对象的构造过程（分配内存 → 初始化 → 赋值给静态引用）重排序为：分配内存 → 赋值给静态引用 → 初始化。此时另一个线程可能读到非 null 的引用，但对象尚未初始化完毕，造成空指针或异常状态。
加上 volatile 后，禁止了该重排序，并确保后续读操作能看到初始化后的全部字段值（happens-before 语义）。
标准双重检查锁写法（Java）
以下是推荐的实现方式：
public class Singleton {
private static volatile Singleton instance;
private Singleton() {}
public static Singleton getInstance() {
if (instance == null) { // 第一次检查（无锁）
synchronized (Singleton.class) {
if (instance == null) { // 第二次检查（加锁后）
instance = new Singleton(); // volatile 保证原子性和可见性
}
}
}
return instance;
}
}
注意点：
- 构造函数必须私有，防止外部 new 实例
- instance 必须用 volatile 修饰，不可省略
- 两个 if (instance == null) 缺一不可：外层避免不必要的同步，内层防止重复创建
- synchronized 锁的是类对象（Singleton.class），确保全局唯一锁
其他安全且更简洁的替代方案
双重检查锁虽经典，但易出错。以下方式更推荐：
- 静态内部类（推荐）：利用类加载机制保证线程安全与懒加载，无同步开销
- 枚举单例：天然线程安全、防反射/反序列化攻击，但不支持延迟加载
- 使用 Holder 模式（即静态内部类）：代码简洁，JVM 保证仅在首次调用 getInstance 时才加载内部类并初始化实例
常见误区提醒
以下写法是错误或不安全的：
- 去掉 volatile —— 可能导致部分线程看到半初始化对象
- 把 synchronized 加在整个方法上（synchronized static getInstance）—— 效率低，每次调用都阻塞
- 用普通成员变量代替 static + volatile —— 不满足单例要求
- 在 getInstance 中直接 new 并赋值，无任何检查 —— 完全非线程安全
双重检查锁不是最简单的方式，但理解它有助于掌握并发编程中的可见性、有序性与同步粒度问题。实际项目中，优先考虑静态内部类或枚举方式。
