java - 在将 volatile 引用设置为引用新创建的对象后，线程是否仍然认为构造函数的效果正在发生？

Question

我读了here -

When thread A writes to a volatile variable and subsequently thread B reads that same variable, the values of all variables that were visible to A prior to writing to the volatile variable become visible to B after reading the volatile variable. So from a memory visibility perspective, writing a volatile variable is like exiting a synchronized block and reading a volatile variable is like entering a synchronized block

以下片段摘自 here这篇文章可以追溯到 2001 年，当时 volatile 关键字的语义不同。

class SomeClass {
  private Resource resource = null;
  public Resource getResource() {
    if (resource == null) {
      synchronized {
        if (resource == null) 
          resource = new Resource();
      }
    }
    return resource;
  }
}

如果引用是可变的，双重检查锁定是固定的。

private volatile Resource resource = null;

但是我是否需要将 Resource 类的成员字段也设置为易变的以确保线程安全？

编辑:

作者在同一篇文章中提到——易变也不是你想的那样

A commonly suggested nonfix is to declare the resource field of SomeClass as volatile. However, while the JMM prevents writes to volatile variables from being reordered with respect to one another and ensures that they are flushed to main memory immediately, it still permits reads and writes of volatile variables to be reordered with respect to nonvolatile reads and writes. That means -- unless all Resource fields are volatile as well -- thread B can still perceive the constructor's effect as happening after resource is set to reference the newly created Resource.

这意味着 Double Checked Locking 在 JDK 5 之前很好，考虑到资源字段也是易变的，或者类本身是不可变的。请提出建议。

Answer 1

在一些可追溯到 2001 年的旧 JVM 中，volatile 关键字的含义有时会被误解，因此实现无法正常运行 - 这就是第二个语句背后的原因引用您的问题，即 2001 年文章中的那个 - volatile 是 DCL 的非修复方法。

引用自:http://www.javamex.com/tutorials/synchronization_volatile_java_5.shtml

As of Java 5, accessing a volatile variable creates a memory barrier: it effectively synchronizes all cached copies of variables with main memory, just as entering or exiting a synchronized block that synchronizes on a given object. Generally, this doesn't have a big impact on the programmer, although it does occasionally make volatile a good option for safe object publication. The infamous double-checked locking antipattern actually becomes valid in Java 5 if the reference is declared volatile.

在 Java 5 中，事情发生了变化，写入/读取到 volatile 字段不能用非 volatile 读/写重新排序，所以你的代码中的所有事情都被声明在写入 volatile 之前发生在此写入之前执行。根据您的代码段:如果 Resource 类的成员字段是不可变的，则无需将它们设置为 volatile 即可让其他线程安全地读取它们。如果其他线程(构造和初始化 Resource 实例字段的线程除外)可以修改这些成员字段，那么您需要使它们成为线程安全的(例如，将它们标记为 volatile - 这只是简单内存屏障的示例，可能还不够)。考虑使用 volatile 的更改示例:

class SomeClass {
  private volatile Resource resource = null;
  public Resource getResource() {
    if (resource == null) {
      synchronized {
        if (resource == null) 
          resource = new Resource();
      }
    }
    return resource;
  }
}

Resource() 构造函数在将实例分配给 volatile 字段之前完全执行。读取线程将看到创建实例的线程写入的所有内存 - 因此所有初始化都是可见的，这意味着 resource 实例的发布是线程安全的。

要清楚:

The statement made by @BrianGoetz in the article from the 2001 that marking a field as volatile...

...still permits reads and writes of volatile variables to be reordered with respect to nonvolatile reads and write`s

doesn't hold anymore in modern JVMs (JVM >= Java5)

免责声明当我们谈到同步时，我们经常使用术语内存障碍，但许多消息来源指出，这种障碍实际上阻止了指令的重新排序，因此典型的内存障碍> 只是确保代码中声明在内存屏障点之前执行的所有内容(例如，进入同步块(synchronized block)、写入 volatile 变量)在您的程序到达内存屏障点之前真正执行(对于例如，您知道如果您读取对 volatile 变量的引用，它不会在构造函数真正完成并返回表单初始化之前发布)。没有没有刷新到主内存用于同步 - CPU缓存与其他场合一起写入主内存，使内存对多核CPU中的其他线程可见的是缓存一致性硬件