volatile 能禁止重排序并保证可见性，正确写法是 private static volatile singleton instance；静态内部类方式更优，利用类加载机制实现线程安全单例。
不加 volatile 时，new Singleton() 可能被重排序成“分配内存 → 设置引用 → 初始化”
Java 中 instance = new Singleton() 看似原子操作，实际分三步：分配对象内存、调用构造函数初始化、将引用赋值给 instance。JVM 和 CPU 可能对后两步重排序——即先让 instance 指向一块已分配但尚未初始化的内存地址。
此时另一个线程执行第一次检查：if (instance != null) 判定为真，直接返回该引用，接着调用其方法（比如 resource.doSomething()），而 resource 还是 null，触发 NullPointerException 或更隐蔽的数据错乱。
这种问题在 JDK 5 之前无法靠 volatile 彻底解决，但自 JSR-133 内存模型修订后，volatile 写操作会插入 StoreStore + StoreLoad 屏障，强制禁止其前后的指令重排序。
volatile 不是“替代锁”，而是补足 synchronized 缺失的可见性与有序性
synchronized 块能保证临界区的互斥和 happens-before 关系，但它只约束块内操作；外层的 if (instance == null) 是非同步读，不享受锁带来的内存语义保障。
也就是说：synchronized 能防止多个线程同时进块里创建实例，但不能保证一个线程刚在块里写完 instance，另一个线程立刻在块外读到“完全初始化好”的值。
必须靠 volatile 提供两件事：
- 写屏障：确保
instance = new Singleton()的全部初始化动作（包括构造函数内所有字段赋值）在引用发布前完成 - 读屏障：确保每次读
instance都从主内存加载最新值，而非本地 CPU 缓存中的旧快照
常见误写：volatile 修饰错位置或漏掉
错误写法一：private static Singleton instance; —— 没 volatile，重排序风险始终存在。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
错误写法二：private volatile Singleton instance; —— 实例变量不是 static，每个对象都有一份，根本不是单例。
正确写法唯一：private static volatile Singleton instance;
还要注意：构造函数必须是私有的，且不能在其中泄露 this 引用（比如启动线程、注册监听器），否则即使加了 volatile，其他线程也可能拿到未初始化完成的对象。
如果只是要一个线程安全单例，其实有更好的选择
双重检查锁 + volatile 是可行解，但不是最优解。它依赖 JVM 内存模型细节，代码易错、难验证、可读性差。
更推荐用静态内部类方式：
public class Singleton {
private Singleton() {}
private static class Holder {
static final Singleton INSTANCE = new Singleton();
}
public static Singleton getInstance() {
return Holder.INSTANCE;
}
}
利用类加载机制的天然线程安全性，无须 synchronized、无须 volatile、延迟加载、语法简洁。真正需要手动控制初始化时机或带参数构造时，才考虑 DCL。
那个 volatile 字眼看着小，却是横跨编译器、JIT、CPU cache 三层的内存契约——漏掉它，等于在并发逻辑里埋了一颗不确定何时爆炸的雷。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
