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