【问题讨论】：
JLS，这称为数据竞争。对于数据竞赛来说，一切皆有可能，如果你也能展示你在哪里看到这个例子，那将会很有帮助
CPU 必须确保的唯一事情是在线程中写入 X 不会影响随后分配到其关联的 RX 内存位置。它没有说明它从哪里获得要写入的值。
所以，
在线程 1 中，CPU 说
“哦，我需要读取 X”，因此开始读取操作。
然后它说
“我需要写入 X”，然后 QUEUES 写入队列中的值
线程 2 做同样的事情。
“哦，我需要阅读 X”并开始阅读。
“我需要写入 X”，并将写入排队。
现在我们有两个等待读取和两个排队写入。
如果 CPU 架构表明一个核心上的读取可能会询问另一个核心的写入队列，那么两个核心可以相互读取对方对 X 的未完成写入。因此，您可以将两个值跨核心拉取，最终分配给 RX该线程的内存位置。
当您在指令流中放置内存屏障时，它可以防止这种过度急切的排队写入读取。
【讨论】：
r1 和 r2 不是“内存位置”，或者至少不是任何其他线程引用的内存位置。在 CPU 术语中，它们是寄存器，这就是为什么它们具有像 r1 这样的名称。半相关：preshing.com/20120515/memory-reordering-caught-in-the-act 但这是关于 StoreLoad 重新排序，而不是 LoadStore 重新排序，这是创建所询问的条件所必需的。 （除了这是对同一内存位置的重新排序操作，这是不寻常的。）
8.1 内存模型允许的令人惊讶的行为
图 12 显示了一个小而有趣的示例。行为 r1 == 2 并且 r2 == 1 是合法行为，尽管可能很难看到 它是如何发生的。编译器不会重新排序中的语句 每个线程；此代码决不能导致 r1 == 1 或 r2 == 2。 然而，行为 r1 == 2 和 r2 == 1 可能被 a 早期执行写入的处理器架构，但在某种程度上 它们对在它们之前的本地读取不可见 节目顺序。这种行为虽然令人惊讶，但 Java 允许 记忆模型。为了在内存模型中得到这个结果，我们同时提交 先写后读。
不知何故，CPU 决定在读取 x 之前写入 x。这个例子所说的只是，这是有效的行为，或多或少，这是一个被接受为有效行为的异常。
Intel Itanium CPU 可能会产生这种行为。
所以而不是：
//Thread 1
int x = 0;
int r1 = x;
x = 1;
//Thread 2
int x = 0;
int r2 = x;
x = 2;
发生这种情况：
//Thread 1
int x = 0;
x = 2; //from Thread 2
int r1 = x;
//Thread 2
int x = 0;
x = 1; //from Thread 1
int r2 = x;
这是完全有效的。 （可接受的例外。）
【讨论】：
r1 == 2和r2 == 1。您的示例显示 r1 == 1 和 r2 == 2 而“编译器不会重新排序每个线程中的语句；[...]”。