面试官：说说什么是Java内存模型？

绝地灬酷狼 2023-01-18 04:12 217阅读 0赞

在面试中，面试官经常喜欢问：『说说什么是Java内存模型(JMM)？』

面试者内心狂喜，这题刚背过：『Java内存主要分为五大块：堆、方法区、虚拟机栈、本地方法栈、PC寄存器，balabala……』

面试官会心一笑，露出一道光芒：『好了，今天的面试先到这里了，回去等通知吧』

一般听到等通知这句话，这场面试大概率就是凉凉了。为什么呢？因为面试者弄错了概念，面试官是想考察JMM，但是面试者一听到`Java内存`这几个关键字就开始背诵八股文了。Java内存模型(JMM)和 Java 运行时内存区域区别可大了呢，不要走开接着往下看，答应我要看完。

# 为什么要有内存模型？ #

要想回答这个问题，我们需要先弄懂传统计算机硬件内存架构。好了，我要开始画图了。

## 硬件内存架构 ##

![图片][9b64b4060fe297b957074d8376d1492d.png]

（1）CPU

去过机房的同学都知道，一般在大型服务器上会配置多个CPU，每个CPU还会有多个`核`，这就意味着多个CPU或者多个核可以同时（并发）工作。如果使用Java 起了一个多线程的任务，很有可能每个 CPU 都会跑一个线程，那么你的任务在某一刻就是真正并发执行了。

（2）CPU Register

CPU Register也就是 CPU 寄存器。CPU 寄存器是 CPU 内部集成的，在寄存器上执行操作的效率要比在主存上高出几个数量级。

（3）CPU Cache Memory

CPU Cache Memory也就是 CPU 高速缓存，相对于寄存器来说，通常也可以成为 L2 二级缓存。相对于硬盘读取速度来说内存读取的效率非常高，但是与 CPU 还是相差数量级，所以在 CPU 和主存间引入了多级缓存，目的是为了做一下缓冲。

（4）Main Memory

Main Memory 就是主存，主存比 L1、L2 缓存要大很多。

注意：部分高端机器还有 L3 三级缓存。

## 缓存一致性问题 ##

由于主存与 CPU 处理器的运算能力之间有数量级的差距，所以在传统计算机内存架构中会引入高速缓存来作为主存和处理器之间的缓冲，CPU 将常用的数据放在高速缓存中，运算结束后 CPU 再讲运算结果同步到主存中。

使用高速缓存解决了 CPU 和主存速率不匹配的问题，但同时又引入另外一个新问题：缓存一致性问题。

![图片][7806e1d8a5901dd733e2ff57de86b6af.png]

在多CPU的系统中(或者单CPU多核的系统)，每个CPU内核都有自己的高速缓存，它们共享同一主内存(Main Memory)。当多个CPU的运算任务都涉及同一块主内存区域时，CPU 会将数据读取到缓存中进行运算，这可能会导致各自的缓存数据不一致。

因此需要每个 CPU 访问缓存时遵循一定的协议，在读写数据时根据协议进行操作，共同来维护缓存的一致性。这类协议有 MSI、MESI、MOSI、和 Dragon Protocol 等。

## 处理器优化和指令重排序 ##

为了提升性能在 CPU 和主内存之间增加了高速缓存，但在多线程并发场景可能会遇到`缓存一致性问题`。那还有没有办法进一步提升 CPU 的执行效率呢？答案是：处理器优化。

> 为了使处理器内部的运算单元能够最大化被充分利用，处理器会对输入代码进行乱序执行处理，这就是处理器优化。

除了处理器会对代码进行优化处理，很多现代编程语言的编译器也会做类似的优化，比如像 Java 的即时编译器（JIT）会做指令重排序。

![图片][47a4ef891a9a77f8d2becf66afa7aa7d.png]

> 处理器优化其实也是重排序的一种类型，这里总结一下，重排序可以分为三种类型：
> 
>  *  编译器优化的重排序。编译器在不改变单线程程序语义放入前提下，可以重新安排语句的执行顺序。
>  *  指令级并行的重排序。现代处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
>  *  内存系统的重排序。由于处理器使用缓存和读写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。

# 并发编程的问题 #

上面讲了一堆硬件相关的东西，有些同学可能会有点懵，绕了这么大圈，这些东西跟 Java 内存模型有啥关系吗？不要急咱们慢慢往下看。

熟悉 Java 并发的同学肯定对这三个问题很熟悉：『可见性问题』、『原子性问题』、『有序性问题』。如果从更深层次看这三个问题，其实就是上面讲的『缓存一致性』、『处理器优化』、『指令重排序』造成的。

![图片][70bc951b06378fbba1ae326c59bc8752.png]

缓存一致性问题其实就是可见性问题，处理器优化可能会造成原子性问题，指令重排序会造成有序性问题，你看是不是都联系上了。

出了问题总是要解决的，那有什么办法呢？首先想到简单粗暴的办法，干掉缓存让 CPU 直接与主内存交互就解决了可见性问题，禁止处理器优化和指令重排序就解决了原子性和有序性问题，但这样一夜回到解放前了，显然不可取。

所以技术前辈们想到了在物理机器上定义出一套内存模型， 规范内存的读写操作。内存模型解决并发问题主要采用两种方式：`限制处理器优化`和`使用内存屏障`。

# Java 内存模型 #

同一套内存模型规范，不同语言在实现上可能会有些差别。接下来着重讲一下 Java 内存模型实现原理。

## Java 运行时内存区域与硬件内存的关系 ##

了解过 JVM 的同学都知道，JVM 运行时内存区域是分片的，分为栈、堆等，其实这些都是 JVM 定义的逻辑概念。在传统的硬件内存架构中是没有栈和堆这种概念。

![图片][6cc4c8e874164a4fb2cfcac08107ada7.png]

从图中可以看出栈和堆既存在于高速缓存中又存在于主内存中，所以两者并没有很直接的关系。

## Java 线程与主内存的关系 ##

Java 内存模型是一种规范，定义了很多东西：

*  所有的变量都存储在主内存（Main Memory）中。
 *  每个线程都有一个私有的本地内存（Local Memory），本地内存中存储了该线程以读/写共享变量的拷贝副本。
 *  线程对变量的所有操作都必须在本地内存中进行，而不能直接读写主内存。
 *  不同的线程之间无法直接访问对方本地内存中的变量。

看文字太枯燥了，我又画了一张图：

![图片][36af6da7f4e58e6b34f438378e3c38b1.png]

## 线程间通信 ##

如果两个线程都对一个共享变量进行操作，共享变量初始值为 1，每个线程都变量进行加 1，预期共享变量的值为 3。在 JMM 规范下会有一系列的操作。

![图片][283d747d575ce113e1fd01db52894863.png]

为了更好的控制主内存和本地内存的交互，Java 内存模型定义了八种操作来实现：

*  lock：锁定。作用于主内存的变量，把一个变量标识为一条线程独占状态。
 *  unlock：解锁。作用于主内存变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。
 *  read：读取。作用于主内存变量，把一个变量值从主内存传输到线程的工作内存中，以便随后的load动作使用
 *  load：载入。作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。
 *  use：使用。作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎，每当虚拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作。
 *  assign：赋值。作用于工作内存的变量，它把一个从执行引擎接收到的值赋值给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
 *  store：存储。作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以便随后的write的操作。
 *  write：写入。作用于主内存的变量，它把store操作从工作内存中一个变量的值传送到主内存的变量中。

> 注意：工作内存也就是本地内存的意思。

# 有态度的总结 #

由于CPU 和主内存间存在数量级的速率差，想到了引入了多级高速缓存的传统硬件内存架构来解决，多级高速缓存作为 CPU 和主内间的缓冲提升了整体性能。解决了速率差的问题，却又带来了缓存一致性问题。

数据同时存在于高速缓存和主内存中，如果不加以规范势必造成灾难，因此在传统机器上又抽象出了内存模型。

Java 语言在遵循内存模型的基础上推出了 JMM 规范，目的是解决由于多线程通过共享内存进行通信时，存在的本地内存数据不一致、编译器会对代码指令重排序、处理器会对代码乱序执行等带来的问题。

为了更精准控制工作内存和主内存间的交互，JMM 还定义了八种操作：`lock`, `unlock`, `read`,`load`,`use`,`assign`, `store`, `write`。

[9b64b4060fe297b957074d8376d1492d.png]: /images/20221021/0c8c30d27bbf4cb6b1d1909baef670e6.png
[7806e1d8a5901dd733e2ff57de86b6af.png]: /images/20221021/36134bcc25b945b5b8535154eaf4d999.png
[47a4ef891a9a77f8d2becf66afa7aa7d.png]: /images/20221021/4969ed567aff489c873fd6f270fd4283.png
[70bc951b06378fbba1ae326c59bc8752.png]: /images/20221021/cd40fcbc1b2e4ea189b4e59116ab107f.png
[6cc4c8e874164a4fb2cfcac08107ada7.png]: /images/20221021/753f1ea73c454b988b50df6f12a2bc82.png
[36af6da7f4e58e6b34f438378e3c38b1.png]: /images/20221021/a0740a445b8f4042b6101900bb22ec47.png
[283d747d575ce113e1fd01db52894863.png]: /images/20221021/13c30707b9e44822b964fda20129dac2.png