缓存一致性协议

缓存一致性协议

在执行程序时，每一条指令都是在CPU中执行的，执行指令过程中会包含读取与写入的操作。一般来说程序运行过程中的临时数据都存放在主存(即内存)中，由于CPU执行速度很快，但每次从内存读取数据和向内存写入数据的过程与CPU执行指令速度比起来要慢的多，若是每次对数据的操作都与内存进行交互的话，会大大降低指令执行的速度，为了提升性能，CPU中出现了高速缓存(cache，现在一般都有三级缓存)！

CPU有了高速缓存之后，但程序在运行时，会将运算需要的数据从主存中复制一份到CPU的高速缓存中，接着进行读取与写入操作即就从其高速缓存中进行，当运算结束后，会将高速缓存中的数据刷新到主存中。
举例执行i=i+1，该条指令在单线程中并不会有问题，但是在多线程中就会出现线程安全问题！

问题描述：由于是多线程，可能多个线程会同时拷贝一份主存中的对应变量，接着在线程中不断对对应自己线程的副本进行读取写入操作，当多个线程执行完之后，重新刷新高速缓存中的值到主存，这时候就会出现缓存不一致问题！

解决缓存不一致问题方法：硬件层面提供方法

**通过在总线加LOCK#锁的方式。但是锁的是IO总线。这就变成串行肯定有性能问题。

后来引入锁缓存行。CacheLine: 64byte（64bit机）为一个缓存行，8个缓存行为一个内存块。如果锁的数据超过缓存行这个锁也会失效。锁缓存行有一套协议叫缓存一致性协议。

就是定义这个缓存行的锁如何有效。缓存一致性协议的实现很有很多比如：MESI,MSI,MOESI等。

大部分系统都会实现MESI。

MESI协议 规定每条缓存都有一个状态位(额外两位表示)，该状态位可对应四种状态：
①修改态(Modified)：此缓存被修改过，与主存数据不一致，为此缓存专有。
②专有态(Exclusive)：此缓存与主内存一致，但是其他CPU中没有。
③共享态(Shared)：此缓存与主内存一致，但也出现在其他缓存中。
④无效态(Invalid)：此缓存无效，需要从主内存重新读取

在MESI协议下。Thread1和Thread2读取i=0就变成下面的这个流程。
（1）Thread1从主存中读取i=0,数据存在高速缓存中，这时候的状态为E（独占）,在缓存行有监听机制，可以监听到缓存的主存的数据被其它CPU也读取了。
（2）Thread2从主存中读取i=0,数据存在高速缓存中，这个时候监听机制知道有两个核读取到了i=0数据，它们在缓存中的状态变成了S(共享)。
（3）Thread1把数据i=0从缓存读取到寄存器进行修改操作i=1,缓存行的数据被修改后状态变成M,监听到数据被修改后Thread2中的数据状态变成I。
（4）缓存一致性协议会保证这个修改了的数据立马刷回主存，而不是等待某个时间点再刷回主存，因为Thread2中的数据失效了需要从主存中再次读取数据，为了减少CPU等待时间，Thread1需要立即刷回主存而且能保证刷回主存是原子性的。

说明：这仅仅是CPU硬件层面的，对于Java的话需要去知晓对应的Java内存模型(JMM)对应的规范说明。
————————————————
原文链接：https://blog.csdn.net/cl939974883/article/details/115497264

volatile和MESI协议之间的关系

首先强调一点，volatile和mesi这两个东西没有半点关系。mesi是缓存一致性的一种实现手段，多核CPU为了保证缓存数据的一致性，通常有两种实现手段，一种是总线锁，另一种是缓存锁。总线锁性能消耗大，缓存锁则一般通过缓存一致性来实现。因此我们知道mesi是CPU硬件级别的。 volatile是JAVA的一种关键字，实现了两个功能： 1.可见性 2.禁止乱序。 禁止乱序，在JVM层面使用内存屏障来实现，汇编级别通过lock #指令来实现。

问题：既然CPU有了MESI协议可以保证cache的一致性，那么为什么还需要volatile这个关键词来保证可见性(内存屏障)？或者是只有加了volatile的变量在多核cpu执行的时候才会触发缓存一致性协议？

两个解释结论：

多核情况下，所有的cpu操作都会涉及缓存一致性的校验，只不过该协议是弱一致性，不能保证一个线程修改变量后，其他线程立马可见，也就是说虽然其他CPU状态已经置为无效，但是当前CPU可能将数据修改之后又去做其他事情，没有来得及将修改后的变量刷新回主存，而如果此时其他CPU需要使用该变量，则又会从主存中读取到旧的值。而volatile则可以保证可见性，即立即刷新回主存，修改操作和写回操作必须是一个原子操作；
正常情况下，系统操作并不会进行缓存一致性的校验，只有变量被volatile修饰了，该变量所在的缓存行才被赋予缓存一致性的校验功能。

我们再来看一下另一位大N的解释:

首先，volatile是java语言层面给出的保证，MSEI协议是多核cpu保证cache一致性（后面会细说这个一致性）的一种方法，中间隔的还很远，我们可以先来做几个假设：

回到远古时候 那个时候cpu只有单核，或者是多核但是保证sequence consistency[1]，当然也无所谓有没有MESI协议了。那这个时候，我们需要java语言层面的volatile的支持吗？当然是需要的，因为在语言层面编译器和虚拟机为了做性能优化，可能会存在指令重排的可能，而volatile给我们提供了一种能力，我们可以告诉编译器，什么可以重排，什么不可以。
那好 假设更进一步，假设java语言层面不会对指令做任何的优化重排，那在多核cpu的场景下，我们还需要volatile关键字吗？答案仍然是需要的。因为 MESI只是保证了多核cpu的独占cache之间的一致性，但是cpu的并不是直接把数据写入L1 cache的，中间还可能有store buffer。有些arm和power架构的cpu还可能有load buffer或者invalid queue等等。因此，有MESI协议远远不够。
再接着 让我们再做一个更大胆的假设。假设cpu中这类store buffer/invalid queue等等都不存在了，cpu是数据是直接写入cache的，读取也是直接从cache读的，那还需要volatile关键字吗？你猜的没错，还需要的。原因就在这个“一致性”上。consistency和coherence都可以被翻译为一致性，但是MSEI协议这里保证的仅仅coherence而不是consistency。那consistency和cohence有什么区别呢？下面取自wiki[2]的一段话：
Coherence deals with maintaining a global order in which writes to a single location or single variable are seen by all processors. Consistency deals with the ordering of operations to multiple locations with respect to all processors.

因此，MESI协议最多只是保证了对于一个变量，在多个核上的读写顺序，对于多个变量而言是没有任何保证的。很遗憾，还是需要volatile～～

好的，到了现在这步，我们再来做最后一个假设，假设cpu写cache都是按照指令顺序fifo写的，那现在可以抛弃volatile了吧？你觉得呢？我都写到标题4了，那肯定不行啊！因为对于arm和power这个weak consistency[3]的架构的cpu来说，它们只会保证指令之间有比如控制依赖，数据依赖，地址依赖等等依赖关系的指令间提交的先后顺序，而对于完全没有依赖关系的指令，比如x=1;y=2，它们是不会保证执行提交的顺序的，除非你使用了volatile，java把volatile编译成arm和power能够识别的barrier指令，这个时候才是按顺序的。

引用：https://www.zhihu.com/question/296949412/answer/747494794