java - JLS中最终字段安全上下文的确切含义是什么

Question

术语 final-field-safe context 在 JLS 的第 17.5.3 段(final 字段的后续修改)中经常使用。虽然，从规范中可以理解(如果我在这里错了，请纠正我)

An implementation may provide a way to execute a block of code
in a final-fieldsafe context.

确切的行为取决于实现，目前还没有明确的术语定义。
我可以假设，如果我们有一个最终字段卡住 F(发生在对象构造结束时或通过反射 API 设置的最终字段)和一个操作 A ，这样happens-before(F, A)，然后 A 在 final-field-safe context 中？

Answer 1

帮助理解什么JLS 17.5.3通过“最终字段安全上下文”表示，请考虑以下代码

public static final AccountType SINGLETON_ACCOUNT_TYPE = new AwesomeAccountType();

在 Java 5 之前，Java 有一个“特性”，即 AwesomeAccountType 的构造及其对 SINGLETON_ACCOUNT_TYPE 的分配的线程安全性被开发人员认为是安全的。不幸的是，规范含糊不清和/或没有说明行为，这导致不同的 JVM 实现具有不同的行为。结果是，在这种情况下，Java 通常不是线程安全和可移植的。

这样做的原因是，构建 AwesomeAccountType 所涉及的操作顺序可能会在运行时重新排序，这样在对象完全构建之前，对对象的引用就可以对另一个线程可见。该行为是不确定的，它总是在单核 CPU 上工作，通常在英特尔 CPU 上工作，但会在内存模型较弱的 CPU(例如 Dec Alpha)上匆忙倒下。

然后，“最终字段安全上下文”是分配给上述最终字段 (SINGLETON_ACCOUNT_TYPE) 所涉及的代码区域，它涵盖了 AwesomeAccountType 的所有构造函数和 JVM 内部用于分配的代码并为对象初始化内存。

Java 内存模型的这些更改是在 JSR133 下进行的，以下常见问题解答对于理解所做更改的上下文非常有用:JSR133 FAQ .