java并发4——Java内存模型（Java Memory Model，JMM）

墨蓝 2021-12-11 20:09 238阅读 0赞

要讲java内存模型（Java Memory Model, JMM），先需要从几个基本概念讲起。

## 1，程序、进程与线程 ##

程序指一段代码，是静态的概念；而进程指运行中的代码，是动态的概念；而线程相对而言概念上没那么好解释，按照执行效果来说就是进程的小弟，拥有进程资源的小一号独立运行单元。

为什么要讲这3个概念？因为并发针对的就是这个小弟，线程。

## 2，JVM与线程 ##

JVM与线程有什么关系？具体来说，run java main方法时，先会启动JVM，进行类加载，然后调用main方法，再启动main方法自己手写的线程。后续会专门写类加载的过程。

## 3，JVM的内存区域 ##

这个图可以说把java内存区域描述得很清楚了，后续计划也写下JVM打算详细再描述一遍。但是注意哈，内存区域和内存模型是不通的概念。

这里面记住两地，一是堆和方法区是共享的，所谓共享就是能在不通线程中看到，当然也是GC优化的主要对象；二是局部变量存在栈中，一般我们说的栈指虚拟机栈，就是java自己的一套，本地方法栈保存的则是C++写的方法使用的栈。

具体来说，方法区存这些数据：类信息、常量、static 、JIT；Java堆区存：实例对象；虚拟机栈存：局部变量。程序计数器：java线程的私有数据，这个数据就是执行下一条指令的地址；

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMDU5NjEx_size_16_color_FFFFFF_t_70][]

下左图说明了堆与栈之间的数据交互，右图说明了内存、cache与cpu之间的交互（实际上右图可以进行细化）：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMDU5NjEx_size_16_color_FFFFFF_t_70 1][]

细化后的内存与cpu之间的数据交互如下图所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMDU5NjEx_size_16_color_FFFFFF_t_70 2][]

cache一般有三级，通过多级cache解决内存与cpu处理速度不一致问题，提升吞吐量。cpu中也有一块存储哦，叫寄存器！

## 4，java内存模型（JMM） ##

有了前面的铺垫，接下来就可以看看JMM是什么样子的了：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMDU5NjEx_size_16_color_FFFFFF_t_70 3][]![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMDU5NjEx_size_16_color_FFFFFF_t_70 4][]

左右两图是一个意思，注意哦这里的内存不是内存条的那个内存！

说明一下几个区域的内容及工作方式：

（1）主内存：共享的信息；

（2）工作内存：私有信息，基本数据类型，直接分配到工作内存，引用的地址存放在工作内存，引用的对象存放在堆中。对应vm stack，vm stack可以设置；

（3）工作方式：

A  线程修改私有数据，直接在工作空间修改

B  线程修改共享数据，把数据复制到工作空间中去，在工作空间中修改，修改完成以后，刷新内存中的数据

线程里的不论stack还是heap的存储空间都涵盖了CPU registers、cache和main Memory！也就是说工作空间和内存（左图）对应的物理存储，包括了CPU registers、cache和main Memory，而JMM为概念模型！下图描述了这种对应关系：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMDU5NjEx_size_16_color_FFFFFF_t_70 5][]

这个模型很重要，并发的很多原理都基于这个模型！根据这个模型，可以发现存在CPU缓存的一致性问题，并发处理不一致，即多个线程读入和写入主内存的数据可能不一致，最终造成错误。

如何解决这类一致性问题？

（1）总线加锁（操作系统提供了总线锁定的机制）  降低CPU的吞吐量

（2）缓存上的一致性协议（MESI）：缓存一致性机制就整体来说，是当某块CPU对缓存中的数据进行操作了之后，就通知其他CPU放弃储存在它们内部的缓存，或者从主内存中重新读取。

当CPU在CACHE中操作数据时，如果该数据是共享变量，数据在CACHE读到寄存器中，进行新修改，并更新内存数据；CaCHE  LINE置无效，其他的CPU就从内存中读数据。

具体原理参加[https://blog.csdn.net/qq\_22059611/article/details/93625503][https_blog.csdn.net_qq_22059611_article_details_93625503]

java内存模型主要用于规范内存数据和工作空间数据的交互。

## 5，并发编程的三个重要特性 ##

原子性：不可分割  x=1（synchronize改变原子性）

可见性：线程只能操作自己工作空间中的数据。（volatile改变可见性）

有序性：程序中的顺序不一定就是执行的顺序（虚拟机的重排序，volatile可保证有序性）

有两种重排序：编译重排序、指令重排序

但是重排序遵守下列规则：

as-if-serial:单线程中重排后不影响执行的结果，多线程则不一定。

happens-before用来阐述内存可见性：两个操作之间具有happens-before关系，并不意味着前一个操作必须要在后一个操作之前执行！happens-before仅仅要求前一个操作（执行的结果）对后一个操作可见，且前一个操作按顺序排在第二个操作之前

参考：[https://blog.csdn.net/u010571316/article/details/64906481][https_blog.csdn.net_u010571316_article_details_64906481]

JMM如何保证三大特征？

（1）JMM与原子性

比如（a）X=1 具有原子性；（b）y=x 没有原子性，因为这个操作包含两个步骤，一是把x读到工作空间，二是把值写入y，这两项单独是有原子性，但是合在一起就没有原子性了；（c）i++同样没有原子性；（d）z=z+1没有原子性。

那么如何保证一段操作具有原子性？——采用synchronized、JUC（java.util.concurent）中的Lock

（2）JMM与可见性

可见性指线程只能看到自己工作空间的数据，其他线程工作空间的数据看不到；如果要互相可见，采用volatile，则可实现，即均从内存中读，一旦有更新刷新到内存，后续会详述volatile关键字。

（3）JMM与有序性

采用synchronized和volatile均可实现，后续会详述这两个关键字。

Happens-before原则：  
1）程序次序原则  
2）锁定原则  ：后一次加锁必须等前一次解锁  
3）Volatile原则：霸道原则  
4）传递原则：A---B ---C    A--C

附录，内存的相关操作及并发的优劣势

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMDU5NjEx_size_16_color_FFFFFF_t_70 6][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMDU5NjEx_size_16_color_FFFFFF_t_70 7][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMDU5NjEx_size_16_color_FFFFFF_t_70 8][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMDU5NjEx_size_16_color_FFFFFF_t_70 9][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMDU5NjEx_size_16_color_FFFFFF_t_70]: /images/20211211/0068cd3ab66b4a9f8bd0a39d01a6959e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMDU5NjEx_size_16_color_FFFFFF_t_70 1]: /images/20211211/a17b57db189d4441bea6758532cde30c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMDU5NjEx_size_16_color_FFFFFF_t_70 2]: /images/20211211/689db2586c97425d8e028df344f1d114.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMDU5NjEx_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20191202102011756.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMDU5NjEx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMDU5NjEx_size_16_color_FFFFFF_t_70 4]: /images/20211211/896581a42ebf4699934bafd286cc3daa.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMDU5NjEx_size_16_color_FFFFFF_t_70 5]: /images/20211211/7dc6b0d4fa2d456ba6afd16a92263d83.png
[https_blog.csdn.net_qq_22059611_article_details_93625503]: https://blog.csdn.net/qq_22059611/article/details/93625503
[https_blog.csdn.net_u010571316_article_details_64906481]: https://blog.csdn.net/u010571316/article/details/64906481
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMDU5NjEx_size_16_color_FFFFFF_t_70 6]: /images/20211211/d2bbc264a521456f95afaf0b97e2b10a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMDU5NjEx_size_16_color_FFFFFF_t_70 7]: /images/20211211/6ee93ea32f2c4cb7a151c9adbeb4acfd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMDU5NjEx_size_16_color_FFFFFF_t_70 8]: /images/20211211/495a693b67f347e6bac6f3c81db4c149.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMDU5NjEx_size_16_color_FFFFFF_t_70 9]: /images/20211211/ca68de20d4cc436fb1135928185d08b3.png