真实 Java 应用程序中的单例模式和损坏的双重检查锁定

Question

我正在阅读文章 双重检查锁定和单例模式，关于双重检查锁定如何被破坏，以及 StackOverflow 上的一些相关问题。

我已经多次使用这种模式/习惯用法，没有任何问题。自从我一直在使用 Java 5 以来，我的第一个想法是 Java 5 内存模型已经纠正了这个问题。然而文章说：

本文涉及Java内存 针对 Java 进行修改之前的模型 5.0；有关内存排序的陈述可能不再正确。 然而， 双重检查锁定惯用法仍然是 在新的内存模型下崩溃了。

这是一个真正的问题吗？如果是，在什么条件下？

Answer 1

说明关于双重检查锁定的单例示例，该示例看起来很聪明，但已被破坏

同步块的开始保证您看到最新的数据，但它不能保证重新排序，您不能期望获得一致的数据视图，除非您
也在同步块中。它不保证在同步部分中完成的变量修改对其他线程可见。只有进入同步块的线程才能保证看到更改。这就是双重检查锁定被破坏的原因 - 它在读者端不同步。 读取线程可能会看到单例不为空，但单例数据可能未完全初始化（可见）。

另一方面，排序是由 volatile 提供的，它保证了排序，例如写入 volatile 单例静态字段可以保证对单例对象的写入将在写入 volatile 静态字段之前完成。它不会阻止创建两个对象的单例；这是由同步提供的。
类最终静态字段不需要是易失性的。在 Java 中，JVM 解决了这个问题。

更多信息可以在：

• 双重检查锁定：聪明，但破碎
• “双重检查锁定已损坏”声明

Answer 2

人们很难确定他们的应用程序实际上受到了双重检查锁定故障的影响。事实上，由于各种原因，许多使用此习惯用法的应用程序可能永远不会遇到该问题。

但是，这并不意味着您应该使用它。仅存在不可量化的失败概率这一事实就足以说服您不要使用双重检查锁定，特别是因为有安全的替代方案。

你只是很幸运。

Answer 3

我们有一个应用程序使用了损坏的双重检查惯用法，并且它在很长一段时间内都运行良好 - 不，事实上，我从未遇到过这种惯用法的问题。当然，无论如何我都修复了它。

我想原因之一是线程可见性最终将在现实世界中实现。一旦达到，它就会留下来。所以是的，检测问题是否已经发生将非常困难。

我相信 String 的 hashCode() 实现部分依赖于这个事实...线程在看不到缓存时计算 hashCode，但最终它们开始看到。同时，重复计算意味着只是浪费了一些 CPU 时间，并且避免了内存效应的好处易失性语义胜过这种浪费的努力（至少这就是我猜他们以这种方式实现的原因）。有效使用的习惯用法是（实际的 String.hashCode() 实现）：

/** Cache the hash code for the string */
private int hash; // Defaults to 0

public int hashCode() {
    int h = hash;
    if (h == 0) {
        int off = offset;
        char val[] = value;
        int len = count;

        for (int i = 0; i < len; i++) {
            h = 31*h + val[off++];
        }
        hash = h;
    }
    return h;
 }

显然，在使用它之前必须进行大量思考和衡量。