什么是JMM模型？

过甚其词

于 2022-10-22 18:19:21 发布

阅读量459

点赞数

文章标签： jvm java 面试

本文链接：https://blog.csdn.net/qq_42804252/article/details/127465211

版权

什么是JMM模型？

《Java虚拟机规范》中曾试图定义一种"java内存模型"来屏蔽各种硬件和操作系统的内存访问差异，以实现让java程序在各种平台下都能达到一致的内存访问效果，主要定义程序中各种变量的访问规则。

Java 内存模型（Java Memory Model 简称JMM）是一种抽象的概念，来屏蔽各种硬件和操作系统的内存访问差异，已实现让java程序在各种平台下都能达到一致的内存访问差异。而他并不真实存在，它描述的一组规则或规范，通过这组规范定义了程序中各个变量（包括实例字段、静态字段和构成数组对象的元素）的访问方式。JVM运行程序的实体是线程，而每个线程创建时 JVM 都会为其创建一个工作内存（有些地方称为栈空间），用于存储线程私有的数据，而Java 内存模型中规定所有变量都存储在主内存，其主内存是共享内存区域，所有线程都可以访问，但线程对变量的操作（读取赋值等）必须在工作内存中进行，首先要将变量从主内存拷贝到增加的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，不能直接操作主内存中的变量，工作内存中存储这主内存中的变量副本拷贝，工作内存是每个线程的私有数据区域，因

此不同的线程间无法访问对方的工作内存，线程间的通信（传值）必须通过主内存来完成。

JMM 不同于 JVM 内存区域模式

JMM 与 JVM 内存区域的划分是不同的概念层次，更恰当说 JMM 描述的是一组规则，通过这组规则控制各个变量在共享数据区域内和私有数据区域的访问方式，JMM是围绕原子性、有序性、可见性展开。JMM 与 Java 内存区域唯一相似点，都存在共享数据区域和私有数据区域，在 JMM 中主内存属于共享数据区域，从某个程度上讲应该包括了堆和方法区，而工作内存数据线程私有数据区域，从某个程度上讲则应该包括程序计数器、虚拟机栈以及本地方法栈。

线程、工作内存、主内存工作交互图（基于JMM规范），如下：

主内存

主要存储的是Java实例对象，所有线程创建的实例对象都存放在主内存中，不管该实例对象是成员变量还是方法中的本地变量（也称局部变量），当然也包括了共享的类信息、常量、静态变量。由于是共享数据区域，多个线程同一个变量进行访问可能会发送线程安全问题。

工作内存

主要存储当前方法的所有本地变量信息（工作内存中存储着主内存中的变量副本拷贝），每个线程只能访问自己的工作内存，即线程中的本地变量对其他线程是不可见的，就算是两个线程执行的是同一段代码，它们也会在各自的工作内存中创建属于当前线程的本地变量，当然也包括了字节码行号指示器、相关Native方法的信息。注意由于工作内存是每个线程的私有数据，线程间无法相互访问工作内存，因此存储在工作内存的数据不存在线程安全问题。

根据 JVM 虚拟机规范主内存与工作内存的数据存储类型以及操作方式，对于一个实例对象中的成员方法而言，如果方法中包括本地变量是基本数据类型（boolean、type、short、char、int、long、float、double），将直接存储在工作内存的帧栈中，而对象实例将存储在主内存（共享数据区域，堆）中。但对于实例对象的成员变量，不管它是基本数据类型或者包装类型（Integer、Double等）还是引用类型，都会被存储到堆区。至于 static 变量以及类本身相关信息将会存储在主内存中。

针对long和double型变量的特殊规则

Java内存模型要求lock、unlock、read、load、assign、use、store、write这八种操作都具有原子性，但是对于64位的数据类型（long和double），在模型中特别定义了一条宽松的规定：允许虚拟机将没有被volatile修饰的64位数据的读写操作划分为两次32位的操作来进行，即允许虚拟机实现自行选择是否要保证64位数据类型的load、store、read和write这四个操作的原子性，这就是所谓的“long和double的非原子性协定”（Non-Atomic Treatment of double and long Variables）。

如果有多个线程共享一个并未声明为volatile的long或double类型的变量，并且同时对它们进行读取和修改操作，那么某些线程可能会读取到一个既不是原值，也不是其他线程修改值的代表了“半个变量”的数值。不过这种读取到“半个变量”的情况是非常罕见的，经过实际测试[1]，在目前主流平台下商用的64位Java虚拟机中并不会出现非原子性访问行为，但是对于32位的Java虚拟机，譬如比较常用的32 位x86平台下的HotSpot虚拟机，对long类型的数据确实存在非原子性访问的风险。从JDK 9起， HotSpot增加了一个实验性的参数-XX：+AlwaysAtomicAccesses（这是JEP 188对Java内存模型更新的一部分内容）来约束虚拟机对所有数据类型进行原子性的访问。而针对double类型，由于现代中央处理器中一般都包含专门用于处理浮点数据的浮点运算器（Floating Point Unit，FPU），用来专门处理单、双精度的浮点数据，所以哪怕是32位虚拟机中通常也不会出现非原子性访问的问题，实际测试也证实了这一点。笔者的看法是，在实际开发中，除非该数据有明确可知的线程竞争，否则我们在编写代码时一般不需要因为这个原因刻意把用到的long和double变量专门声明为volatile。

需要注意的是，在主内存中的实例对象可以被多线程共享，倘若两个线程同时调用类同一个对象的同一个方法，那么两个线程会将要操作的数据拷贝一份到直接的工作内存中，执行晚操作后才刷新到主内存。模型如下图所示：

Java 内存模型与硬件内存架构的关系

通过对前面的硬件内存架构、Java内存模型以及Java多线程的实现原理的了解，我们应该已经意识到，多线程的执行最终都会映射到硬件处理器上进行执行，但Java内存模型和硬件内存架构并不完全一致。对于硬件内存来说只有寄存器、缓存内存、主内存的概念，并没有工作内存（线程私有数据区域）和主内存（堆内存）之分，也就是说 Java 内存模型对内存的划分对硬件内存并没有任何影响，因为 JMM 只是一种抽象的概念，是一组规则，并不实际存在，不管是工作内存的数据还是主内存的数据，对于计算机硬件来说都会存储在计算机主内存中，当然也有可能存储到 CPU 缓存或者寄存器中，因此总体上来说，Java 内存模型和计算机硬件内存架构是一个相互交叉的关系，是一种抽象概念划分与真实物理硬件的交叉。（注意对于Java内存区域划分也是同样的道理）

JMM 存在的必要性

在明白了 Java 内存区域划分、硬件内存架构、Java多线程的实现原理与Java内存模型的具体关系后，接着来谈谈Java内存模型存在的必要性。

由于JVM运行程序的实体是线程，而每个线程创建时 JVM 都会为其创建一个工作内存（有些地方称为栈空间），用于存储线程私有的数据，线程与主内存中的变量操作必须通过工作内存间接完成，主要过程是将变量从主内存拷贝的每个线程各自的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，如果存在两个线程同时对一个主内存中的实例对象的变量进行操作就有可能诱发线程安全问题。

假设主内存中存在一个共享变量 x ，现在有 A 和 B 两个线程分别对该变量 x=1 进行操作， A/B线程各自的工作内存中存在共享变量副本 x 。假设现在 A 线程想要修改 x 的值为 2，而 B 线程却想要读取 x 的值，那么 B 线程读取到的值是 A 线程更新后的值 2 还是更新钱的值 1 呢？

答案是：不确定。即 B 线程有可能读取到 A 线程更新钱的值 1，也有可能读取到 A 线程更新后的值 2，这是因为工作内存是每个线程私有的数据区域，而线程 A 操作变量 x 时，首先是将变量从主内存拷贝到 A 线程的工作内存中，然后对变量进行操作，操作完成后再将变量 x 写回主内存。而对于 B 线程的也是类似的，这样就有可能造成主内存与工作内存间数据存在一致性问题，假设直接的工作内存中，这样 B 线程读取到的值就是 x=1 ，但是如果 A 线程已将 x=2 写回主内存后，B线程才开始读取的话，那么此时 B 线程读取到的就是 x=2 ，但到达是那种情况先发送呢？

如下图所示案例：以上关于主内存与工作内存直接的具体交互协议，即一个变量如何从主内存拷贝到工作内存，如何从工作内存同步到主内存之间的实现细节，Java内存模型定义来以下八种操作来完成。

数据同步八大原子操作

lock（锁定）：作用于主内存的变量，把一个变量标记为一个线程独占状态；
unlock（解锁）：作用于主内存的变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定；
read（读取）：作用于主内存的变量，把一个变量值从主内存传输到线程的工作内存中，以后随后的load工作使用；
load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量；
use（使用）：作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎；
assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量；
store（存储）：作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以便随后的write的操作；
wirte（写入）：作用于工作内存的变量，它把store操作从工作内存中的一个变量值传送到主内存的变量中。

如果要把一个变量从主内存中复制到工作内存中，就需要按顺序地执行 read 和 load 操作；
如果把变量从工作内存中同步到主内存中，就需要按顺序地执行 store 和 write 操作。

但Java 内存模型只要求上述操作必须按顺序执行，而没有保证必须是连续执行。

同步规则分析

不允许一个线程无原因地（没有发生任何 assign 操作）把数据从工作内存同步回主内存中；
一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化（load 或者 assign）的变量。即就是对一个变量实施 use 和 store 操作之前，必须先自行 assign 和 load 操作；
一个变量在同一时刻只允许一条线程对其进行 lock 操作，但 lock 操作可不被同一线程重复执行多次，多次执行 lock 后，只有执行相同次数 unlock 操作，变量才会被解锁。lock 和 unlock 必须成对出现；
如果对一个变量执行 lock 操作，将会清空工作内存中此变量的值，在执行引擎使用变量之前需要重新执行 load 或 assign 操作初始化变量的值；
如果一个变量事先没有被 lock 操作锁定，则不允许对它执行 unlock 操作；也不允许去 unlock 一个被其他线程锁定的变量；
对一个变量执行 unlock 操作之前，必须先把此变量同步到主内存中（执行store 和 write 操作）。

并发编程的可见性、原子性与有序性问题

原子性

原子性指的是一个操作不可中断，即使是在多线程环境下，一个操作一旦开始就不会被其他线程影响。

在Java中，对于基本数据类型的变量的读取和赋值操作是原子性操作需要注意的是：对于32位系统来说，long 类型数据和 double 类型数据（对于基本类型数据：byte、short、int、float、boolean、char 读写是原子操作），它们的读写并非原子性的，也就是说如果存在两条线程同时对 long 类型或者 double 类型的数据进行读写是存在相互干扰的，因为对于32位虚拟机来说，每次原子读写是32位，而 long 和 double 则是64位的存储单元，这样回导致一个线程在写时，操作完成前32位的原子操作后，轮到B线程读取时，恰好只读取来后32位的数据，这样可能回读取到一个即非原值又不是线程修改值的变量，它可能是“半个变量”的数值，即64位数据被两个线程分成了两次读取。但也不必太担心，因为读取到“半个变量”的情况比较少，至少在目前的商用虚拟机中，几乎都把64位的数据的读写操作作为原子操作来执行，因此对于这个问题不必太在意，知道怎么回事即可。

X=10; //原子性(简单的读取、将数字赋值给变量) 
Y = x; //变量之间的相互赋值，不是原子操作
X++; //对变量进行计算操作
X=x+1;
复制代码

可见性

理解了指令重排现象后，可见性容易理解了。可见性指的是当一个线程修改了某个共享变量的值，其他线程是否能够马上得知这个修改的值。对于串行程序来说，可见性是不存在的，因为我们在任何一个操作中修改了某个变量的值，后续的操作中都能读取到这个变量，并且是修改过的新值。

但在多线程环境中可就不一定了，前面我们分析过，由于线程对共享变量的操作都是线程拷贝到各自的工作内存进行操作后才写回到主内存中的，这就可能存在一个线程A修改了共享变量 x 的值，还未写回主内存时，另外一个线程B又对主内存中同一个共享变量 x 进行操作，但此时A线程工作内存中共享变量 x 对线程B来说并不可见，这种工作内存与主内存同步延迟现象就会造成可见性问题，另外指令重排以及编译器优化也可能回导致可见性问题，通过前面的分析，我们知道无论是编译器优化还是处理器优化的重排现象，在多线程环境下，确实回导致程序乱序执行的问题，从而也就导致可见性问题。

有序性

有序性是指对于单线程的执行代码，我们总是认为代码的执行是按顺序依次执行的，这样的理解并没有毛病，比较对于单线程而言确实如此，但对于多线程环境，则可能出现乱序现象，因为程序编译称机器码指令后可能回出现指令重排现象，重排后的指令与原指令的顺序未必一致，要明白的是，在Java程序中，倘若在本线程内，所有操作都视为有序行为，如果是多线程环境下，一个线程中观察另外一个线程，所有操作都是无序的，前半句指的是单线程内保证串行语义执行的一致性，后半句则指令重排现象和工作内存与主内存同步延迟现象。

JMM如何解决原子性、可见性和有序性问题

原子性问题

除了 JVM 自身提供的对基本数据类型读写操作的原子性外，可以通过 synchronized 和 Lock 实现原子性。因为 synchronized 和 Lock 能够保证任一时刻只有一个线程访问该代码块。

可见性问题

volatile 关键字可以保证可见性。当一个共享变量被 volatile 关键字修饰时，它会保证修改的值立即被其他的线程看到，即修改的值立即更新到主存中，当其他线程需要读取时，它会去内存中读取新值。synchronized 和 Lock 也可以保证可见性，因为它们可以保证任一时刻只有一个线程能访问共享资源，并在其释放锁之前将修改的变量刷新到内存中。