漏掉 volatile 会导致“提前发布”：JVM 可能将 new 拆解为分配内存→设置引用→执行构造，且②③步重排序，使线程读到未初始化的 instance，其字段为 null 或默认值，引发 NullPointerException 或逻辑错误。
漏掉 volatile 会导致对象被“提前发布”
在双重检查锁（DCL）单例中，如果单例引用没用 volatile 修饰，JVM 可能将 new Singleton() 拆解为三步：分配内存 → 设置引用 → 执行构造方法。而第②步和第③步可能被重排序——即引用先指向一块已分配但尚未完成初始化的内存空间。
此时另一个线程恰好执行到第一次判空，发现 instance 不为 null，就直接返回并使用该对象。但它的字段（比如 data、config 等）还没来得及赋值，仍保持默认值（null、0、false），一调用就会触发 NullPointerException 或逻辑错误。
泛型单例里这个问题更隐蔽
泛型擦除后，所有 Singleton<String> 和 Singleton<Integer> 共享同一个静态字段。若声明为：
-
private static Singleton<?> instance;（未加 volatile） - 构造函数里对泛型字段
this.data = data;赋值
那么即使类型参数不同，只要多个线程并发调用 getInstance()，仍可能读到 data == null 的“半成品”对象。这不是泛型的问题，而是缺少 volatile 导致的可见性+重排序叠加风险。
立即学习“Java免费学习笔记（深入）”；
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
不是每次都会出错，但无法预测何时崩溃
这个隐患属于“竞态条件”，是否触发取决于：
- CPU 缓存一致性协议（如 MESI）的行为
- JVM 版本与优化策略（尤其是 JIT 编译器是否启用重排序）
所以它往往在线上高并发、低概率复现，本地测试很难暴露，排查成本极高。
修复方式很简单，但必须做全
仅加 volatile 还不够，要同时满足：
- 单例引用字段声明为
private static volatile Singleton instance; - 确保构造函数内不发生
this逸出（比如注册监听、启动线程等） - 避免在构造过程中依赖其他非 volatile 共享状态
如果逻辑复杂，更推荐改用静态内部类或 Enum 单例——它们天然规避了 DCL 的所有陷阱。
