内存屏障保证缓存一致性

 在前面内存系统重排序提到，“写缓存没有及时刷新到内存，导致不同处理器缓存的值不一样”，出现这种情况是糟糕的，所幸处理器遵循缓存一致性协议能够保证足够的可见性又不过多的损失性能。

 缓存一致性协议给缓存行（通常为64字节）定义了个状态：独占（exclusive）、共享（share）、修改（modified）、失效（invalid），用来描述该缓存行是否被多处理器共享、是否修改。所以缓存一致性协议也称MESI协议。

• 独占（exclusive）：仅当前处理器拥有该缓存行，并且没有修改过，是最新的值。
• 共享（share）：有多个处理器拥有该缓存行，每个处理器都没有修改过缓存，是最新的值。
• 修改（modified）：缓存行被修改过了，需要写回主存，并通知其他拥有者 “该缓存已失效”。
• 失效（invalid）：缓存行被其他处理器修改过，该值不是最新的值，需要读取主存上最新的值。

MESI优化

 处理修改状态是比较耗时的操作，既要发送失效消息给其他拥有者并写回主存，还要等待其他拥有者处理失效信息，直到收到失效消息的响应。如果在这一段时间，处理器都处于空等，那是奢侈的。所以引入缓存和失效缓存来让处理器不再“等”。

存储缓存

 存储缓存（Store Buffers），也就是常说的写缓存，当处理器修改缓存时，把新值放到存储缓存中，处理器就可以去干别的事了，把剩下的事交给存储缓存。

失效队列

 处理失效的缓存也不是简单的，需要读取主存。并且存储缓存也不是无限大的，那么当存储缓存满的时候，处理器还是要等待失效响应的。为了解决上面两个问题，引进了失效队列（invalidate queue0）。

 处理失效的工作如下：
1. 收到失效消息时，放到失效队列中去。
2. 为了不让处理器久等失效响应，收到失效消息需要马上回复失效响应。
3. 为了不频繁阻塞处理器，不会马上读主存以及设置缓存为invlid，合适的时候再一块处理失效队列。

引发内存重排序

 下面是处理器A、B，依次写、读内存a的时序图。A、B都缓存了a。

 可以看到即使遵守缓存一致性协议，也会有一段时间缓存不一致（①-⑥）。

 要是读取a的操作在这段时间内，那么处理器B看到的a将是0。处理器执行顺序为写a>读a，而在内存上的顺序为读a>写a，造成了重排序。重排序可能会导致不可见性，要是此时线程A、B分别在处理器A、B上执行，那么线程A执行了写操作后，线程B看不到线程A执行的结果，共享内存a不可见，改变了程序运行结果。

避免内存重排序

 引发重排序是糟糕的，可能造成共享内存不可见，改变程序结果。那么该怎么办，不进行MESI优化吗？既不能追求性能，造成重排序，也不能追求可见性（非共享数据可见是不需要的），降低性能。

 处理器还是使用提供了个武器——内存屏障指令（Memory Barrier）：
1. 写内存屏障（Store Memory Barrier）：处理器将当前存储缓存的值写回主存，以阻塞的方式。
2. 读内存屏障（Load Memory Barrier）：处理器处理失效队列，以阻塞的方式。

 可以看到内存屏障可以阻止内存系统重排序，保证可见性。但其开销也很大，处理器需要阻塞等待，一般应用在锁的获取和释放中。

上面那段处理器A、B，依次写、读内存a，加了内存屏障后，就不会被重排序了。

boolean finish = false;
int a = 0;

//处理器A:
a = 1;
storeMemoryBarrer(); //保证a一定在主存中，且处理器B中a为invlid
finish = true;

//处理器B:
while(!finish);
loadMemoryBarrier(); //保证缓存到a最新的值，执行后a为share
assert a == 1;

JMM中抽象内存屏障

 为了更好的理解如何实现同步的可见性，JMM抽象出了内存屏障Memory Barrier。

屏障类型	伪代码	说明
LoadLoad Barrier	Load1; Barrier; Load2	Load1 在 Load2 之前读取完成
StoreStore Barrier	Store1; Barrier; Store2	Store1 在 Store2 之前写入完成，并对所有处理器可见
LoadStore Barrier	Load1; Barrier; Store2	Load1 在 Store2 之前读取完成
StoreLoad Barrier	Store1; Barrier; Load2	Store1 在 Load2 之前写入完成，并对所有处理器可见