设计线程安全的延迟初始化单例模式并分析Java内存模型下的可见性问题

题目

设计线程安全的延迟初始化单例模式并分析Java内存模型下的可见性问题

信息

• 类型：问答
• 难度：⭐⭐⭐

考点

单例模式实现,volatile关键字原理,双重检查锁定,Java内存模型可见性,类初始化机制

快速回答

实现线程安全的延迟初始化单例需要：

• 使用volatile修饰实例变量防止指令重排序
• 采用双重检查锁定（DCL）减少同步开销
• 私有化构造方法防止外部实例化
• 考虑类初始化方案的替代实现

核心原理：volatile通过内存屏障保证可见性和禁止重排序，解决DCL失效问题。

解析

问题背景

在并发环境下实现延迟初始化的单例模式时，由于Java内存模型的指令重排序特性，看似正确的双重检查锁定（DCL）可能返回未完全初始化的对象。需要深入理解JMM的happens-before规则来解决此问题。

解决方案代码

public class Singleton {
    // volatile 禁止指令重排序
    private static volatile Singleton instance;

    private Singleton() {
        // 防止反射攻击
        if (instance != null) {
            throw new IllegalStateException("Already initialized");
        }
    }

    public static Singleton getInstance() {
        // 第一次检查（无锁）
        if (instance == null) {
            synchronized (Singleton.class) {
                // 第二次检查（加锁）
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

原理说明

关键问题： instance = new Singleton() 包含三个步骤：

1. 分配内存空间
2. 初始化对象
3. 将引用指向内存地址

JVM可能重排序为1→3→2，导致其他线程获取到未初始化的实例。

volatile的作用：

• 禁止步骤2和3的重排序（通过内存屏障）
• 保证写操作对后续读操作的可见性（MESI缓存一致性协议）
• 建立happens-before关系，确保构造方法结束前所有操作对其它线程可见

最佳实践

• 替代方案1：静态内部类（推荐）

  public class Singleton {
      private Singleton() {}
  
      private static class Holder {
          static final Singleton INSTANCE = new Singleton();
      }
  
      public static Singleton getInstance() {
          return Holder.INSTANCE;
      }
  }

  利用类加载机制保证线程安全（JLS 12.4.2规定类初始化阶段加锁）

• 替代方案2：枚举单例（防反射攻击）

  public enum Singleton {
      INSTANCE;
      // 添加方法
      public void execute() { ... }
  }

常见错误

• 忘记volatile修饰符（概率性出现未初始化对象）
• 错误使用同步范围（如在方法上加synchronized导致性能瓶颈）
• 忽略反射/反序列化破坏单例的可能性
• 在DCL中未完全初始化就发布对象引用

扩展知识

• JMM内存屏障： volatile写之前插入StoreStore屏障，写之后插入StoreLoad屏障
• 安全发布模式： 除volatile外，还可通过final字段、静态初始化器或AtomicReference实现
• JLS规范： 参考JLS 17.4内存模型章节的happens-before原则
• 现代JVM优化： 新版JDK已修复DCL问题，但显式声明volatile仍是编码最佳实践