Java双重检查锁定

Question

我碰巧发表了一篇文章，最近讨论了Java中的双重检查锁定模式及其陷阱，现在我想知道我多年来一直使用的那种模式的变体是否会受到任何问题的影响。

我已经查看了很多有关该主题的帖子和文章，并了解了获取对部分构造对象的引用的潜在问题，据我所知，我不认为我的实现受这些问题的影响。 以下模式是否有任何问题？

而且，如果没有，为什么人们不使用它？ 我在这个问题的任何讨论中都没有看过它。

public class Test {
    private static Test instance;
    private static boolean initialized = false;

    public static Test getInstance() {
        if (!initialized) {
            synchronized (Test.class) {
                if (!initialized) {
                    instance = new Test();
                    initialized = true;
                }
            }
        }
        return instance;
    }
}

Answer 1

双重检查锁定被打破 。 由于initialized是一个原语，因此它可能不需要它可以工作，但是在初始化实例之前，没有什么能阻止初始化被视为对非同步代码的真实性。

编辑：为了澄清上面的答案，原始问题询问使用布尔值来控制双重检查锁定。 如果没有上面链接中的解决方案，它将无法正常工作。 您可以仔细检查实际设置布尔值的锁定，但在创建类实例时仍然存在有关指令重新排序的问题。 建议的解决方案不起作用，因为在非同步块中看到初始化的布尔值为true后，实例可能无法初始化。

双重检查锁定的正确解决方案是使用volatile（在实例字段上）并忘记初始化的布尔值，并确保使用JDK 1.5或更高版本，或者在最终字段中初始化它，如链接中详细说明的那样文章和汤姆的回答，或者只是不使用它。

当然，整个概念似乎是一个巨大的过早优化，除非你知道你将获得大量的线程争用获得这个Singleton，或者你已经分析了应用程序，并已经看到这是一个热点。

Answer 2

如果initialized是volatile这将起作用。 就像使用synchronized ， volatile的有趣效果并不像我们可以对其他数据说的那么多。 在写入initialized 之前 ，强制设置instance字段和Test对象。 通过短路使用缓存值时， initialize读取发生在读取instance和通过引用到达的对象之前 。 具有单独的initialized标志没有显着差异（除了它导致代码中更复杂）。

（不安全发布的构造函数中的final字段规则略有不同。）

但是，在这种情况下，您应该很少看到错误。 第一次使用时遇到麻烦的可能性很小，而且是一次非重复比赛。

代码过于复杂。 你可以把它写成：

private static final Test instance = new Test();

public static Test getInstance() {
    return instance;
}

Answer 3

双重检查锁定确实被破坏了，问题的解决方案实际上比这个习惯用法更简单 - 只需使用静态初始化程序。

public class Test {
    private static final Test instance = createInstance();

    private static Test createInstance() {
        // construction logic goes here...
        return new Test();
    }

    public static Test getInstance() {
        return instance;
    }
}

保证在JVM第一次加载类时，以及在类引用可以返回到任何线程之前执行静态初始化程序 - 使其本身具有线程安全性。

Answer 4

这就是为什么双重检查锁定被打破的原因。

同步保证，只有一个线程可以输入代码块。 但它并不能保证在同步部分内完成的变量修改对其他线程是可见的。 只有进入同步块的线程才能保证看到更改。 这就是为什么双重检查锁定被打破的原因 - 它在读者方面没有同步。 读取线程可以看到单例不为空，但单例数据可能未完全初始化（可见）。

订购由volatile提供。 volatile保证排序，例如写入volatile单独的静态字段，保证在写入volatile静态字段之前完成对singleton对象的写入。 它不会阻止创建两个对象的单例，这是通过同步提供的。

类最终静态字段不需要是易失性的。 在Java中， JVM负责这个问题。

请参阅我的帖子， 回答一个真实世界的Java应用程序中的Singleton模式和双重检查锁定 ，说明了一个关于双重检查锁定的单例的例子，它看起来很聪明但是被破坏了。

Answer 5

如果“initialized”为真，那么“instance”必须完全初始化，就像1加1等于2 :)。 因此，代码是正确的。 该实例仅被实例化一次，但该函数可能被调用一百万次，因此它确实提高了性能，而无需检查一百万次减去一次的同步。

Answer 6

在某些情况下，可能会使用双重检查。

1. 首先，如果你真的不需要单例，那么双重检查仅用于NOT创建和初始化为许多对象。
2. 在构造函数/初始化块的末尾设置了一个final字段（这会导致其他线程看到所有先前初始化的字段）。

Answer 7

您应该使用java.util.concurrent.atomic中的原子数据类型。

Answer 8

我一直在研究双重检查的锁定习语，根据我的理解，你的代码可能导致读取部分构造的实例的问题，除非你的Test类是不可变的：

Java Memory Model为共享不可变对象提供了初始化安全性的特殊保证。

即使不使用同步来发布对象引用，也可以安全地访问它们。

（来自非常可取的书籍Java Concurrency in Practice的引文）

因此，在这种情况下，双重检查锁定成语将起作用。

但是，如果不是这种情况，请注意您在没有同步的情况下返回变量实例，因此可能无法完全构造实例变量（您将看到属性的默认值而不是构造函数中提供的值）。

布尔变量不会添加任何东西来避免问题，因为在初始化Test类之前它可能被设置为true（synchronized关键字不能完全避免重新排序，某些步骤可能会改变顺序）。 Java内存模型中没有事先发生的规则来保证这一点。

并且使布尔volatile也不会添加任何东西，因为在Java中原子地创建了32位变量。 双重检查的锁定习语也适用于它们。

从Java 5开始，您可以修复将实例变量声明为volatile的问题。

您可以在这篇非常有趣的文章中阅读有关双重检查成语的更多信息。

最后，我读过一些建议：

• 考虑是否应该使用单例模式。 它被许多人认为是一种反模式。 在可能的情况下，首选依赖注入。 检查一下 。

• 在实施之前，如果确实需要双重检查锁定优化，请仔细考虑，因为在大多数情况下，这是不值得的。 另外，考虑在静态字段中构造Test类，因为延迟加载仅在构造类占用大量资源时才有用，并且在大多数情况下，情况并非如此。

如果您仍需要执行此优化，请查看此链接 ，该链接提供了一些替代方案，以实现与您尝试的类似效果。

Answer 9

尽管DCL似乎适用于许多虚拟机，但DCL问题仍然存在。 http://www.javaworld.com/article/2075306/java-concurrency/can-double-checked-locking-be-fixed-.html这里有一个很好的关于这个问题的文章。

多线程和记忆一致性是比它们看起来更复杂的主题。 [...]如果您只是使用Java为此目的提供的工具 - 同步，您可以忽略所有这些复杂性。 如果同步对可能已编写的变量的每次访问，或者可以由另一个线程读取的变量，则不会出现内存一致性问题。

正确解决此问题的唯一方法是避免延迟初始化（急切地执行）或在同步块内单独检查。 使用boolean initialized等效于对引用本身的null检查。 第二个线程可能看到initialized为true但instance可能仍为null或部分初始化。

Answer 10

双重检查锁定是反模式。

延迟初始化持有者类是您应该关注的模式。

尽管有这么多其他的答案，我想我应该回答，因为仍然没有一个简单的答案说明为什么DCL在许多情况下被打破，为什么它是不必要的以及你应该做什么。 所以我将使用Goetz: Java Concurrency In Practice的一句话Goetz: Java Concurrency In Practice ，对我来说，它在Java内存模型的最后一章中提供了最简洁的解释。

这是关于变量的安全发布：

DCL的真正问题是假设在没有同步的情况下读取共享对象引用时可能发生的最糟糕的事情是错误地看到过时的值（在这种情况下，为null）; 在这种情况下，DCL惯用法通过再次尝试锁定来补偿这种风险。 但最坏的情况实际上要差得多 - 有可能看到参考的当前值但对象状态的陈旧值，这意味着可以看到对象处于无效或不正确的状态。

JMM（Java 5.0及更高版本）中的后续更改使DCL能够在资源变为易失性时工作，并且由于易失性读取通常仅比非易失性读取稍微昂贵，因此性能影响很小。

然而，这是一个习惯已经基本通过的成语 - 激发它的力量（缓慢的无竞争同步，慢速JVM启动）不再起作用，使其作为优化效率降低。 懒惰的初始化持有者习语提供了相同的好处，并且更容易理解。

代码清单16.6 延迟初始化持有者类成语。

 public class ResourceFactory private static class ResourceHolder { public static Resource resource = new Resource(); } public static Resource getResource() { return ResourceHolder.resource; } } 

这是做到这一点的方法。

Answer 11

首先，对于单身人士，你可以使用Enum，正如这个问题中所解释的那样用Enum实现Singleton（用Java编写）

其次，从Java 1.5开始，您可以使用具有双重检查锁定的volatile变量，如本文末尾所述： https ： //www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html