非易失性共享变量损坏 17.7双原子和长原子的非原子处理 17.6单词撕裂

如何解决非易失性共享变量损坏 17.7双原子和长原子的非原子处理 17.6单词撕裂

我知道volatile的可见性保证。我不问这个。

我刚刚审核了以下代码：

class MyController {
  private int someId = -1; // uninitialized state

  public void handleRequest() {
    // gets called from multiple threads,incoming HTTP requests
    var id = getSomeId();
    // do something involving the id
  }

  private int getSomeId() {
    if (this.someId == -1) {
      this.someId = fetchIdFromSomewhereElse();
    }

    return this.someId;
  }

  private int fetchIdFromSomwhereElse()
  {
    // expensive but idempotent,always returns a positive value
  }
}

某同事评论说，我必须使MyController#someId变量易变，否则我将冒着读取损坏值的风险。

我假设getSomeId()不可能返回负值（因为fetchIdFromSomewhereElse永远不会返回负值）。请纠正我，如果我在这里错了。

问题：在上面的代码中，getSomeId()是否有可能返回从未写入someId实例变量的值？

答案是否随数据类型和体系结构而改变？ int / long，32bit / 64bit？ 我认为

• 变量将始终在单词边界上对齐
• 因此，cpu将始终以一次原子操作将整个变量写入内存
• 因此，在32位计算机上使用long可能会在这里引起麻烦。

我确实意识到fetchIdFromSomewhereElse可能会被调用多次，而不仅仅是一次。

我无法给出一个例子，说明在现代64位处理器上int或long损坏。

解决方法

否

不带int。来自the Version 8 JLS,17.7.：

17.7。双原子和长原子的非原子处理

就Java编程语言内存模型而言，对非易失性long或double值的单次写入被视为两次单独的写入：一次写入每个32位的一半。这可能导致线程在一次写入中看到64位值的前32位，而在另一次写入中看到后32位。

[...]

对我来说，这清楚地表明，任何JVM实现都必须能够自动读写32位。结合17.6。 ：

17.6。单词撕裂

Java虚拟机实现的一个考虑因素是，每个字段和数组元素都被认为是独立的。 对一个字段或元素的更新不得与任何其他字段或元素的读取或更新交互。 [...]

很明显，对int字段的写入是原子的。

---

但是它也得出结论，当跨线程使用并且没有long时，共享的非易失性double和synchronized的行为可能会非常不理想。我必须同意我的同事的看法，除非对性能有明显的影响是不能容忍的，只是标记每个共享变量volatile是个好主意。

也是从17.7开始：

[...]

对引用的写入和读取始终是原子的，无论它们是实现为32位还是64位值。

[...]

这意味着JVM必须无论如何都要对任何非基本类型强制使用易失性语义，这会使参考字段上的volatile最糟。

---

感谢@markspace给我word tearing一词给Google！ ：）