13.深入浅出高速缓存带来的可见性问题

Core 0修改了x的值之后，这个Cache line变成了M(Modified)状态，其他Core对应的Cache line变成了I(Invalid)状态。

状态明确之后，那相互之间是如何迁移的呢？这个过程描述起来非常复杂，我们只看简化的情况：

假如只有两个CPU核，如图1所示，当单个CPU从主内存中读取一个数据保存到高速缓存中时，具体的流程是CPU0发出从内存中读取x变量的指令，主内存通过总线返回数据后缓存到CPU0的高速缓存中 ，并且设置该缓存状态为E。

此时如果CPU1同样发出一条针对x的读取指令，如图2所示，那么当CPU0检测到时会针对该消息做出响应，将缓存在CPU0里的x通过Read Response消息返回给CPU1，此时x分别存储在CPU0和CPU1的高速缓存中，所以x的状态被设置为S。

然后CPU0把x变量的值修改成x=30，把自己的缓存状态设置为E，接着把修改后的值写入内存，此时x的缓存行是共享状态，同时需要发送一个Invalidate消息给其他缓存，CPU1收到该消息之后，把高速缓存中的x设置为Invalid，最终得到如下的结构：

 也许这里你会有个疑问，图3中Cache的状态应该是E还是M呢？我的理解是如果将x=30同步到内存之前就是M，同步到内存之后就是E。

根据上面的描述，我们可以看到，CPU的高速缓存导致了缓存一致性的问题，为此，CPU层面提供了总线锁和缓存锁的机制。基本思想是通过LOCK#信号触发总线锁和缓存锁，如果不支持总线锁。则会使用缓存一致性协议来保证缓存一致性协议。其目标都是为了保证同一时刻只允许一个CPU堆共享内存进行读写操作。

总结

说了这么多，那volatile到底做了什么呢？其实就是JVM看到某个变量有volatile之后，调了一下底层的Lock#指令而已。其他的都交给CPU和总线等来处理了。

说了这么多，与volatile有啥关系呢？Volatile一个关键字将上面的内容全给实现了，或者调用底层的服务来实现了。我们可以看一下，当我们对一个变量加了volatile关键字之后在不同的层次会有什么变化，具体包括：

• 代码层面： volatile关键字

• 字节码层面：ACC_VOLATILE字段访问标识符

• JVM层面：JMM要求实现为内存屏障。

• （Hospot）系统底层： 读volatile基于c++的volatile关键字，每次从主存中读取。 写volatile基于c++的volatile关键字和 lock 指令的内存屏障，每次将新值刷新到主存，同时其他cpu缓存的值失效。 C++的volatile禁止对这个变量相关的代码进行乱序优化（重排序），也就具有内存屏障的作用了。

• Linux内核也可以手动插入内存屏障：_ asm _ _ volatile _ ( " " : : : "memory" )。这样就控制CPU的执行按照的执行了。

拓展

这里补充一个概念，上面图中我们用的是缓存行而不是缓存，而且这里会引申出另外一个问题——伪共享问题，感兴趣的同学可以研究一下。