java - JSR-133 说明书如何强制执行 Java 内存模型做出的所有保证

Question

我的理解是 JSR-133 cookbook是关于如何使用一系列内存屏障(或至少是可见性保证)实现 Java 内存模型的引用指南。

根据对不同类型障碍的描述，这也是我的理解，StoreLoad 是唯一保证所有 CPU 缓冲区都刷新到缓存的障碍，因此确保新鲜读取(通过避免存储转发)并保证观察由于缓存一致性的最新值。

我正在查看 volatile /常规存储/加载的不同程序顺序交错所需的特定障碍表，以及需要哪些内存障碍。

根据我的直觉，这张表似乎不完整。例如，Java 内存模型保证监视器的获取操作对在另一个线程中释放之前执行的所有操作的可见性，即使正在更新的值是非 volatile 的。在上面链接的表格中，似乎唯一刷新 CPU 缓冲区和传播更改/允许观察新更改的操作是 Volatile Store 或 MonitorExit，然后是 Volatile Load 或 MonitorEnter。在我上面的示例中，当这些操作(根据表)仅使用 LoadStore 和 StoreStore 时，我看不出障碍如何保证可见性，根据我的理解，它们仅与线程中的重新排序有关，无法强制执行之前发生的事情保证(跨线程)。

我的理解哪里出了问题？或者此实现是否只强制执行之前发生的事情，而不是同步保证或获取/释放监视器的额外操作。

谢谢

Answer 1

StoreLoad is the only one that guarantees all CPU buffers are flushed to cache and therefore ensure fresh reads (by avoiding store forwarding) and guarantees the observation of the latest value due to cache coherency.

这对于 x86 体系结构可能是正确的，但您不应该考虑那种抽象级别。高速缓存一致性对于要执行的处理器来说可能代价高昂。

以移动设备为例，一个重要的目标是减少电池使用程序消耗的电量。在这种情况下，它们可能不会参与缓存一致性和 StoreLoad失去了这个特征。

I don't see how the barriers could guarantee visibility in my above example, when those operations (according to the table) only use LoadStore and StoreStore which from my understanding are only concerned with re-ordering in a thread and cannot enforce the happens before guarantee (across threads that is).

让我们只考虑一个 volatile 字段。不稳定的加载和存储看起来如何？嗯，Aleksey Shipilëv has a great write up on this ，但我会拿一 block 。

一个 volatile 存储然后随后的加载看起来像:

<other ops>
[StoreStore]
[LoadStore]
x = 1; // volatile store
[StoreLoad] // Case (a): Guard after volatile stores

...

[StoreLoad] // Case (b): Guard before volatile loads
int t = x; // volatile load
[LoadLoad]
[LoadStore]
<other ops>

所以，<other ops>可以是非 volatile 写入，但如您所见，这些写入在 volatile 存储之前提交到内存。然后当我们准备好阅读 LoadLoad 时LoadStore将强制等待直到 volatile store成功。

最后，StoreLoad before 和 after 确保易变的加载和存储不会被重新排序，如果紧接在彼此之前。