Java 最终字段 : is "taint" behavior possible with the current JLS

Question

我目前正在尝试了解 this JLS section on final fields .
为了更好地理解 JLS 中的文字，我也在阅读 The Java Memory Model作者:Jeremy Manson(JMM 的创造者之一)。
该论文包含让我感兴趣的示例:如果一个对象 o最终字段对另一个线程可见 t两次:

第一个“不正确”之前 o的构造函数完成

下一个“正确”之后 o的构造函数完成

然后 t可以看到半成品 o即使仅通过“正确”发布的路径访问它。
这是论文中的部分:

Figure 7.3: Example of Simple Final Semantics

f1 is a final field; its default value is 0

Thread 1	Thread 2	Thread 3
o.f1 = 42; p = o; freeze o.f1; q = o;	r1 = p; i = r1.f1; r2 = q; if (r2 == r1) k = r2.f1;	r3 = q; j = r3.f1;

We assume r1, r2 and r3 do not see the value null.i and k can be 0 or 42, and j must be 42.

---

Consider Figure 7.3. We will not start out with the complications of multiple writes to final fields; a freeze, for the moment, is simply what happens at the end of a constructor. Although r1, r2 and r3 can see the value null, we will not concern ourselves with that; that just leads to a null pointer exception.

...

What about the read of q.f1 in Thread 2? Is that guaranteed to see the correct value for the final field? A compiler could determine that p and q point to the same object, and therefore reuse the same value for both p.f1 and q.f1 for that thread. We want to allow the compiler to remove redundant reads of final fields wherever possible, so we allow k to see the value 0.

One way to conceptualize this is by thinking of an object being “tainted’ for a thread if that thread reads an incorrectly published reference to the object. If an object is tainted for a thread, the thread is never guaranteed to see the object’s correctly constructed final fields. More generally, if a thread t reads an incorrectly published reference to an object o, thread t forever sees a tainted version of o without any guarantees of seeing the correct value for the final fields of o.

我试图在 the current JLS 中找到任何明确允许或禁止此类行为的内容，但我发现的是:

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.

当前的 JLS 允许这种行为吗？

Answer 1

是 ，这是允许的。
主要暴露在JMM已经引用的部分:

Assuming the object is constructed "correctly", once an object isconstructed, the values assigned to the final fields in theconstructor will be visible to all other threads withoutsynchronization.

What does it mean for an object to be properly constructed? It simplymeans that no reference to the object being constructed is allowed to"escape" during construction.

In other words, do not place a reference to the objectbeing constructed anywhere where another thread might be able to seeit; do not assign it to a static field, do not register it as alistener with any other object, and so on. These tasks should be doneafter the constructor completes, not in the constructor***

所以是的，在允许的范围内，这是可能的。最后一段充满了关于如何不做的事情的建议；每当有人说避免做 X ，则隐含了 X 可以做到。

如果...怎么办 reflection其他答案正确指出了其他线程正确看到final字段的要求，例如构造函数末尾的卡住，链等。这些答案提供了对主要问题的更深入理解，应首先阅读。本节重点介绍这些规则的可能异常(exception)情况。
最重复的规则/短语可能是这里的这个，复制自 尤金 的答案(顺便说一句，不应该有任何反对票):

An object is considered to be completely initialized when its constructor finishes. A thread that can only see a reference to anobject after that object has been completely initialized isguaranteed to see the correctly [assigned/loaded/set] values for that object'sfinal fields.

请注意，我将术语“初始化”更改为分配、加载或设置的等效术语。这是故意的，因为术语可能会误导我的观点。
另一个正确的陈述来自 chrylis -谨慎乐观- :

The "final freeze" happens at the end of the constructor, and fromthat point on all reads are guaranteed to be accurate.

JLS 17.5 final Field Semantics 指出:

A thread that can only see a reference to an object after thatobject has been completely initialized is guaranteed to see thecorrectly initialized values for that object's final fields.

但是，您认为反射对此有什么看法吗？不，当然不是。它甚至没有读那段。
final的后续修改字段
这些陈述不仅是正确的，而且还得到了 JLS 的支持。 .我不打算反驳他们，只是添加一些关于该法律异常(exception)的一些额外信息: 反射 .该机制除其他外，可以在初始化后更改最终字段的值。
卡住 final字段出现在构造函数的末尾，其中 final字段设置，这是完全正确的。但是还有一个卡住操作的触发器没有被考虑到: 卡住 的 final field 也会通过反射( JLS 17.5.3 )初始化/修改一个字段:

Freezes of a final field occur both at the end of the constructor inwhich the final field is set, and immediately after each modificationof a final field via reflection.

final 上的反射操作字段“打破”规则:在构造函数正确完成后，所有读取 final字段是 仍然不能保证准确 .我试着解释一下。
让我们想象一下所有正确的流程都得到了遵守，构造函数已经初始化，所有 final线程可以正确看到实例中的字段。现在是时候通过反射对这些字段进行一些更改(想象一下这是需要的，即使不寻常，我知道..)。
遵循前面的规则，所有线程都等待，直到所有字段都已更新:就像通常的构造函数场景一样，只有在卡住和反射操作正确完成后才能访问这些字段。 这是违法的地方 :

If a final field is initialized to a constant expression (§15.28) inthe field declaration, changes to the final field may not be observed,since uses of that final field are replaced at compile time with thevalue of the constant expression.

这说明:即使遵循所有规则，您的代码也不会正确读取 final字段的赋值，如果该变量是 原始或字符串 你将它初始化为 字段声明中的常量表达式 .为什么？因为那个变量只是一个 硬编码值 对于您的编译器，即使您的代码在运行时执行中正确更新了值，它也不会再次检查该字段或其更改。
那么，让我们测试一下:

 public class FinalGuarantee 
 {          
      private final int  i = 5;  //initialized as constant expression
      private final long l;

      public FinalGuarantee() 
      {
         l = 1L;
      }
        
      public static void touch(FinalGuarantee f) throws Exception
      {
         Class<FinalGuarantee> rfkClass = FinalGuarantee.class;
         Field field = rfkClass.getDeclaredField("i");
         field.setAccessible(true);
         field.set(f,555);                      //set i to 555
         field = rfkClass.getDeclaredField("l");
         field.setAccessible(true);
         field.set(f,111L);                     //set l to 111                 
      }
      
      public static void main(String[] args) throws Exception 
      {
         FinalGuarantee f = new FinalGuarantee();
         System.out.println(f.i);
         System.out.println(f.l);
         touch(f);
         System.out.println("-");
         System.out.println(f.i);
         System.out.println(f.l);
      }    
 }

输出 :

 5
 1
 -
 5   
 111

最后的 int i在运行时正确更新，要检查它，您可以调试和检查对象的字段值:

两者 i和 l已正确更新。那么 i 发生了什么| ，为什么还是显示5？因为如 JLS 上所述，领域 i在编译时直接替换为 常量表达式的值 ，在本例中为 5 .
每次读取最后一个字段 i然后将是 不正确 ，即使遵循了之前的所有规则。编译器永远不会再次检查该字段:当您编码时 f.i ，它不会访问任何实例的任何变量。它只会返回 5: 最后一个字段只是在编译时硬编码 如果在运行时对其进行了更新，则任何线程将永远不会再次正确地看到它。这违反了法律。
作为在运行时正确更新字段的证明:

两者 555 和 111L 被插入堆栈，字段获得新分配的值。但是在操纵它们时会发生什么，例如打印它们的值？

l未初始化为常量表达式，也未在字段声明中初始化。因此，不受 17.5.3 的影响的规则。该字段已正确更新并从外线程读取。

i但是，在字段声明中被初始化为常量表达式。初始卡住后，没有更多 f.i对于编译器，将永远不会再次访问该字段。即使变量在示例中正确更新为 555，每次从字段读取的尝试都已被硬编码常量 替换。 5 ;无论对变量进行任何进一步的更改/更新，它都将始终返回 5。

16: before the update
42: after the update

没有现场访问权限，但只是“是的，肯定是 5，返回它”。这意味着 final领域 并不总是保证可以正确看到 来自外部线程，即使遵循了所有协议(protocol)。
这会影响原语和字符串。我知道这是一种不寻常的情况，但它仍然是可能的。

其他一些有问题的场景(一些也与评论中引用的同步问题有关):
1- 如果不正确 synchronized使用反射操作，线程可能会落入 竞争条件 在以下场景中:

    final boolean flag;  // false in constructor
    final int x;         // 1 in constructor 

让我们假设反射操作将按以下顺序:

  1- Set flag to true
  2- Set x to 100.

阅读器线程代码的简化:

    while (!instance.flag)  //flag changes to true
       Thread.sleep(1);
    System.out.println(instance.x); // 1 or 100 ?

作为一种可能的情况，反射操作没有足够的时间来更新 x ，所以 final int x字段可能会或不会被正确读取。
2- 一个线程可能会落入 僵局在以下场景中:

    final boolean flag;  // false in constructor

让我们假设反射操作将:

  1- Set flag to true

阅读器线程代码的简化:

    while (!instance.flag) { /*deadlocked here*/ } 

    /*flag changes to true, but the thread started to check too early.
     Compiler optimization could assume flag won't ever change
     so this thread won't ever see the updated value. */

我知道这不是最终字段的特定问题，只是作为这些类型变量的错误读取流的可能场景添加。最后两个场景只是不正确实现的结果，但想指出它们。