为什么要这么做？因为在并发场景下，双重检查锁（DCL）确实存在严重问题——
问题的核心根源
指令重排序
helper=newHelper();// 这不是原子操作实际上包含三个步骤：
- 为
Helper对象分配内存空间 - 调用构造函数初始化对象
- 将引用赋值给
helper变量
问题在于：步骤2和步骤3可能被JVM重排序，导致另一个线程看到一个未完全初始化的对象。
具体场景分析
// 线程1执行helper=newHelper();// 重排序后：分配内存 → 赋值引用 → 初始化// 在线程1赋值引用后、初始化前，线程2进入if(helper==null){// helper不为null，但对象未初始化！// 跳过同步块returnhelper;// 返回一个半成品对象！}JDK5+的推荐解决方案
使用volatile关键字
classSingleton{privatevolatileHelperhelper=null;// 关键：添加 volatilepublicHelpergetHelper(){if(helper==null){// 第一次检查（无锁）synchronized(this){// 加锁if(helper==null){// 第二次检查（有锁）helper=newHelper();// 安全初始化}}}returnhelper;}}volatile如何解决问题
1.禁止指令重排序
- 在
volatile写之前的所有操作，都不会被重排序到写之后 - 在
volatile读之后的所有操作，都不会被重排序到读之前 - 具体来说：
helper = new Helper()的初始化操作（构造函数调用）会在赋值之前完成
2.保证内存可见性
- 当一个线程修改
volatile变量时，新值会立即被刷新到主内存 - 其他线程读取
volatile变量时，会从主内存重新加载最新值
3.建立 happens-before 关系
根据JSR-133（Java内存模型增强）：
- 对
volatile变量的写操作 happens-before 于后续对该变量的读操作 - 这保证了所有线程看到的初始化状态是一致的
完整的线程安全示例
publicclassSafeDoubleCheckedLocking{// 必须使用 volatile 修饰privatevolatileResourceresource;publicResourcegetResource(){// 第一次检查：大多数情况不需要同步，提升性能Resourceresult=resource;if(result==null){// 同步块：确保只有一个线程初始化synchronized(this){result=resource;if(result==null){// volatile 保证初始化完成前不会发布引用resource=result=newResource();}}}returnresult;}staticclassResource{// 资源类的定义publicResource(){// 复杂的初始化逻辑}}}为什么这个方案适用于JDK5+
Java内存模型的演进
- JDK 1.4及之前：DCL根本无法正确实现，
volatile语义不完整 - JDK 5（JSR-133）：重新定义了内存模型，强化了
volatile的语义- 禁止特定类型的指令重排序
- 建立了更强的 happens-before 关系
- 修复了DCL的根本问题
替代方案比较
| 方案 | 优点 | 缺点 |
|---|---|---|
| volatile + DCL | 性能好（大多数情况无锁） | 代码稍复杂，需要JDK5+ |
| 静态内部类 | 简洁安全，延迟加载 | 无法传参初始化 |
| 枚举单例 | 绝对安全，防止反射攻击 | 不够灵活 |
| synchronized方法 | 简单安全 | 每次访问都同步，性能差 |
最佳实践建议
优先考虑其他单例模式
- 静态内部类（如果不需要传参）
- 枚举单例（如果需要绝对安全）
必须使用DCL时
// 确保：// 1. 使用 volatile// 2. 使用JDK5+// 3. 两次检查都不省略性能考量
- DCL在初始化后几乎没有性能损耗
- 适合初始化成本高、频繁访问的场景
