JMM - Java 内存模型，java 读写锁源码分析

内存可见性问题的核心是 CPU 的缓存与主内存不一致。

那么，这里就涉及到计算机原理的部分知识，下图是 X86 架构下 CPU 缓存的布局：

CPU 架构图

从图中可以看出 CPU 有多级缓存，每个核心的一二级缓存数据都是该 CPU 核心私有的，由于有缓存一致性协议（例如 MESI ）的存在，各个核心的缓存之间不会存在不同步的问题。

这里简单讲一下缓存一致性协议 MESI，当各个 CPU 核心都缓存了一个共享变量时，有任何一个核心对它作出了修改都会让其他核心内对应变量的缓存单元失败（这里失效的是整个 CacheLine，不仅仅是变量所占用的区域）并且把修改值同步到主内存。其他核心如果后续要操作这个变量，必须从主内存读，这样就可以保证各个缓存的一致性。

但引入缓存一致性协议会有很大的性能损耗，为了解决这个问题，又进行了各种优化，这其中就有在计算单元和一级缓存之间引入 StoreBuffer 和 LoadBuffer ，如下图所示：

加入各种 Buffer 的 CPU 架构图组

StoreBuffer 和 LoadBuf

【一线大厂Java面试题解析+核心总结学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

fer 的引入，大大提升了计算机性能，但同时也带来了一些问题：各级缓存之间数据是一致的，但 StoreBuffer 和 LoadBuffer 一级缓存之间的数据却是异步的，这里就会存在一致性问题。

当一个缓存中的数据被修改后，会存到 StoreBuffer 中，而 StoreBuffer 不会立即把修改后的数据同步到主内存，这时其他核心在主内存中读取到就是旧数据，也就是说一个数据在一个核心的写操作会出现对其他核心不可见的情况，这就是内存可见性问题。

重排序

上面讲的内存可见性问题其本质就是 CPU 内存重排序，它是重排序的一种。这里讲一下什么是重排序。

重排序分为三种：编译重排序、CPU 指令重排序和 CPU 内存重排序。

• 编译器重排序：对于没有先后依赖的语句，编译器可以重新调整语句的顺序；

• CPU 指令重排序：对于没有先后依赖的指令并行执行；

• CPU 内存重排序：CPU 有自己的缓存，指令的执行顺序与写入主内存的顺序不一定一致。

编译器重排序对开发者来说是无感知的，我们主要关注的是 CPU 指令重排序和 CPU 内存重排序，这两者都会对运行结果产生影响。

举个例子：假如有 X，Y，a，b 四个共享变量，我们在两个不同的线程分别执行下面的代码：

线程一：

X = 1;

a = Y;

线程二：

Y = 1;

b = X;

这两个线程的执行顺序是不一定的，有可能是顺序执行，也可能是交叉执行，最终结果可能是：

• a = 0, b = 1 (线程一执行 -> 线程二执行)

• b = 0, a = 1 (线程二执行 -> 线程一执行)

• a = 1, b = 1 (两个线程交叉执行)

上面就是 CPU 指令重排序产生的影响。但实际情况会有第四种结果：

• a = 0, b = 0 （内存重排序）

导致这个结果的原因是两个线程全部或其中一个的写入操作没有同步到主内存中，因此给 a 或 b 赋值时读取到的还是旧值 0，这就是内存可见性问题。

CPU 指令重排序问题我们可以通过锁、CAS 等同步机制来解决，编译器重排序和 CPU 内存重排序都可以通过引入内存屏障来解决，这里主要关注内存屏障在 CPU 重排序的应用。

内存屏障

===================================================================

内存屏障是一个比较底层的概念，它能对重排序作一定的限制，不同的内存屏障对重排序限制不同，一般都是组合使用的。作为 Java 开发者我们知道使用 volatile 关键字修饰的变量不会存在内存可见性问题，它的原理其实就是在对变量的操作前后都加入了两个不同的内存屏障，以保证所有的读写组合都不会发生内存可见性问题。

可以把内存屏障分为四类：

• LoadLoad：禁止读和读的重排序

• StoreStore：禁止写和写的重排序

• LoadStore：禁止读和写的重排序

• StoreLoad：禁止写和读的重排序

JDK 8 开始，Unsafe 类提供了三个内存屏障方法：