DCL在Java 5前因volatile重排序约束弱易致“半初始化”；JDK 5+需用volatile保证安全；推荐静态内部类方案，线程安全、延迟加载、无同步开销。
为什么直接用双重检查锁（DCL）容易出错
Java 5 之前，volatile 关键字对重排序约束较弱，即使写了双重检查锁，JVM 或 CPU 仍可能将 new Singleton() 的构造步骤（分配内存 → 初始化字段 → 设置引用）重排，导致其他线程看到一个未完全初始化的对象。这是最典型的“半初始化”问题。
常见错误现象包括：某个线程调用 getInstance() 后拿到非 null 实例，但访问其字段时抛出 NullPointerException 或读到默认值（如 0、false）。
- 必须把实例字段声明为
volatile，否则 DCL 不安全 - JDK 5+ 才保证
volatile的写-读语义能禁止相关重排序 - 不要在
Singleton构造器中启动线程、注册回调或调用可被子类重写的方法——这会暴露this引用
推荐做法：使用静态内部类实现延迟加载
这是目前最简洁、安全、且无需同步的方案。JVM 保证类的初始化是线程安全的，且仅在首次主动使用该类时触发（即调用 Holder.INSTANCE 时才加载 Holder 类）。
public class Singleton {
private Singleton() {}
<pre class='brush:java;toolbar:false;'>private static class Holder {
static final Singleton INSTANCE = new Singleton();
}
public static Singleton getInstance() {
return Holder.INSTANCE;
}}
立即学习“Java免费学习笔记（深入）”；
优势明显：
- 无显式同步，无
volatile，无 CAS，性能开销几乎为零 - 天然线程安全，由 JVM 类加载机制保障
- 真正延迟：直到第一次调用
getInstance()才创建实例 - 兼容所有 JDK 版本（包括 JDK 1.2+）
如果必须用枚举，要注意单例的可序列化行为
枚举是 Java 中唯一能天然防止反序列化破坏单例的方式，但它的延迟性不如静态内部类——枚举类在首次被“主动使用”（如访问其常量、调用其方法）时就完成初始化，不是严格意义上的“按需加载”。
public enum Singleton {
INSTANCE;
<pre class='brush:java;toolbar:false;'>public void doSomething() { /* ... */ }}
立即学习“Java免费学习笔记（深入）”；
使用场景有限制：
- 不能继承其他类（枚举已隐式继承
java.lang.Enum） - 不能用于需要实现
Serializable以外接口并动态代理的场景 - 若类有复杂初始化逻辑（如依赖 Spring 容器），枚举无法注入依赖
别碰 AtomicReference + compareAndSet 实现延迟初始化
除非你明确要支持“多次尝试初始化并容忍失败重试”，否则没必要手动用 AtomicReference 模拟懒汉。它代码冗长、易出错，且在高竞争下性能反而不如静态内部类或 DCL（加了 volatile）。
典型误用：
- 忘记用
new AtomicReference<Singleton>()初始化，导致 NPE - 在
compareAndSet(null, newInstance)失败后没正确返回已存在的实例，造成内存泄漏或重复构造 - 误以为 CAS 能替代内存屏障作用——其实仍需配合
volatile语义才能安全发布对象
真正需要原子初始化控制的场景极少，多数时候是过早优化。
