DCL是懒汉式单例中兼顾线程安全与性能的优化方案，需用volatile修饰静态实例以禁止指令重排序、确保构造完成才可见，并依赖两次判空——第一次无锁避免竞争，第二次有锁防止重复创建。
双重检查锁（DCL）不是万能的，但配合正确的静态变量声明，它能在懒汉式单例中兼顾线程安全与性能。关键不在“加不加锁”，而在“什么时候检查、怎么赋值、谁能看到完整状态”。
volatile 是静态实例变量的必需修饰符
声明单例引用时，必须用 private static volatile Singleton instance;。这不是可选项，而是防止 JVM 指令重排序导致其他线程拿到半初始化对象的核心防线。
对象创建实际分三步：分配内存 → 调用构造函数初始化 → 将引用指向该内存地址。没有 volatile 时，JVM 可能重排为“分配内存 → 引用赋值 → 初始化”，此时另一个线程看到 instance 不为 null，却读到未初始化的字段，引发空指针或逻辑错误。
volatile 同时保障两点：
- 禁止上述重排序，确保构造完成后再对外可见
- 让所有线程对 instance 的读写都直接操作主内存，避免因 CPU 缓存不一致导致多次创建
双重检查的两次判空缺一不可
第一次检查在锁外，目的是避免绝大多数调用进入临界区；第二次检查在锁内，是真正决定是否创建实例的最终判断。
漏掉任一次都会出问题：
- 只保留锁内检查 → 每次调用都要抢锁，性能退化成同步方法
- 只保留锁外检查 → 多线程可能同时通过判断，各自 new 出不同实例
标准结构如下（Java 示例）：
if (instance == null) {synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
}
静态变量初始化时机决定线程安全基础
静态变量本身不具备线程安全性，它的安全来自使用上下文。在 DCL 中，instance 初始值必须是 null（不能是 new Singleton()），否则就变成饿汉式，失去懒加载意义。
类加载阶段对静态变量的赋值是线程安全的，但那仅适用于饿汉式。DCL 属于懒汉式变体，所以 instance 必须显式初始化为 null，并靠双重检查 + volatile + 锁协同保证后续赋值的安全性。
常见误写：
private static Singleton instance = new Singleton(); // 这是饿汉式，不是 DCL
C++ 和 Java 的实现差异要特别注意
Java 依赖 volatile + synchronized；C++11 及以后更推荐用函数内静态局部变量，编译器自动保证首次初始化的线程安全，代码更简洁且无锁开销：
static Singleton& getInstance() {static Singleton instance;
return instance;
}
若必须手写 DCL，C++ 需用 std::atomic
