为什么在双重检查锁定中使用了volatile

在Head First设计模式手册中，具有双重检查锁定的单例模式已实现如下：

public class Singleton {
    private volatile static Singleton instance;
    private Singleton() {}
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

我不明白为什么volatile要使用它。volatile使用不会 违反使用双重检查锁定（即性能）的目的吗？

JCIP书籍volatile提供了一个很好的资源，可以理解为什么需要这样做。维基百科也对该材料进行了不错的解释。

真正的问题是Thread A可能instance在完成构造之前为其分配存储空间instance。Thread B将看到该作业并尝试使用它。Thread B由于使用的是的部分构造版本，因此导致失败instance。

正如@irreputable所引用的那样，volatile并不昂贵。即使价格昂贵，一致性也应优先于性能。

懒惰单身人士还有另一种干净优雅的方式。

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

来源文章：来自Wikipedia的Initial-on-demand_holder_idiom

在软件工程中，按需初始化（设计模式）惯用语是一个延迟加载的单例。在所有Java版本中，该习惯用法都可以实现安全，高度并发的延迟初始化以及良好的性能。

由于该类没有任何static要初始化的变量，因此初始化很容易完成。

LazyHolder在JVM确定必须执行LazyHolder之前，不会初始化其中的静态类定义。

静态类LazyHolder时静态方法时，才会执行getInstance是在该类的Singleton调用，并在第一时间发生这种情况，JVM将加载和初始化LazyHolder类。

该解决方案是线程安全的，不需要特殊的语言构造（即volatile或synchronized）。

好吧，没有针对性能的双重检查锁定。这是一个破碎的模式。

撇开情绪，这volatile是因为在第二个线程通过时没有它instance == null，第一个线程可能尚未构建new Singleton()：没有人保证对象的创​​建会发生在分配给instance任何线程之前，而实际上是创建对象。

volatile依次建立读写之间的先发生后关系，并修复损坏的模式。

如果您正在寻找性能，请改为使用Holder内部静态类。

如果没有，则在第一个将同步块设置为null后，第二个线程可能会进入同步块，并且本地缓存仍会认为它为null。

第一个不是出于正确性（如果您是对的，那将是自我挫败），而是出于优化目的。

将变量声明为as可以volatile确保对它的所有访问实际上都从内存中读取其当前值。

如果没有volatile，则编译器可优化掉的存储器访问，以变量（例如保持其值在寄存器），因此，只有在第一次使用该变量的读取实际存储器位置保持变量。如果变量在第一次访问和第二次访问之间被另一个线程修改，则会出现问题。第一个线程只有第一个（预修改）值的副本，因此第二条if语句测试变量值的陈旧副本。

易失性读取本身并不真正昂贵。

您可以设计一个测试来getInstance()紧密循环调用，以观察易失性读取的影响。但是，这种测试是不现实的；在这种情况下，程序员通常会调用getInstance()一次并在使用期间缓存实例。

另一个暗示是通过使用final字段（请参阅维基百科）。这需要额外的读取，这可能会比volatile版本贵。该final版本可能在一个紧密的循环中更快，但是该测试尚无定论。

双重检查锁定是一种防止getInstance在多线程环境中调用方法时创建另一个单例实例的技术。

请注意

• 初始化之前，对Singleton实例进行了两次检查。
• 出于这个原因，只有在首先检查单例实例之后才使用同步关键部分。
• volatile实例成员声明上的关键字。这将告诉编译器始终从主内存而不是从CPU高速缓存读取和写入。使用volatile变量保证事前发生关系，所有写操作都将在实例变量的任何读取之前发生。

缺点

• 由于需要 volatile关键字正常工作，因此它与Java 1.4及更低版本不兼容。问题在于，无序写入可能允许实例引用在执行单例构造函数之前被返回。
• 由于易失性变量的缓存减少而导致的性能问题。
• 在初始化之前，两次检查了Singleton实例。
• 它非常冗长，使代码难以阅读。

单例模式有几种实现，每种都有优点和缺点。

• 渴望加载单身人士
• 双重检查锁定单身人士
• 按需初始化持有人惯用语
• 基于枚举的单例

详细说明每个都太冗长，因此我只链接了一篇好文章-您想了解的有关Singleton的全部信息