本文主要是介绍Java——》MESI，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
推荐链接：
总结——》【Java】
总结——》【Mysql】
总结——》【Redis】
总结——》【Kafka】
总结——》【Spring】
总结——》【SpringBoot】
总结——》【MyBatis、MyBatis-Plus】
总结——》【Linux】
总结——》【MongoDB】
总结——》【Elasticsearch】
Java——》MESI
- 一、概念
- 二、作用
- 三、状态：4种
- 四、MESI VS volatile
- 五、有了MESI协议，为啥还有volatile？
数据一致性协议：
- 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协议，让其他缓存行失效。
这篇关于Java——》MESI的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
