JMM(Java Memory Model java内存模型

本文主要是介绍JMM(Java Memory Model java内存模型，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

目标：

搞清楚高并发场景下，java内存模型是怎么支持的，对象在内存中是怎么布局的？

 

目录

目标：

搞清楚高并发场景下，java内存模型是怎么支持的，对象在内存中是怎么布局的？

1.硬件层的并发优化基础知识

 2.多核CPU线程访问条件下数据不一致性问题？

 原因：

 解决方案：

缓存行

MESI带来的伪共享问题

3.CPU的乱序执行问题

 CPU乱序执行的原因

CPU乱序执行的表现

读指令的乱序执行

写指令的合并执行（write combining）

如何保证特定情况下，不乱序

CPU级别采用内存屏障保证或者Java的汇编指令 Lock ：

JVM级别再进行规范

Java代码级别采用volatitle关键字保障

1.字节码层面（.class文件）

2.JVM层面

3. os和硬件层面

---

1.硬件层的并发优化基础知识

备注：

L3高速缓存也是在主板上，所以也是被所有的CPU共享的。

L0寄存器，存储着CPU内部核心的几个计算单元，用于计算。

离CPU越近容量越小，成本越高，速度越快。

比如说 有个变量int a=3;在 L2上，计算时CPU会先把a  load到L1上，然后被L0直接加载计算。

 2.多核CPU线程访问条件下数据不一致性问题？

 原因：

两个CPU彼此独立，但是都是操作CPU的共享区域的数据，比如一个CPU 对X作了修改，另一CPU是不能及时知道的。这就造成了共享区域的数据对各个不同的CPU 来说数据不一致问题。

 解决方案：

老的CPU:

总线锁会锁住总线，使得其他CPU甚至不能访问内存中其他的地址，因而效率较低

 新的CPU

现在CPU的数据一致性，通过缓存锁+总线锁来解决

https://www.cnblogs.com/z00377750/p/9180644.html

新的CPU采用缓存锁（缓存一致性）来解决，一致性的协议又很多，Intel采用了MESI协议。

 CPU会对缓存的内容做状态标记，如果读取的内容相对于主存来说被更改过（自己修改过），则状态改这个内容对应的缓存行状态改为Modified（别的cpu对这个内容所在缓存行状态就是Invalid）;如果读取的内容自己独享，就将其所在缓存行状态改为Exclusive。如果读取的内容，我读的时候别人也在读取，该内容所在缓存行状态就修改为Shared。如果读取的内容别的cPU已经修改过，说明我的读的内容无效了，该内容所在缓存行  状态就变为Invalid。

缓存行

现在cpu 缓存数据，不是一个字节一个字节来缓存，而是以一个缓存行，默认64字节。一次性加载到缓存中。

MESI带来的伪共享问题

如果自己要修改某个数据A，发现它的状态已经变为了Invalid，则去缓存中再加载一次。

思考这个场景： x,y位于同一个缓存行，cpu1只想的读取x，cpu2只想读取y

由于读取时必须以缓存行为单位，cpu1 读取x时，也读取到了y。 cpu1改变了x的值后，x所在的缓存行的状态在CPU1中就会被改变为modified, 在cpu2中x所在的缓存行状态就会变为invalid。 因此,cpu2 本来想读取y,一看y 所在缓存行状态变为了 invalid 。就会去重新加载y所在的缓存行。问题是cpu2其实只关注y,y的值也没有变化，而x的变化和它无关。因此本质上cpu2不需要去进行这次缓存加载的。

同理cpu2对y作了修改，后cpu1也得重新加载x所对应的缓存行。

这样的重新加载是一种时间和资源的浪费，缓存一致性或者说缓存锁解决数据安全问题的的同时带来的 这个多次非必要加载缓存问题被称为伪共享问题。

3.CPU的乱序执行问题

首先明确一个事实，CPU执行指令的时候是乱序执行的。

 CPU乱序执行的原因

https://www.cnblogs.com/liushaodong/p/4777308.html

CPU的执行指令在内存中做一些操作，因为CPU的执行速度相较于内存至少时100倍，所以CPU不能干等着执行结果，为了提高效率，CPU就 在一条指令执行结束之前，继续执行别的指令。这种不按照程序的编写顺序执行的情况，被称为CPU的乱序执行问题。乱序变现在读指令的乱序，和写指令的乱序。

当然乱序执行不能带来程序的最终执行结果的乱序。所以，计算机底层，对CPU的乱序执行也是作了规范，也保障乱序执行的结果是正确的。提高了执行效率，也保证执行结果的正确性。

CPU乱序执行的表现

读指令的乱序执行

CPU在执行一条读指令后等待该指令执行完（或者返回结果）前，回去执行另一条与该指令没有依赖关系的读指令

写指令的合并执行（write combining）

合并写：

CPU将计算好的值A缓存到L1,如果缓存失败，就会缓存到L2,再此过程中L2相对于CPU太慢了，如果这个过程中A值被改写了几次。CPU会直接将改写的最终结果刷到L2。这种情况被称为合并写

如何保证特定情况下，不乱序

某些特定场景写要保证顺序，如何保障有序性

CPU级别采用内存屏障保证或者Java的汇编指令 Lock ：

sfence:在sfence指令前的写操作当必须在sfence指令后的写操作前完成。

lfence：在lfence指令前的读操作当必须在lfence指令后的读操作前完成。

mfence：在mfence指令前的读写操作当必须在mfence指令后的读写操

作前完成。

JVM级别再进行规范

LoadLoad屏障： 对于这样的语句Load1; LoadLoad; Load2，
在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕。

StoreStore屏障：
对于这样的语句Store1; StoreStore; Store2，
在Store2及后续写入操作执行前，保证Store1的写入操作对其它处理器可见。

LoadStore屏障：
对于这样的语句Load1; LoadStore; Store2，
在Store2及后续写入操作被刷出前，保证Load1要读取的数据被读取完毕。

StoreLoad屏障： 对于这样的语句Store1; StoreLoad; Load2，
​ 在Load2及后续所有读取操作执行前，保证Store1的写入对所有处理器可见。

 备注：这些规范的实现，是依赖于硬件级别的原理来实现的。具体用哪些硬件原理，怎么组合操作，JVM自己决定。

Java代码级别采用volatitle关键字保障

1.字节码层面（.class文件）

被volatile 修饰的变量在.class二进制字节码文件中多了一个acc_volatile 标记

2.JVM层面

JVM对被acc_volatile  修饰的变量,也即 .class文件中被 acc_volatile修饰的变量:

        如果它是写操作指令，则在该写操作前面加一个 StoreStoreBarrier ,后面加一个StoreLoadBarrier ,保证该指令与上下两个指令不重排序

        如果它是读操作指令，则在该读操作前面加一个 LoadLoadBarrier ，后面加一个LoadStoreBarrier ,保证该指令与上下两个指令不重排序

3. os和硬件层面

windows 上采用Lock 指令和MESI 实现，Linux我忘了，哈哈哈

这篇关于JMM(Java Memory Model java内存模型的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---