java - 在实践中，什么情况下操作系统/CPU 不会产生非 volatile Java 变量的最终一致性？

Question

我们试图在我们的云服务产品中尽可能避免原子操作和读取内存。因此，我们在实践中进行了激烈的辩论eventual consistency当 Java 在现代处理器上运行时，静态变量的(也称为最终可见性)。

众所周知，Java 语言规范不保证对静态范围变量的多线程更改的跨线程更新可见性 或最终一致性>除非它们被定义为 volatile 。基本上，不使用 volatile 关键字意味着无法保证一致性。使用 volatile 关键字可确保指令顺序以及跨线程的变量最新值的即时可见性/一致性。

• “对 volatile 变量 v 的写入(第 8.3.1.4 节)与任何线程对 v 的所有后续读取进行同步(其中“后续”是根据同步顺序定义的)。” Section 14.4.4 Java 语言规范 (JLS)
• “字段可以被声明为 volatile 的，在这种情况下，Java 内存模型确保所有线程看到变量的一致值(第 17.4 节)。” Section 8.3.14 Java 语言规范 (JLS)
• https://dzone.com/articles/java-multi-threading-volatile-variables-happens-be-1
• https://wiki.sei.cmu.edu/confluence/display/java/Concurrency%2C+Visibility%2C+and+Memory

然而，实际上，当现代商用 CPU 写入静态变量时，它们确实会将某种形式的内存更新提示排队到缓存 Controller ，然后最终强制内存位置更新跨核心缓存。而且，除非正在读取的内存位置处于特定线程上的紧密循环中，否则企业工作负载上的正常 CPU 使用率似乎最终会生成所需的缓存提示，以在线程之间为非 volatile 数据生成一致性。实践中的静态变量(除非编译器优化边缘情况导致奇怪的重新排序问题)。

举个例子，如果我们有多个 Java 线程读取一个不带 volatile 限定符的静态共享变量，其中一个线程对该变量生成间隔非常大的写入(每隔几个小时一次)，那么 Java 测试代码一致地快速显示线程无论没有 volatile 限定符，都会拾取值变化。这可能是由于底层操作系统/CPU 架构使每核缓存无效。

所以我们的问题是:除了编译器重新排序问题(例如循环中的终止条件)之外，任何人都可以解释一下这个操作系统/CPU 不保证但在实践中最终一致性不会发生吗？

例如，是否存在实际的 Intel/AMD/ARM 架构或 Linux 风格，这种不保证但在实践中不会发生最终一致性？我们的测试表明，即使没有 volatile 关键字，它最终也总是能在 MacOS Linux 上产生一致性。

Answer 1

现代CPU具有一致的内存模型，因此如果变量写入内存，它将是可见的(将来可以随时更改，所以不要依赖它)。

在实践中会让你失败的是 JIT，它可以决定根本不将变量存储在内存中。