《 JAVA 并发编程的艺术》一书中说指令重排序可能会改变多线程程序的执行结果。举的例子如下：
class test { private int a = 0; private boolean flag = false;
public void change() { a = 1; flag = true; } public void sysout() { while (flag) { System.out.println(a); } } }
书中说以上程序在多线程时，输出的结果不一定是 1，有可能是 0 ； 但是我自己尝试了多次也未复现出这种情况，因此非常疑问这个情况真的可以复现出来吗？这个指令重排序到底说的真的假的呀？如果有复现出来的同学可以发个程序执行结果的图看下嘛？
1. 你要确认 class 文件的字节码是否存在重排序，最好去翻一下字节码，一般这种简单的代码，
我觉得可能字节码层面不会发生重排序
2. 你要用这些代码 反复运行 让 JVM 生成 JIT 后的汇编指令，看下 JIT 后的汇编代码是否存在重排序
3. CPU 层面还有分支预测跟指令冒险 这个更加不好验证
4. 另外这里多线程的话 还要涉及到内存可见性的问题的，因为 CPU 的 L1 L2 L3 同步的模型很复杂，
现在 X86 都是 TSO 模型，具体到 Intel 下面还有 MESI 的模型，另外 AMD zen2 架构流行后，
现在又开始流行 NUMA 了，总之多线程同步下面的技术细节太多。
有兴趣的话 你可以研究我的这篇博文，是关于内存可见性的研究，里面对 JVM 的 JIT 后的代码 用 GDB 打断点验证过了
https://www.cnblogs.com/richard-winters/p/14237940.html
关于重排序跟 memory barrier 这块，你只要记住 多线程同步的时候 一定要用 Java 的锁或者原子变量就行了，
因为这两个都会用 x86 的同步原语 lock sfence mfence 等指令，如果不想搞清楚底层同步的原语，最好的办法就是记住 Java 的 happen before 原则就行了，这样多线程编程的时候就不会被底层的技术细节给搞蒙 B 了。
sysout() 线程可能根本就没观测到 change() 线程里面 对变量 a 的修改，因为 a 既没有 volatile （ x86 的 lock 原语），可能线程 sysout() 取到 a 的值 只是它在寄存器里面之前的拷贝，或者是线程 sysout() CPU 的 L1 的缓存，
而且 sysout() 跟 change() 线程 都没有用到 同步的原语
System.out.println 的内部实现自带一个锁，影响了并发语义，它是最容易犯的验证并发的错误。
跟汇编根本没关系
这个问题是 smp 情况下，cpu 对内存的写是异步的，一个 cpu 读到 flag 等于 true 时，a=1 这个写操作不一定就同步过来到这个 cpu 上，可能看到的还是 0
为了保障逻辑正确，需要加同步等待指令
重排序是完全可能发生的，因为从编译器到 CPU 都是保证单线程 as-if-serial 语义，
多线程的时候只能用到处理的同步原语才能解决
int a = 2;
int c = 1 + a;
float b = 3f / 2f;
像这种代码 第三条代码完全可能发生重排序，因为浮点运算会用到 FPU 而 CPU 完全是空闲出来的，
而且从 CPU 优化的角度来看，第一条指令跟第二条有依赖，所以不会重排，但是 第三条指令跟 第一条 and 第二条指令不存在任何依赖，所以将 float b= 3f/2f 提前拿出来 交给 FPU 计算 得出结果是完全合理的，而且并不会影响程序的正确性，当然这一切都是在单线程的情况下，如果你多线程需要同步，那么必然要用 x86 lock mfence 这些原语来禁止 重排序
@minato
@fuse 你们两位说的是可见性的问题，不过我这个主要是为了探讨指令重排序，当然以上程序也有可能是因为可见性导致出现的输出 0 。我补充了重排序可能出现的情况。您可以看下。
这样一来，多线程环境下，监听线程读取到 flag 变成 true 的时候，a 的值有可能=0 有可能=1，不能按编码顺序去理解
要说 Memory Model 那涉及到的东西就更多了。