为什么后续的 Java 内存模型修订要求使用 volatile 语义以确保双重检查锁定模式的安全性？

对问题的回答

历史

在 Java 5 之前，Java 内存模型（JMM）存在内存可见性保证较弱的问题，这使得许多流行的并发习惯用法变得不安全。双重检查锁定模式在 1990 年代后期出现，作为延迟初始化的性能优化，但其存在一个关于指令重排序的致命缺陷。JSR-133 在 2004 年重新定义了 volatile 关键字的语义，以提供获取-释放内存顺序，特别是为了解决可见性问题，而无需完全同步的开销。

问题

在没有 volatile 的情况下，JVM 和底层 CPU 架构被允许重排指令，使得对变量的引用赋值可能在构造函数执行完成之前就发生。这就创造了一个窗口，其他线程可以观察到一个非空引用，指向一个其字段包含默认或未初始化值的对象，从而导致不可预测的行为或 NullPointerException。这种并发风险特别隐蔽，因为它仅在特定的时序条件和硬件内存模型下表现出来，测试时难以重现。

解决方案

将实例字段声明为 volatile 会插入一个内存屏障，建立构造函数中写入和其他线程随后的读取之间的发生-之前关系。这防止编译器和处理器将对 volatile 字段的写入与构造函数中的先前写入顺序重排，确保在引用变得可见之前，对象已完全构造。该模式允许线程在初始化后检查引用而无需加锁，既提供了线程安全性，又保证了高性能。

public class ConnectionPool {
    private static volatile ConnectionPool instance;
    
    private ConnectionPool() {
        // 复杂初始化
    }
    
    public static ConnectionPool getInstance() {
        if (instance == null) {
            synchronized (ConnectionPool.class) {
                if (instance == null) {
                    instance = new ConnectionPool();
                }
            }
        }
        return instance;
    }
}

生活中的情况

一项高吞吐量的微服务处理支付流程需要一个单例的 ConnectionPool 来管理 JDBC 连接到 PostgreSQL 集群。在高峰期，成千上万的线程同时调用 getInstance() 当服务首次启动时，这需要一个线程安全的初始化策略，以尽量减少锁的竞争。初始化序列涉及建立 TCP 套接字、分配直接字节缓冲区以及执行模式验证查询，这使得急切实例化在自动扩展场景下变得开销巨大。

急切初始化

急切初始化 涉及在静态初始化块中创建池。该方法通过类加载机制保证线程安全，并完全消除了对 synchronized 块的需求。然而，连接建立需要三秒的 TCP 握手和凭证交换，这违反了在自动扩展事件中对冷启动时间的服务级别协议。

同步方法

同步方法 使用 synchronized 关键字封装了 getInstance() 方法。虽然这通过序列化所有访问修正了竞争条件，但在负载下引入了严重的性能降级。分析显示，在初始化后，线程在获取监视器锁时浪费了不必要的周期，尽管完全构造的池是不可变的，大约增加了每次调用 18 毫秒的延迟。

带有 volatile 的双重检查锁定

带有 volatile 的双重检查锁定 被选为最佳方法。该解决方案采用未同步的快速路径检查 null，随后在关键区域内使用 synchronized 块，并在其中进行第二次 null 检查以防止多个实例化。volatile 修饰符确保完全初始化的池状态在发布时立即对所有 CPU 内核可见，平衡了延迟初始化与启动后零锁的开销。

所选的解决方案实现了成功的延迟初始化而没有阻塞，使服务能够在初始池创建后处理每秒 50,000 个请求，并且响应时间小于毫秒。在启动过程中消除了竞争条件，同时在稳定状态操作期间保持无锁访问，防止在高并发场景下发生的 NullPointerException 实例。监控确认 JVM 在单例建立后正确处理了所有 64 核心之间的内存可见性，而无需显式同步。

候选人常常忽略的内容

为什么双重检查锁定模式需要两个独立的 null 检查，而不是单次的同步检查？

第一次检查在 synchronized 块外进行，以提供快速的无锁路径，适用于实例已经存在的常见案例。第二次检查在 synchronized 块内是必要的，因为多个线程可以同时通过第一次 null 检查，而实例仍未初始化。如果没有这第二次验证，每个线程将依次获取锁并创建单独的实例，从而违反单例属性。内部检查确保只有第一个进入关键区的线程进行构造，而后续线程发现实例已初始化并跳过创建。

Java 内存模型如何区分 volatile 写入和同步块退出的可见性保证？

这两种结构建立了发生-之前关系，但它们在不同的粒度和性能特征上运作。synchronized 块退出会将线程工作内存中所有修改过的变量刷新到主内存，起到全局内存屏障的作用。相反，volatile 写入特别防止该特定变量与周围指令的重排序，并确保写入立即可见。在 Java 5 之前，volatile 缺乏这些保证，导致其不足以安全发布；现代 JMM 将 volatile 写入视为与 C++ 的释放操作相似，并将读取视为获取操作，提供有针对性的可见性，而不需要监视锁定的全部成本。

不可变对象能否消除双重检查锁定模式中对 volatile 的需求？

不能，因为 final 字段只保证在构造函数完成后才会有不可变性，而不仅仅是在引用本身发布时。没有 volatile，指令重排序可能会导致引用在构造函数执行完成之前被写入主内存，从而允许另一个线程观察到一个非空引用指向一个部分构造的对象。虽然 final 字段确保构造后值不能更改，但如果引用提前逃逸，则无法防止默认或未初始化值的可见性。安全发布要求使用 volatile 或 synchronized 以确保构造与可见性之间的发生-之前关系，无论对象的内部不可变性如何。