x86 架构上的 Java、volatile 和内存屏障

Question

这更像是一个理论问题。我不确定所有概念、编译器行为等是否都是最新的并且仍在使用，但我想确认我是否正确理解了我正在尝试学习的一些概念。

语言是Java。

据我目前的了解，在 X86 架构上，StoreLoad 屏障(尽管用于实现它们的确切 CPU 指令)放在 volatile 写入之后，以使它们对其他线程中的后续 volatile 读取可见(因为 x86 不'保证较新的读取总是看到较旧的写入)(引用 http://shipilev.net/blog/2014/on-the-fence-with-dependencies/)

现在从这里 ( http://jpbempel.blogspot.it/2013/05/volatile-and-memory-barriers.html ) 我看到了:

public class TestJIT
{
    private volatile static int field1;
    private static int field2;
    private static int field3;
    private static int field4;
    private static int field5;
    private volatile static int field6;

    private static void assign(int i)
    {
        field1 = i << 1; // volatile
        field2 = i << 2;
        field3 = i << 3;
        field4 = i << 4;
        field5 = i << 5;
        field6 = i << 6; // volatile.
    }

    public static void main(String[] args) throws Exception
    {
        for (int i = 0; i < 10000; i++)
        {
            assign(i);
        }
        Thread.sleep(1000);
    }
}

生成的程序集仅在 field6 赋值后才具有 StoreLoad，而在 field1 赋值后则不存在，但后者也是易变的。

我的问题:

1) 到目前为止我写的内容有意义吗？还是我完全误解了什么？

2) 为什么编译器在 field1 volatile 赋值后省略 StoreLoad？这是优化吗？但它有一些缺点吗？例如，另一个线程在 field1 赋值后启动，可能仍然读取 field1 的旧值，即使它实际上已被更改？

Answer 1

1) Does what I have written so far make sense? Or am I totally misinterpreting something?

我认为你做对了一切。

2) Why is the compiler omitting a StoreLoad after field1 volatile assignment? Is this an optimization? But has it some drawbacks?

是的，这是一种优化，但要做到这一点非常棘手。

Doug Lea 的 JMM Cookbook实际上显示了在两个连续的 volatile 存储的情况下推荐的障碍的示例，并且 在每个存储之后都有 StoreLoad 有一个StoreStore(x86 无操作)在两个商店之间，StoreLoad 仅在第二个商店之后。然而，Cookbook 指出相关分析可能相当复杂。

编译器应该能够证明 volatile 读取不会出现在写入 field1 和写入 field6 之间的同步顺序中>。我不确定如果对 TestJIT 进行了轻微更改，以便在另一个线程中同时执行相当数量的 volatile 负载，那是否可行(通过当前的 HotSpot JIT)时间。

For example, another thread kicking in after field1 assignment, might still read an old value for field1 even if it has been actually changed?

如果 volatile 加载在同步顺序中遵循 volatile 存储，则不应允许发生这种情况。因此，如上所述，我认为 JIT 逃脱了它，因为它没有看到任何正在完成的 volatile 加载。

更新

更改了 JMM Cookbook 示例的详细信息，因为 kRs 指出我将 StoreStore 误认为是 StoreLoad。答案的本质没有改变。