相对于其他领域的易变语义

Question

假设我有以下代码

private volatile Service service;

public void setService(Service service) {
  this.service = service;
}

public void doWork() {
  service.doWork();
}

Modified 字段标记为易失性，并且其值不依赖于先前的状态。所以，这是正确的多线程代码（暂时不用担心 Service 实现）。

据我所知，从内存可见性的角度来看，读取 volatile 变量就像进入一把锁。这是因为普通变量的读取不能与易失性变量的读取重新排序。

这是否意味着以下代码是正确的？

private volatile boolean serviceReady = false;
private Service service;

public void setService(Service service) {
  this.service = service;
  this.serviceReady = true;
}

public void doWork() {
  if ( serviceReady ) {
    service.doWork();
  }
}

Answer 1

是的，从 Java 1.5 开始，这段代码是“正确的”。

无论有或没有易失性（写入对象引用都是原子的），原子性都不是问题，因此您可以以任何方式将其从关注列表中划掉——唯一悬而未决的问题是更改的可见性和顺序的“正确性”。

对易失性变量的任何写入都会设置“发生之前”关系（新 Java 内存模型的关键概念，如 JSR-133) 以及同一变量的任何后续读取。这意味着读取线程必须能够看到写入线程可见的所有内容：也就是说，它必须看到写入时至少具有“当前”值的所有变量。

我们可以通过查看 第 17.4 节来详细解释这一点Java 语言规范 .5，具体如下要点：

1. “如果 x 和 y 是同一个线程的操作，并且 x 按程序顺序出现在 y 之前，则 hb(x, y)”（即同一线程上的操作不能以与程序顺序不一致的方式重新排序）
2. “对易失性字段（§8.3.1.4）的写入发生在该字段的每次后续读取之前。” （这是澄清文本，解释易失性字段的先写后读是一个同步点）
3. “如果 hb(x, y) 和 hb(y, z)，则 hb(x, z)”（发生的传递性-before)

因此，在您的示例中：

• 写入“service”(a) 发生在写入“serviceReady”(b) 之前，由于规则 1，
• 写入“serviceReady”(b) 发生在读取相同内容之前(c)，由于规则 2，
• 因此，(a) 发生在 (c)（第三条规则）之前，

这意味着在本例中，一旦 serviceReady 为 true，就可以保证“服务”设置正确。

您可以看到一些使用几乎完全相同相同示例的优秀文章，其中一个位于 IBM DeveloperWorks -- 请参阅“Volatile 的新保证”：

写入 V 时 A 可见的值现在保证对 B 可见。

，并且位于 JSR-133 FAQ，由该 JSR 的作者编写：

因此，如果读者看到 v 的值为 true，也可以保证看到之前发生的对 42 的写入。在旧的内存模型下，情况并非如此。如果 v 不是易失性的，那么编译器可以重新排序 writer 中的写入，并且 reader 对 x 的读取可能会看到 0。

Answer 2

AFAIK 这是正确的代码。

@CPerkins：仅使 setService 方法同步将不起作用，因为您还必须在读取时同步。

然而，在这种情况下，一个变量就足够了。为什么需要额外的布尔字段。
例如

private volatile Service service;

public void setService(Service service) {
  this.service = service;
}

public void doWork() {
  if ( service != null ) {
    service.doWork();
  }
}

，假设没有人将 setService 调用为 null。所以你可能应该进行空检查：

private volatile Service service;

public void setService(Service service) {
  if (service == null) throw NullPointerException();
  this.service = service;
}

public void doWork() {
  if ( service != null ) {
    service.doWork();
  }
}

Answer 3

您对易失性的影响是正确的，所以这应该是正确的，但我对您的设计感到困惑。我不明白为什么你不只是同步 setService - 它可能不会经常被调用。如果它被多次调用，“if (serviceReady)”部分就没有意义了，因为它仍然是真的，但没关系，因为如果我理解正确的话，替换是原子的。

我猜 service.doWork() 是线程安全的，是吗？

Answer 4

从理论上讲，它永远不会起作用。您希望确保两个变量的内存一致性，并且希望依赖第一个变量的易失性读取。易失性只读保证读取线程看到变量的最新值。所以它绝对不如进入锁定（同步）部分那么强。

实际上，它可能会起作用，具体取决于您所使用的 JVM 的 volatile 实现。如果通过刷新所有 CPU 缓存来实现易失性读取，那么它应该可以工作。但我准备打赌这不会发生。 我可以在多核 x86 CPU 上强制实现缓存一致性吗？< /a> 是关于这个主题的好读物。

我想说，只需为两个变量设置一个公共锁（ java.util.concurrent.Lock 或 synchronized ）即可完成。

---

Java 语言规范，第三版，有这个说说易失性：

8.3.1.4 易失性字段

字段可以声明为易失性的，在这种情况下，Java 内存模型（第 17 节）确保所有线程看到变量的一致值。

和

17.4.4 同步顺序

• 对 易失性变量 (§8.3.1.4) v 的写入与任何线程对 v 的所有后续读取进行同步（其中后续是根据同步顺序定义的）。
• 对易失性字段 (§8.3.1.4) 的写入发生在该字段的每次后续读取之前。

它没有提及其他变量的可见性影响。