双重检查锁定在java中失效是因为jvm指令重排序与引用可见性未同步，导致线程可能看到未完全初始化的instance；必须用volatile修饰instance字段以建立happens-before关系。
双重检查锁定为什么在Java里会失效
因为JVM的指令重排序 + 线程对对象引用的可见性未同步，导致一个线程看到instance非空，但实际构造函数还没执行完。这不是“偶尔出错”，而是在没有volatile时必然存在的内存模型漏洞。
典型现象：某线程调用getInstance()后拿到一个instance，但访问其字段时报NullPointerException，或字段值为默认值（如int为0、String为null）——说明对象已被分配内存并赋值给instance，但初始化尚未完成。
- 根本原因不是多线程竞争new操作，而是JVM允许将
new Singleton()拆解为：①分配内存 → ②初始化字段 → ③将引用写入instance；而步骤②和③可能被重排序 -
synchronized块内能保证原子性，但块外的第一次判空读取instance != null不具happens-before关系，无法保证看到完全初始化的对象 - 该问题在x86上较难复现（因强内存模型），但在ARM、JIT优化激进的场景下极易触发
必须用volatile修饰单例引用变量
加volatile不是为了“禁止重排序”本身，而是建立happens-before关系：对volatile变量的写操作，对其他线程后续的读操作可见，且强制刷新主内存视图。
错误写法：private static Singleton instance; → 即使加了双重检查也无效
立即学习“Java免费学习笔记（深入）”；
正确写法：private static volatile Singleton instance;
- 仅修饰
instance字段即可，不需要对构造函数、方法加volatile - 不能用
final替代：虽然final域有初始化安全保证，但它只作用于对象内部字段，不解决instance引用本身的可见性问题 - Java 5+ 才正式支持
volatile的内存语义；JDK 1.4及之前版本即使写了volatile也无效
双重检查锁定的标准实现长什么样
去掉所有装饰性逻辑，最简可用版本就是下面这样。任何增删都可能引入风险。
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();
}
}
}
return instance;
}
}
- 两个
if (instance == null)缺一不可：第一个避免无谓加锁，第二个防止重复初始化 -
synchronized必须锁Singleton.class（或当前类的唯一Class对象），不能锁this或新建对象 - 不要在
getInstance()里加参数、日志、计数器等副作用逻辑——它必须是纯的、幂等的获取操作 - 如果类有静态字段需初始化，确保它们不依赖
instance的创建顺序；否则应改用静态内部类方式
比双重检查更稳妥的替代方案
除非有明确性能压测数据证明synchronized成为瓶颈，否则优先选更简单、更不易出错的方式。
- 静态内部类：利用JVM类加载机制的天然线程安全，无须
volatile，无同步开销 ——private static class Holder { static final Singleton INSTANCE = new Singleton(); } - 枚举单例：JVM保证枚举实例创建的原子性与全局唯一性，还能防反射/反序列化攻击 ——
enum Singleton { INSTANCE; } - Spring等容器管理的Bean默认就是单例，无需手写 —— 直接声明
@Scope("singleton")或默认配置即可
真正需要双重检查的场景极少：通常是高性能基础组件（如日志器、配置中心客户端），且确认过静态内部类因类加载时机问题不适用。
