多核硬件架构,看Java内存模型

网友投稿 700 2022-05-29

在了解Java内存模型之前,先来看一下多核硬件架构。

我们应该都知道,计算机在执行程序的时候,每条指令都是在CPU中执行的,而执行的时候,又免不了要和数据打交道。而计算机上面的数据,是存放在主存当中的,也就是计算机的物理内存啦。

刚开始,还相安无事的,但是随着CPU技术的发展,CPU的执行速度越来越快。而由于内存的技术并没有太大的变化,所以从内存中读取和写入数据的过程和CPU的执行速度比起来差距就会越来越大,这就导致CPU每次操作内存都要耗费很多等待时间。

所以,人们想出来了一个好的办法,就是在CPU和内存之间增加高速缓存。缓存的概念大家都知道,就是保存一份数据拷贝。他的特点是速度快,内存小,并且昂贵。

再随着市场对CPU计算能力的需要,于是出现了多核CPU,每个核都有各自的缓存。下图简单描述了多核硬件架构的实现。

现代计算机硬件,几乎都是多核处理器实现。打开Windows的任务管理器,可以核心数,还可以看到处理器的缓存。如下图红框:

可以清晰的看到L1、L2、L3三级缓存。

计算机内部的缓存架构(CPU三级缓存)

从多核硬件架构,看Java内存模型

缓存大大缩小了高速CPU与低速内存之间的差距。以三层缓存架构为例:

L1 Cache最接近CPU, 容量最小(如32K、64K、256K等)、速度最高,每个核上都有一个L1 Cache。

L2 Cache容量更大(如256K)、速度更低, 一般情况下,每个核上都有一个独立的L2 Cache。

L3 Cache最接近内存,容量最大(如12MB),速度最低,在同一个CPU插槽之间的核共享一个L3 Cache。

单核时代只有一个处理器核心,读/写操作完全都是由单核完成,没什么问题;但是多核架构,一个核修改主存后,其他核心并不知道数据已经失效,继续傻傻的使用,轻则数据计算错误,重则导致死循环、程序崩溃等。

缓存一致性协议

多核CPU硬件架构厂商,设计之初就预测到多线程操作数据不一致的问题,因此出现了——缓存一致性协议。

不同的CPU硬件生产厂商,具体的实现不一样。Intel的MESI协议最出名。

MESI协议文档:https://en.wikipedia.org/wiki/MESI_protocol

在MESI协议中,每个Cache line有4个状态,可用2个bit表示,它们分别是:

状态 描述

M(Modified) 这行数据有效,数据被修改了,和内存中的数据不一致,数据只存在于本Cache中。

E(Exclusive) 这行数据有效,数据和内存中的数据一致,数据只存在于本Cache中。

S(Shared) 这行数据有效,数据和内存中的数据一致,数据存在于很多Cache中。

I(Invalid) 这行数据无效。

在MESI协议中,每个Cache的Cache控制器不仅知道自己的读写操作,而且也监听(snoop)其它Cache的读写操作。每个Cache line所处的状态根据本核和其它核的读写操作在4个状态间进行迁移,如下图:

AMD的Opteron处理器使用从MESI中演化出的MOESI协议,O(Owned)是MESI中S和M的一个合体,表示本Cache line被修改,和内存中的数据不一致,不过其它的核可以有这份数据的拷贝,状态为S。

Intel的core i7处理器使用从MESI中演化出的MESIF协议,F(Forward)从Share中演化而来,一个Cache line如果是Forward状态,它可以把数据直接传给其它内核的Cache,而Share则不能。

用下面的简图,简单说明下MESI如何在多核环境,确保缓存一致性的。

两个CPU执行两个线程,都执行count++,都先从主内存获取count=0,都将count=0从主存拷贝到各自的缓存区,且在缓存区count=0的状态为S(Shared,多线程共享状态)。

一个线程(左边的线程)先执行了修改count+=1,按MESI缓存协议规范,在该线程中count是M状态(即:已被修改),则其他拥有count变量的线程,count状态都变为(I)失效状态,即需要再去主内存拿新值。

可见,缓存一致性协议解决了多核硬件架构的一致性问题。那缓存一致性又和JMM有什么关系呢?

JMM也是遵照多核硬件架构的设计,用Java实现了一套JVM层面的“缓存一致性”。

如果开发者运用的得当,最终可以达到Java线程间:变量可见性、有序性、原子性。

有了MESI,为什么还需要JMM?

既然有了MESI协议,是不是就不需要volatile的可见性语义了?当然不是,还有以下问题:

并不是所有的硬件架构都提供了相同的一致性保证,不同的硬件厂商实现不同,JVM需要volatile统一语义。

可见性问题不仅仅局限于CPU缓存内,JVM自己维护的内存模型(JMM)中也有可见性问题。使用volatile做标记,可以解决JVM层面的可见性问题。

Java内存模型JMM

Java内存模型(Java Memory Model,简称JMM),本身是种抽象的概念,并不是像硬件架构一样真实存在的;它描述的是一组规则或规范,通过这组规范定义了程序中各个变量(包括实例字段、静态字段和构成数组对象的元素)的访问方式。

由于JVM运行程序的实体是线程,而每个线程创建时,JVM都会为其创建一个工作内存(有些地方称为栈空间),用于存储线程私有数据,而Java内存模型中规定所有变量都存储在主内存,主内存时关系内存区域,所有线程都可以访问,但线程对变量的操作(读取赋值等)必须在工作内存中进行,首先要将变量从主内存拷贝到自己的工作内存空间,然后对变量进行操作,操作完后再将变量写回主内存,不能直接操作主内存中的变量。

工作内存是每个线程的私有数据区域,因此不同线程间无法访问对方的工作内存,线程间的通信(传值)必须通过主内存来完成。如下图所示:

内存模型JMM与Java运行时数据区的关系

Java虚拟机的运行时数据区被划分为:方法区、Java堆、Java虚拟机栈、PC寄存器、本地方法栈,还有常量池。它们被分为两大类——线程共享和线程私有数据区。

线程共享数据区,包括:Java堆、方法区、常量池。它们会随着虚拟机启动而创建,随着虚拟机退出而销毁。

线程私有数据区,包括:PC寄存器、JVM栈、本地方法区。它们是与线程一一对应的,这些与线程对应的数据区域会随着线程开始和结束而创建和销毁。详细了解可阅读:JVM体系结构-----深入理解内存结构

本质上来说,内存模型JMM和Java运行时数据区没有任何关系,它们是两个不同纬度的东西。

但如果硬要扯上关系的话,可以把Java运行时数据区的JVM栈 看作是内存模型中的"工作内存",因为按Java运行时数据区对内存的划分,符合线程私有性质、且存储本地变量的存储区域,只有线程私有的栈空间。

JMM主内存与工作内存的数据存储类型以及操作方式

根据虚拟机规范,对于一个实例对象中的成员方法而言

1、如果方法中包含本地变量是基本数据类型,将直接存储在工作内存(栈)中;

2、但如果本地变量是引用类型,那么该变量的引用会存储在工作内存的栈中,而对象的实例将存储在主内存(堆)中。但对于实例对象的成员变量,不管它是基本数据类型或者包装类型(Integer、Double等)还是引用类型,都会被存储到堆区。

3、至于static变量以及类自身相关信息将会存储在主内存中。

需要注意的是,在主内存中的实例对象可以被多线程共享,如果两个线程同时调用了同一个对象的同一个方法,那么两个线程会将 要操作的数据拷贝一份到自己的工作内存中,执行完成后才刷新到主内存,如下图所示:

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

对于硬件架构来说,只有寄存器、缓存、主内存的概念,并没有工作内存(线程私有数据区)和主内存(堆内存)之分,也就是说Java内存模型对内存的划分对硬件内存并没有任何影响,因为JMM是一种抽象的概念,是一组规则,并不实际存在,不管是工作内存的数据还是主内存的数据,对于计算机硬件来说都会存储在计算机主内存中,当然也有可能存储到CPU缓存或者寄存器中,因此总体上,Java内存模型和硬件内存架构师一个相互交叉的关系,是一种抽象概念划分与真实物理硬件的交叉。(注意对于Java内存区域划分也是同样的道理)

小结:

1、硬件架构的缓存一致性协议(如MESI),解决了多核硬件的一致性问题。

JMM也是遵照多核硬件架构的设计,用Java实现了一套JVM层面的“缓存一致性”。

如果开发者运用的得当,最终可以达到Java线程间:内存可见性、有序性、原子性。

2、JMM不像硬件架构,不是实实在在存在的,JMM是理论基础。但JMM最终还是要落到硬件架构上去运行。

存档文章

终于有人把Java内存模型(JMM)说清楚了

JVM体系结构-----深入理解内存结构

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:程序员,不要说你这些快捷键你都知道.
下一篇:PHP蜘蛛爬虫开发文档
相关文章