synchronizes-with edegs 编译器是否在两个方向上重新排序障碍？

Question

我有一个关于 Java 内存模型的问题。举个例子：

action 1
action 2
synchronized(monitorObject) { //acquire
    action 3
} //release
action 4

acquire 和release 可以是任何同步边（锁定、解锁、启动线程、加入线程、检测线程中断、volatile-write、volatile-read 等）

是否保证action 3 在获取之前 不能移动，在发布之后 不能移动？

是否保证action 2 不能在获取之后 移动（无论是在发布之前还是之后）并且action 4 不能在之前移动 em> 发布（无论是在获取之前还是之后）？

对于编译器的重新排序操作，与边“双向障碍”同步吗？

---

编辑 1 我担心这一点，因为如果 synchronizes-with 边缘不是双向重新排序障碍，编译器可以简单地通过将锁获取移动到其他锁来创建死锁。

或者双向重新排序障碍甚至不需要防止这种情况发生，因为锁获取不能被推入其他人，因为这会改变同步顺序？

---

编辑 2 动作 1、2、3 和 4 是 JMM 定义的“线程间动作”。

---

编辑 3 下面的示例显示了重新排序如何导致死锁：

x 和 y 是共享变量，syncA 和 syncB 可以被任何其他线程获取。但是使用下面的代码，就不会出现死锁了。

/* 1 */  synchronized(syncA) {
/* 2 */      x = 1;
/* 3 */  }
/* 4 */  y = 0;
/* 5 */  synchronized(syncB) {
/* 6 */      y = 1;
/* 7 */  }

但是，如果 syncA 的获取被重新排序到 syncB 块中，这可能会导致死锁：

y = 0;
synchronized(syncB) {
    y = 1;
    synchronized(syncA) {
        x = 1;
    }
}

我认为这不是合法的编译器转换，因为它会改变同步顺序。我对这个假设是否正确？ Java 内存模型 (JMM) 的哪一部分允许/不允许这样做？

Answer 1

感谢assylias 链接到this question，其中包含来自JSR-133 Cookbook 的这张图片的答案：

根据这张图片，从 EDIT 3 开始的编译器转换是非法的，因为它重新排序了两个 MonitorEnters。

此外，该表还显示了哪些同步边是哪些类型的“重新排序障碍”，用于哪些其他操作。

感谢您的帮助:)