推荐链接:
总结——》【Java】
总结——》【Mysql】
总结——》【Redis】
总结——》【Kafka】
总结——》【Spring】
总结——》【SpringBoot】
总结——》【MyBatis、MyBatis-Plus】
总结——》【Linux】
总结——》【MongoDB】
总结——》【Elasticsearch】
数据一致性协议:
- MSI
- MESI
- MOS
- Synapse Firefly Dragon
一、概念
MESI是协议,是规范,是interface,需要CPU厂商实现。
MESI是CPU缓存一致性的协议
,大多数的CPU厂商都根据MESI去实现了缓存一致性的效果。
二、作用
让各个CPU的数据保持一致性
三、状态:4种
状态 | 描述 | 备注 |
---|---|---|
M = Modified | 被修改 | |
E = Exclusive | 独享的 | |
S = Shared | 共享的 | |
I = Invalid | 无效的 | 从内存中读取最新的数据 |
四、MESI VS volatile
MESI:是CPU硬件层面
上的一致性
volatile:是Java中JMM层面
的一致性。
MESI:有一套固定的机制,无论你是否声明了volatile,他都会基于这个机制来保证缓存的一致性(可见性)。
volatile:存在一些问题,不过也有其他的处理方案(使用总线锁,但时间成本太高 并且效率低,如果锁了总线,就一个CPU核心在干活)。
五、有了MESI协议,为啥还有volatile?
MESI协议存在问题:
MESI保证了多核CPU的独占cache之间的可见性,但是CPU不是说必须直接将寄存器中的数据写入到L1,因为在大多是×86架构的CPU中,寄存器和L1之间有一个store buffer,寄存器值可能落到了store buffer,没落到L1中,就会导致缓存不一致。而且除了×86架构的CPU,在arm和power的CPU中,还有load buffer,invalid queue都会或多或少影响缓存一致性!
MESI协议和volatile不冲突
。
- MESI是
CPU层面
的,CPU厂商很多实现不一样
,而且CPU的架构中的一些细节也会有影响,比如Store Buffer会影响寄存器写入L1缓存,导致缓存不一致。 - volatile的底层生成的是汇编的
lock指令
,这个指令会要求强行写入主内存
,并且可以忽略Store Buffer这种缓存从而达到可见性的目的,而且会利用MESI协议,让其他缓存行失效。