java - 构造函数应该有 StoreStore 屏障吗？

Question

是否应该将 store-store-barriers 放入构造函数中？

这是一个例子。最初假设 global_f = f = r = 0。一个线程A创建一个对象，赋值给一个字段，赋值给一个全局变量:

class Foo {
    int x;
    void Foo(int x) {
         this.x = x;
    }
}

f = new Foo(42);
global_f = f;

另一个线程B从全局变量中获取引用，然后读取该字段。

r = global_f.x;

假设线程 B 从线程 B 读取对象引用的执行，它可以从 X 读取什么值到 r？是否始终为 42？

我对 C++ 和 Java 的行为很感兴趣。根据我对内存模型的理解，r 不能保证为 42。

为了确保对象的字段被正确初始化，我们通常可以将 store-store-barriers 放在构造函数的末尾。这似乎是 C++ 和 Java 中的一个陷阱。至少对于 Java，对于 final 字段，一切都很好，不是吗？这在实践中并不那么重要，因为至少在 x86 和 AMD64 上，store-store-barrier 是一个 NOP。但是，在 ARM 或 POWER 等其他架构上则不然。

Answer 1

在 Java 中，不能保证 r 将是 42，除非您将 x 字段声明为 final.

---

To ensure that the fields of an object are properly initialized, we could put store-store-barriers at the end of constructors in general. This seems to a pitfall in both C++ and Java.

这是评论而不是问题。然而，相反的论点是，在所有构造函数的末尾放置一个隐式屏障会在各种情况下导致不必要的性能损失；例如

• 对于单线程代码，
• 对于未发布f的多线程代码
• 对于多线程代码，其中对 x 的访问由同步方法保护。

Java 和 C++ 的内存模型是简单性和性能考虑之间的折衷。如果您过于追求简单性(即通过设计排除所谓的陷阱)，多线程代码将不会为您提供人们想要/需要的那种加速。