StoreStore屏障如何映射到x86下的指令？

Question

JSR133 cookbook 说：

StoreStore Barriers 序列：Store1;商店商店； Store2 确保 Store1 的数据对其他处理器可见（即刷新到 内存）之前与 Store2 关联的数据和所有后续 存储说明。一般来说，需要 StoreStore 屏障 不保证刷新的严格顺序的处理器 从写缓冲区和/或缓存到其他处理器或主内存。

而且，从说明书中我们知道，对于同步块，Java 编译器会插入一些障碍来防止可能的重新排序：

MonitorEnter
[LoadLoad] <==inserted barrier
[LoadStore]<==inserted barrier

...
[LoadStore]<==inserted barrier
[StoreStore]<==inserted barrier
MonitorExit

但是，由于 x86 不允许重新排序 Read-Read、Read-Write 和 Write-Write。所以上面所有的barrier都会映射到no-ops。也就是说对于x86处理器来说MonitorEnter和MonitorExit之间不会插入barrier。 我的困惑是，如果我们将 StoreStore 映射到 x86 下的 no-op，那么如何保证可见性？ 更详细地说，x86 确实使用了存储缓冲区，因此为了使在关键部分执行的写入对其他处理器可见，我们需要刷新存储缓冲区，因此需要写入屏障。从可见性的角度来看，a 应该映射到 sfence/mfence/Lock#？但是食谱说，从防止重新排序的角度来看，它应该映射到无操作。 或者，关键是可见性保证是由 MonitorEnter 完成的，并且 MonitorExit 本身？如果是这样的话，我想他们可能会使用所谓的 Read barrier 和 Write barrier 来保证可见性，对吧？

Answer 1

虽然我们可以说内存屏障能够：

1. 保证可见性（通过刷新存储缓冲区和/或应用 使队列无效）
2. 防止重新排序（禁止在加载之间重新排序 和/或存储在内存屏障之前或之后）

但这并不意味着内存屏障应该总是同时做以上两件事，Sun JDK 提供的 Unsafe.doPutOrderedXX 方法就是这样一个例子：

SomeClass temp = new SomeClass(); //S1
unsafe.putOrderedObject(this, valueOffset, null);
Object target = temp; //S2

unsafe.putOrderedObject 这里用作 StoreStore 屏障，因此可以防止 重新排序 S1 和 S2，但不保证 S1 的结果对其他处理器/线程可见（因为没有这样的需要）。

有关不安全和易失性的更多信息：

1. Where is sun.misc.Unsafe documented?

2. http://mishadoff.com/blog/java-magic-part-4-sun-dot-misc-dot-unsafe/

3. http://jpbempel.blogspot.com/2013/05/volatile-and-memory-barriers.html

也就是说，在x86下，为了防止重排序的enter code here，一个StoreStore可以映射到no-op，为了保证可见性，一个StoreStore应该映射到一些指令比如sfence/mfence/锁定#。

另一个例子是final关键字。为了强制执行 final 的语义（观察到的变量的值不能更改），编译器应该在写入 final 字段和从该构造函数返回之间插入一个 StoreStore 屏障。原因这样做是：确保在将构造对象的引用写入引用变量之前，写入 final 字段应该对其他处理器可见。实际上，这意味着对 ordering 的要求而不是可见性，因此在返回之前写入 final 的结果被刷新（刷新存储缓冲区/或缓存）是 必要的从那个构造函数。因此，在 x86 下，JVM 不会为 final 字段插入任何屏障。