死磕java同步系列之JMM (java内存模型)

  

简介

  

Java内存模型是在硬件内存模型上的更高层的抽象,它屏蔽了各种硬件和操作系统访问的差异性,保证了Java程序在各种平台下对内存的访问都能达到一致的效果。

  

硬件内存模型

  

在正式讲解Java的内存模型之前,我们有必要先了解一下硬件层面的一些东西。

  

在现代计算机的硬件体系中,CPU的运算速度是非常快的,远远高于它从存储介质读取数据的速度,这里的存储介质有很多,比如磁盘,光盘,网卡,内存等,这些存储介质有一个很明显的特点,距离CPU越近的存储介质往往越小越贵越快,距离CPU越远的存储介质往往越大越便宜越慢。

  

所以,在程序运行的过程中,CPU大部分时间都浪费在了磁盘IO,网络通讯,数据库访问上,如果不想让CPU在那里白白等待,我们就必须想办法去把CPU的运算能力压榨出来,否则就会造成很大的浪费,而让CPU同时去处理多项任务则是最容易想到的,也是被证明非常有效的压榨手段,这也就是我们常说的“并发执行”。

  

但是,让CPU并发地执行多项任务并不是那么容易实现的事,因为所有的运算都不可能只依靠CPU的计算就能完成,往往还需要跟内存进行交互,如读取运算数据,存储运算结果等。

  

前面我们也说过了,CPU与内存的交互往往是很慢的,所以这就要求我们要想办法在CPU和内存之间建立一种连接,使它们达到一种平衡,让运算能快速地进行,而这种连接就是我们常说的“高速缓存”。

  

高速缓存的速度是非常接近CPU的,但是它的引入又带来了新的问题,现代的CPU往往是有多个核心的,每个核心都有自己的缓存,而多个核心之间是不存在时间片的竞争的,它们可以并行地执行,那么,怎么保证这些缓存与主内存中的数据的一致性就成为了一个难题。

  

为了解决缓存一致性的问题,多个核心在访问缓存时要遵循一些协议,在读写操作时根据协议来操作,这些协议有MSI, MESI,莫西人等,它们定义了何时应该访问缓存中的数据,何时应该让缓存失效,何时应该访问主内存中的数据等基本原则。

  

死磕java同步系列之JMM (java内存模型)

  

而随着CPU能力的不断提升,一层缓存就无法满足要求了,就逐渐衍生出了多级缓存。

  

按照数据读取顺序和CPU的紧密程度,CPU的缓存可以分为一级缓存(L1),二级缓存(L2),三级缓存(L3),每一级缓存存储的数据都是下一级的一部分。

  

这三种缓存的技术难度和制作成本是相对递减的,容量也是相对递增的。

  

所以,在有了多级缓存后,程序的运行就变成了:

  

当CPU要读取一个数据的时候,先从一级缓存中查找,如果没找到再从二级缓存中查找,如果没找到再从三级缓存中查找,如果没找到再从主内存中查找,然后再把找到的数据依次加载到多级缓存中,下次再使用相关的数据直接从缓存中查找即可。

  

而加载到缓存中的数据也不是说用到哪个就加载哪个,而是加载内存中连续的数据,一般来说是加载连续的64个字节,因此,如果访问一个长类型的数组时,当数组中的一个值被加载到缓存中时,另外7个元素也会被加载到缓存中,这就是“缓存行”的概念。

  

死磕java同步系列之JMM (java内存模型)

  

缓存行虽然能极大地提高程序运行的效率,但是在多线程对共享变量的访问过程中又带来了新的问题,也就是非常著名的“伪共享”。

  

关于伪共享的问题,我们这里就不展开讲了,有兴趣的可以看彤哥之前发布的【杂谈什么是伪共享(假共享)?】章节的相关内容。

  

除此之外,为了使CPU中的运算单元能够充分地被利用,CPU可能会对输入的代码进行乱序执行优化,然后在计算之后再将乱序执行的结果进行重组,保证该结果与顺序执行的结果一致,但并不保证程序中各个语句计算的先后顺序与代码的输入顺序一致,因此,如果一个计算任务依赖于另一个计算任务的结果,那么其顺序性并不能靠代码的先后顺序来保证。

  

与CPU的乱序执行优化类似,java虚拟机的即时编译器也有类似的指令重排序优化。

  

为了解决上面提到的多个缓存读写一致性以及乱序排序优化的问题,这就有了内存模型,它定义了共享内存系统中多线程读写操作行为的规范。

  

Java内存模型

死磕java同步系列之JMM (java内存模型)