java - Java 中 Final 字段和 volatile 字段之间内存模型语义的差异

Question

摘自 Java 并发实践:

When a field is declared volatile, the compiler and runtime are put on notice that this variable is shared and that operations on it should not be reordered with other memory operations. Volatile variables are not cached in registers or in caches where they are hidden from other processors, so a read of a volatile variable always returns the most recent write by any thread.(p25)

并且，

Final fields can't be modified(although the objects they refer to can be modified if they are mutable), but they also have special semantics under the Java Memory Model. It is the use of final fields that makes possible the guarantee of initialization safety(see Section 3.5.2) that lets immutable objects be freely accessed and shared without synchronization.(p32)

背诵不安全的出版物:

public class Holder {
      private int n;
      public Holder(int n) { this.n = n; }
      public void assertSanity() {
         if (n != n) // might be true for other threads.
     }
}

令人惊讶的是，n 的值可能会被其他线程视为过时。但 final 修饰符就可以解决问题。类似于 volatile ，不是吗？ final 字段本质上是 volatile 吗？ (一个可能的解释为什么final volatile是不允许的)

Answer 1

不，final 字段本质上不是 volatile 。

如果是的话，那就会不必要地昂贵，因为在大多数情况下，您需要在 volatile 写入之后放置一个StoreLoad屏障。

对于 final 字段可以避免这种情况，因为您有一个额外的约束可以帮助您 - 您知道 final 字段必须在相应的类创建时初始化或者实例对象已完全初始化。

该规范可能有点难以阅读(看看 JLS 的 section 17.5)，但请记住，就像臭名昭著的 JMM 因果关系部分一样，要点是正式描述直观行为对于大多数人来说。

至于实现，通常需要两件事:

1. 确保 final 字段存储(包括字段是引用时链下的存储)不能与构造函数外部的存储重新排序。如果底层硬件架构具有强大的内存模型(如 x86)，即使您内联构造函数，这通常也是无操作。

2. 确保给定线程中的第一个 final 字段加载不能与该字段所属的相应引用的同一线程中的第一个加载重新排序。这几乎总是无操作，因为所有编译器和大多数硬件架构都尊重加载依赖性。

最后，大多数架构上便宜得多的 LoadStore 和 StoreStore 屏障应该足以实现 final 字段。

===

您可以阅读有关如何在幕后实现 final 字段的更多信息:

• Doug Lea 的 JMM Cookbook (请参阅最终字段部分)
• Alexey Shipilev 太棒了 All Fields Are Final博客文章。

===

附注即使存在 final 字段，不安全的发布也是危险的。请参阅here一些注意事项。