java - JMM 保证关于对象的最终引用和非最终引用

Question

我尝试理解最终字段的语义。

让我们研究代码:

public class App {

    final int[] data;
    static App instance;

    public App() {
        this.data = new int[]{1, 0};
        this.data[1] = 2;
    }


    public static void main(String[] args) {
        new Thread(new Runnable() {
            public void run() {
                instance = new App();
            }
        }).start();

        while (instance == null) {/*NOP*/}
        System.out.println(Arrays.toString(instance.data));
    }
}

我有一些问题:

1. jmm 是否保证if 应用程序终止然后输出 [1,2]？
2. jmm 是否保证循环终止后 instance.data 不为空？

P.S.我不知道如何使标题正确，请随意编辑。

补充

如果我们替换:是否有能见度差异:

public App() {
    this.data = new int[]{1, 0};
    this.data[1] = 2;
}

与

public App() {
    int [] data = new int[]{1, 0};
    data[1] = 2;
    this.data = data;    
}

我还想知道如果在我的示例中将 final 替换为 volatile，wjat 会是什么。

因此我想得到关于 4 个新案例的解释

Answer 1

是的，有一些收获。您正在循环后重新读取 instance 变量，并且由于两次读取都是活泼的，退出循环并不能保证循环后的读取读取非 null 引用.

由于这个问题不是问题的主题，假设有以下变化:

App instance;
while((instance=App.instance) == null) {/*NOP*/}
System.out.println(Arrays.toString(instance.data));

然后，如果应用程序终止，它将输出[1,2]。关键是 final 字段语义适用于整个构造函数，数组引用写入字段的确切时间无关紧要。这也意味着在构造函数中，重新排序是可能的，因此如果 this 引用在构造函数完成之前转义，则所有保证都是无效的，无论 this 是否在之前转义或者在程序顺序写入之后。由于在您的代码中，this 在构造函数完成之前不会转义，因此保证适用。

引用JLS §17.5., final Field Semantics :

An object is considered to be completely initialized when its constructor finishes. A thread that can only see a reference to an object after that object has been completely initialized is guaranteed to see the correctly initialized values for that object's final fields.

请注意，它指的是完全初始化 状态，而不是写入特定的final 字段。这也将在下一节 §17.5.1 中解决。 :

Let o be an object, and c be a constructor for o in which a final field f is written. A freeze action on final field f of o takes place when c exits, either normally or abruptly.

---

如果将变量更改为 volatile，则几乎没有任何保证。 volatile 字段在对该变量的写入和后续读取之间建立了一种发生在之间的关系，但经常被忽视的关键点是“后续”。如果 App 实例发布不当，就像在您的示例中一样，则不能保证主线程对 instance.data 的读取将是后续的。如果它读取一个 null 引用，这现在是可能的，那么您就知道它不是后续的。如果它读取一个非 null 引用，您知道它是在字段写入之后的，这意味着您可以保证在第一个槽中读取 1，但是第二次你可能会读到 0 或 2。

如果你想从障碍和重新排序的角度讨论这个问题，volatile 写入 data 保证所有先前的写入都已提交，其中包括 1 到第一个数组槽，但它不保证后续的非 volatile 写入不会更早提交。因此，App 引用的不正确发布仍有可能在 volatile 写入之前执行(尽管这种情况很少发生)。

如果将写入移动到构造函数的末尾，一旦看到非null 数组引用，所有之前的写入都是可见的。对于 final 字段，不需要进一步讨论，如上所述，write 在构造函数中的实际位置无论如何都是无关紧要的。对于 volatile 情况，如上所述，您不能保证读取非 null 引用，但是当您读取它时，所有先前的写入都会被提交。了解表达式 new int[]{1, 0}; 被编译为等价于 hiddenVariable=new int[2]; 可能会有所帮助。隐藏变量[0]=1； hiddenVariable[1]=0; 无论如何。在其构造之后但在对字段的数组引用的 volatile 写入之前放置另一个数组写入不会改变语义。