指令流水线所带来的一些问题

1. 结构冒险

   流水线中出现硬件资源竞争

2. 数据冒险

   流水线中后面的指令需要等待前面指令完成数据的读写

3. 控制冒险

   流水线需要个怒前面指令的执行结果来决定下一步去哪儿之行

为了解决指令流水线的数据冒险所带来的停顿、CPU 搞了个乱序执行。

在遇到数据冒险时、指令调度单元从中选择一些没有数据依赖的指令来执行。后面再进行结果回写时、才按原有顺序进行回写。

这就是 CPU 带来的乱序执行。

Java 编译器处于 “优化” 的目的、按照某种规则将指令重新排序（尽管有时候看起来像乱序）

这就是编译器带来的乱序。

因为 CPU 缓存同步顺序带来伪乱序。

以上即是导致重排序的三种原因。

我们先来看看 CPU 缓存所带来的一些问题

比如现在两个 CPU 都对变量 i 进行 +1、现在 i 在内存中的值为 0 (非并发 + 1)

那么

1. CPU1 从内存中将 i 值放入到自己的缓存中
2. CPU1 对 i 值进行 +1、并将结果写到自己的缓存中
3. CPU2 中的缓存中已经存在i的值了(可能是上一次读取缓存的)
4. CPU2 对 i 值进行 +1、并将结果写到自己的缓存中
5. CPU1和 CPU2 将自己缓存的 i 写回到内存中

此时 i 被加了两次、但是结果只有一次的的值。

缓存一致性协议 MESI

我们在来看看上面这个流程

1. CPU1 从内存中将 i 值放入到自己的缓存中、此时该缓存行的状态位 S （CPU2 中也有该缓存、状态为 S）
2. CPU1 发出失效命令、告知 CPU2 将它的缓存行状态置为I失效。CPU2 将 i 的缓存行状态更新为 I 并且回复 CPU1 ack 消息
3. CPU1 收到 ack 消息之后将缓存行的状态由 S 变为 E
4. 然后CPU1 对 i 值进行 +1、并将结果写到自己的缓存中、此时状态变为 M
5. CPU2 对 i 值进行 +1 前发现 i 的缓存行位 I、发起读取、CPU1 收到请求、先将 i 刷回到 内存、状态变为 E 然后再发 i 的值给 CPU2 然后状态变为 S。然后 CPU2 再发起失效命令
6. CPU2 对 i 值进行 +1、并将结果写到自己的缓存中
7. CPU2 将自己缓存的 i 写回到内存中

（事实上获取i和失效命令会同时发出、invalidate read）

那么最终 i 会被正确的+1

上面这里并非是一个并发+1的场景、也可以是一个串行的场景、只不过第一次和第二次的+1分配到不同的 cpu 上。

通过 MESI 协议、貌似解决了缓存一致性的问题。

但是我们每次都需要等待到其他 CPU 的 ack 才能去执行指令、这样子太慢了、并且其他 CPU 也可能并不是马上会去执行失效请求的、因为可能它可能正在执行其他高优先级的指令。

所以又引入了另一个组件、store buffer

它的作用很简单

1. CPU1 发起失效请求之后、CPU1 不会等其他 CPU 的 ack、而是马上执行指令、然后将执行的结果存放在 store buffer。由 store buffer 等待其他 CPU 回复 ack 、然后才将执行结果刷回到 CPU 的

但是这样子也会带来问题、比如我们下面的这段代码(ARM 架构上)

    int x = 0;int y = 0;private void write(){x = 1;y = 1;}private void read(){System.out.println(y);System.out.println(x);}

假设 x 的值已经被更新在 store buffer 了、这个时候 cpu 缓存里面 x 的值还是 0

这个时候 cpu 就会继续执行 y=1 假如这个时候 y