Java使用非易失性重排序易失性写入

Question

我对下面的代码段有一个问题。结果可能有一个结果[0，1，0]（这是用JCStress执行的测试）。那么这是怎么发生的呢？我认为数据写入（data=1）应该在Actor2（guard2=1）中写入到guard2之前执行。我说得对吗？我问，因为很多时候我读到挥发物周围的说明没有重新排序。此外，根据这一点：http://tutorials.jenkov.com/java-concurrency/volatile.html其内容如下：

JVM无法对易失性变量的读写指令进行重新排序（只要JVM检测到重新排序后的程序行为没有变化，JVM可能会出于性能原因对指令进行重新排序）。前后的指令可以重新排序，但易失性读或写不能与这些指令混合。在易变变量读或写之后的任何指令都保证在读或写之后发生。

所以如果我们不能重新排序

  public class DoubleVolatileTest {

      volatile int guard1 = 0;
      int data = 0;
      volatile int guard2 = 0;

      @Actor
      public void actor1() {
          guard2 = 1;
          data = 1;
          guard1 = 1;
      }

      @Actor
      public void actor2(III_Result r) {
          r.r1 = guard1;
          r.r2 = data;
          r.r3 = guard2;
      }

  }

提前感谢！

Answer 1

首先，这：

JVM无法对易失性变量的读写指令进行重新排序。。。

意味着挥发物本身不能重新排序（即挥发物与挥发物）；但要注意的是

只要JVM在重新排序过程中没有检测到程序行为的变化，JVM就可以出于性能原因重新排序指令。

一般来说，关于JVM重新排序（可能或不可能）的推理是不正确的（我已经读到关于挥发物的指令没有重新排序…）。重新订购/屏障/等不属于JLS的一部分；相反，它是在规则之前发生的，这是您唯一应该关心的事情。

您的示例，确实可以简化为评论中所说：

@Outcome(id = "0, 0", expect = Expect.ACCEPTABLE, desc = "don't care about this one")
@Outcome(id = "1, 0", expect = Expect.ACCEPTABLE_INTERESTING, desc = "the one we care about")
@Outcome(id = "1, 1", expect = Expect.ACCEPTABLE, desc = "don't care about this one")
@Outcome(id = "0, 1", expect = Expect.ACCEPTABLE, desc = "don't care about this one")
@JCStressTest
@State
public class VolatileTest {


    private volatile int guard = 0;
    private int x = 0;


    @Actor
    void writeActor() {
        guard = 1; // volatile store

        // your reasoning is that these two operations should be re-ordered
        // unfortunately, this is not correct.

        x = 1; // plain store
    }

    @Actor
    void readActor(II_Result r) {

        r.r1 = x; // plain store
        r.r2 = guard; // plain store

    }
}

运行此操作将导致1，0，这意味着x=1确实是用guard=1重新订购的；事实上，可能会发生更多其他事情（但为了简单起见，我们称之为重新排序，尽管这不是您可以观察到的唯一原因）。

用JLS术语来说：您之前没有确定这些操作之间发生过任何事情（例如典型的易失性存储/易失性加载）-因此这些操作可以自由浮动。这可能是答案的结尾，差不多。更广泛的解释是易失性（因为您使用了它），据说：

对易失性字段的写入发生在同一字段的每次后续读取之前。

您没有对易失性保护进行任何读取，因此无法保证任何事情。另一种解释它的方法是这篇优秀的文章，甚至是这篇文章。但是即使您确实阅读了Guard，仍然无法保证重新排序，因为您的代码设置方式。

只有当存在成对的用法时，volatile才能正常工作，即线程1写入volatile字段-Thread2观察写入。在这种情况下，在写入程序顺序之前所做的一切都将被Thread2看到（显然是在看到写入值之后）。或在代码中：

 public class VolatileTest {

    private volatile int guard = 0;
    private int x = 0;


    @Actor
    void writeActor() {

        // store comes "before" the store to volatile
        // as opposed to the previous example
        x = 1; // plain store
        guard = 1; // volatile store
    }

    @Actor
    void readActor(II_Result r) {

        r.r1 = guard; // plain store
        r.r2 = x; // plain store

    }
}

现在，JLS向您保证，如果您看到防护罩为1，您也会看到x为1（这次不能在下方重新订购）。因此，1，0现在是非法的，因此从未在输出中看到过。