java-在将可变引用设置为引用新创建的对象之后,线程是否仍会感知构造函数的影响？

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了java-在将可变引用设置为引用新创建的对象之后,线程是否仍会感知构造函数的影响？，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含3828字，纯文字阅读大概需要6分钟。

内容图文

我读了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类的成员字段设置为volatile,以确保线程安全？

编辑：

作者在同一篇文章中提到-
波动也不意味着你在想什么

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.

这意味着双重检查锁定在JDK 5之前是可以的
资源字段也是可变的,或者类本身是不可变的.
请提出建议.

解决方法:

在某些可以追溯到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的写入实际在此写入之前执行之前发生的事情.根据您的摘录：如果Resource类的成员字段是不可变的,则无需使其具有可变性即可使其安全地被其他线程读取.如果其他线程(构造和初始化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;
  }
}

在将实例分配给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)

免责声明
在谈到同步时,我们通常使用术语“内存屏障”,但是许多消息来源指出,这种屏障实际上阻止了指令的重新排序,因此典型的内存屏障只是确保声明中的所有代码都将被执行.在程序到达内存屏障点之前(例如,您知道如果您读取了对易失变量的引用,则该内存屏障点(例如,进入同步块,写入易失性变量)才真正执行过构造函数真正完成并返回表单初始化).没有刷新到主内存以进行同步-CPU高速缓存在其他情况下被写入主内存,使内存对多核CPU中的其他线程可见的是高速缓存一致性硬件

内容总结

以上是互联网集市为您收集整理的java-在将可变引用设置为引用新创建的对象之后,线程是否仍会感知构造函数的影响？全部内容，希望文章能够帮你解决java-在将可变引用设置为引用新创建的对象之后,线程是否仍会感知构造函数的影响？所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端