volatile不能单独防止双重检查锁中的指令重排序，但配合synchronized和正确初始化顺序，可确保其他线程看到构造完成的对象；它通过禁止相关内存访问重排序并强制缓存刷新来实现，Java 5+才真正支持该语义。
volatile 能不能防止双重检查锁里的指令重排序
不能直接防止，但配合 synchronized 和恰当的初始化顺序，能确保其他线程看到构造完成的对象。关键不是 volatile 自己“阻止重排”，而是它禁止了编译器和 CPU 对该变量读写操作与前后某些内存访问的重排序，并强制刷新缓存。
常见错误现象：getInstance() 返回非 null 但对象字段仍为默认值（如 int field = 0 却本该是 42），本质是对象构造未完成就被发布（publish）出去了。
- 必须把单例引用声明为
volatile，否则new Singleton()的三步（分配内存、调用构造、赋值引用）可能被重排成“分配→赋值→构造” -
volatile不保证构造过程原子性，所以synchronized块仍不可省——它只管住“第一次创建”那一次 - Java 5+ 才真正修复了
volatile的语义（JSR-133），老 JDK（如 1.4）下无效
双重检查锁的标准写法长什么样
标准写法的核心是：两次判空 + volatile 引用 + synchronized 块内再判空。少任何一个环节都可能出问题。
public class Singleton {
private static volatile Singleton instance;
public static Singleton getInstance() {
if (instance == null) { // 第一次检查
synchronized (Singleton.class) {
if (instance == null) { // 第二次检查
instance = new Singleton(); // 这里有重排序风险，靠 volatile 拦住
}
}
}
return instance;
}
}
- 如果去掉
volatile，JIT 可能将instance = new Singleton()拆开并重排，导致其他线程拿到半初始化对象 - 如果只保留外层
if，高并发下会大量进入synchronized块，性能差；只保留内层if，则无法避免重复初始化 - 不要在
getInstance()里加参数或做复杂逻辑——它应该只是返回实例，否则破坏“惰性初始化”的前提
为什么不用 static 内部类替代 volatile + 双检锁
因为 static 内部类方式更简洁、安全，且无同步开销，JVM 类加载机制天然保证单例唯一性和初始化完成性。但它属于“饿汉式变体”，不适用于需要依赖外部参数或运行时配置的场景。
立即学习“Java免费学习笔记（深入）”；
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
使用场景差异：
- 纯静态单例（无构造参数、不依赖 Spring 或配置中心）→ 优先用
static内部类 - 需要传参初始化（比如
new DatabaseConnection(url)）→ 只能用双检锁 +volatile - 要兼容 Android 低版本（Dalvik）或某些裁剪 JVM →
static内部类仍可用，但双检锁需确认volatile行为是否被正确实现
容易被忽略的坑：volatile 不解决所有并发问题
volatile 只保障可见性和禁止特定重排序，不提供原子性。很多人误以为加了 volatile 就能随便改字段，结果出错。
典型翻车点：
-
volatile int counter;然后写counter++—— 这是读-改-写三步，volatile不保证这三步不被其他线程打断，要用AtomicInteger - 单例对象内部字段没加
volatile或同步，而外部又通过反射/序列化绕过构造函数 →volatile对引用本身有效，对对象内部状态无效 - 在非 final 字段上依赖
volatile实现“发布-订阅”模式，但没配合适当的 happens-before 链路（比如缺少同步块或锁释放）→ 其他线程仍可能看到旧值
最常被漏掉的是：volatile 解决的是“引用可见性”，不是“对象安全性”。对象一旦发布，它的字段是否线程安全，得看字段自己怎么设计。
