硬件工程师一直在努力地优化他们产品的性能，使我们可以获取更多的代码外的高性能部件。然而，它带来的问题是：当你的代码在运行时，你并不能直观地查看它是运行在什么场景下。有着无数硬件细节被抽象化。而抽象往往意味着容易有漏洞 。

处理器缓存

对主存的请求是一项昂贵的操作，即使是在现代机器上，在执行的时候也会花上百纳秒的时间。然后，其他操作的执行时间，不同于主存的访问，其发展就显缓慢。这个问题通常被称为Memory Wall ，而最明显的解决方案就是引入缓存。简单来说，处理器对它经常访问的主存数据保存一份拷贝。你可以在这里 深入阅读不同的缓存架构，我们将会继续另外一个问题：保持缓存最新。

很明显，当我们只有一个执行部件（从现在开始这里指处理器）时是没问题的，但当你拥有多于一个时，事情会变得复杂。

如果A缓存了某些值，处理器A怎么知道处理器B已经修改了它们呢？

或者，更一般地说，你怎么保证缓存一致性

为了保存内存状态的一致性，处理器需要进行交互。那种交互的规则称之为缓存一致性协议（cache coherency protocol）

缓存一致性协议

现在有着很多不同的协议，不同的硬件厂商，甚至同一个厂商的不同产品线都会有所不同。尽管有着各种各样的区别，但大部分协议都有着很多共同点，这也是我们需要深入MESI的原因。然而，它并没有给读者一个所有协议的完整概述。有一些协议（例如基于目录的 ）是完全不一样的。我们不准备深入他们。

在MESI中，每一个缓存条目都会属于以下状态之一：

1无效（Invalid)缓存不再拥有该条目

2独占（Exclusive）这个条目只存在于这个缓存，没有被修改

3已修改（Modified）处理器已经修改过这个值，但还没有写回主存或者发送给其他处理器

4共享（Shared）多于一个处理器的缓存拥有该条目

状态之间的转换是通过发送特定的协议消息。具体的消息类型关系不大，所以在本文忽略了。你可以通过很多其他的资料去深入了解它们。讽刺的是：当我们深入时，消息被用于并发修改状态。这是个问题。那么那些讨厌Actor Model的人怎么办？

MESI优化和他们引入的问题

在还没有说到细节时，我们知道消息的传递是需要时间的，它使得状态切换有更多的延迟。重要的是我们也需要意识到某些状态的切换需要特殊的处理，可能会阻塞处理器。这些都将会导致各种各样的稳定性和性能问题。

存储缓存（Store Bufferes）

如果你需要对一个在缓存中的共享的变量进行写入，你需要发送一个失效（Invalidate）消息给它的所有持有者，并且等待它们的确认。处理器在这段时间间隔内会阻塞，这是一个不爽的事情，因为这个时间的要求比普通执行一个指令要长得多。

在现实生活中，缓存条目不只包含一个变量。这个被划分出来的单元是一个缓存链，通常包含多于一个变量，并且很多是64字节大小的。

它会导致有趣的问题，例如缓存竞争

为了避免这种时间的浪费，Store Bufferes被引入使用。处理器把它想要写入到主存的值写到缓存，然后继续去处理其他事情。当所有失效确认（Invalidate Acknowledge）都接收到时，数据才会最终被提交。

有人会想到这里有一些隐藏的危险存在。简单的一个就是处理器会尝试从存储缓存（Store buffer）中读取值，但它还没有进行提交。这个的解决方案称为Store Forwarding，它使得加载的时候，如果存储缓存中存在，则进行返回。

相关教程推荐e良师益友网的Java教程