JAVA内存模型

Posted on | In , | | 浏览 次
Words count in article: 4.9k | Reading time ≈ 17

前言

Java作为一种面向对象的，跨平台语言，其对象、内存等一直是比较难的知识点。而且很多概念的名称看起来又那么相似，很多人会傻傻分不清楚。比如本文我们要讨论的JVM内存结构、Java内存模型和Java对象模型，这就是三个截然不同的概念，但是很多人容易弄混。

简单来说，他们的概念如下：

  • 内存结构：
    • 虚拟机在执行Java程序的过程中会把所管理的内存划分为若干个不同的数据区域，如堆、栈，寄存器，方法区，本地常量池等。这些区域都有各自的用途。
  • 内存模型：
    • Java内存模型看上去和Java内存结构（JVM内存结构）相似，很多人会误以为两者是一回事儿，但他们不是一个概念；
    • Java内存模型是根据英文Java Memory Model（JMM）翻译过来的。其实JMM并不像JVM内存结构一样是真实存在的。他只是一个抽象的概念。
    • JMM是一种规范，目的是解决由于多线程通过共享内存进行通信时，存在的本地内存数据不一致、编译器会对代码指令重排序、处理器会对代码乱序执行等带来的问题。并定义了一些语法集，这些语法集映射到Java语言中就是volatile、synchronized等关键字。
  • 对象模型：
    • Java是一种面向对象的语言，而Java对象在JVM中的存储也是有一定的结构的。而这个关于Java对象自身的存储模型称之为Java对象模型。
    • HotSpot虚拟机中，设计了一个OOP-Klass模型。OOP（Ordinary Object Pointer）指的是普通对象指针，而Klass用来描述对象实例的具体类型。

JVM内存结构，和Java虚拟机的运行时区域有关。
Java内存模型，和Java的并发编程有关。
Java对象模型，和Java对象在虚拟机中的表现形式有关。

1 计算机的内存模型

前言部分为了区别jvm内存模型，内存结构和对象模型，给出了三者的简单定义，现在我们来好好聊一聊java的内存模型。其实要了解java的内存模型，我们得从计算机的内存模型说起；

1.1 CPU

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

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

为了不让内存成为计算机处理的瓶颈，人们想出来了一个好的办法，就是在CPU和内存之间增加高速缓存。缓存的概念大家都知道，就是保存一份数据拷贝。他的特点是速度快，内存小，并且昂贵。于是程序的执行过程就变成了：

当程序在运行过程中，会将运算需要的数据从主存复制一份到CPU的高速缓存当中，那么CPU进行计算时就可以直接从它的高速缓存读取数据和向其中写入数据，当运算结束之后，再将高速缓存中的数据刷新到主存当中。

1.2 多级缓存

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

按照数据读取顺序和与CPU结合的紧密程度，CPU缓存可以分为一级缓存（L1），二级缓存（L2），部分高端CPU还具有三级缓存（L3），每一级缓存中所储存的全部数据都是下一级缓存的一部分。这三种缓存的技术难度和制造成本是相对递减的，所以其容量也是相对递增的。

那么，在有了多级缓存之后，程序的执行就变成了：

当CPU要读取一个数据时，首先从一级缓存中查找，如果没有找到再从二级缓存中查找，如果还是没有就从三级缓存或内存中查找。

单核CPU只含有一套L1，L2，L3缓存；如果CPU含有多个核心，即多核CPU，则每个核心都含有一套L1（甚至和L2）缓存，而共享L3（或者和L2）缓存。

1.3 缓存一致性问题

随着计算机能力不断提升，开始支持多线程。那么问题就来了。我们分别来分析下单线程、多线程在单核CPU、多核CPU中的影响。

  • 单线程
    • cpu核心的缓存只被一个线程访问。缓存独占，不会出现访问冲突等问题。
  • 单核CPU，多线程
    • 进程中的多个线程会同时访问进程中的共享数据，CPU将某块内存加载到缓存后，不同线程在访问相同的物理地址的时候，都会映射到相同的缓存位置，这样即使发生线程的切换，缓存仍然不会失效。但由于任何时刻只能有一个线程在执行，因此不会出现缓存访问冲突。
  • 多核CPU，多线程
    • 每个核都至少有一个L1 缓存。多个线程访问进程中的某个共享内存，且这多个线程分别在不同的核心上执行，则每个核心都会在各自的caehe中保留一份共享内存的缓冲。由于多核是可以并行的，可能会出现多个线程同时写各自的缓存的情况，而各自的cache之间的数据就有可能不同。

在CPU和主存之间增加缓存，在多线程场景下就可能存在缓存一致性问题，也就是说，在多核CPU中，每个核的自己的缓存中，关于同一个数据的缓存内容可能不一致。

1.4 MESI协议

MESI（Modified Exclusive Shared Or Invalid）(也称为伊利诺斯协议，是因为该协议由伊利诺斯州立大学提出）是一种广泛使用的支持写回策略的缓存一致性协议。奔腾处理器有使用它，很多其他的处理器都是使用它的变种。该协议使用了cache line的四种状态的首字母来命名。

1.4.1 缓存行状态

单核Cache中每个Cache line有2个标志：dirty和valid标志，它们很好的描述了Cache和Memory(内存)之间的数据关系(数据是否有效，数据是否被修改)，而在多核处理器中，多个核会共享一些数据，MESI协议就包含了描述共享的状态。

多核处理器中，CPU中每个缓存行（caceh line)使用4种状态进行标记（使用两个bit表示):

  • M: 被修改（Modified)

    • 表示这行数据有效，但数据在当前工作内存被修改了，和主内存中的数据不一致，改后的数据目前只存在于该cpu的Cache中。
    • 一个处于M状态的缓存行，必须时刻监听所有试图读取该缓存行对应的主存地址的操作，如果监听到，则必须在此操作执行前把其缓存行中的数据写回主内存。
    • 图示如下图：Core 0修改了x的值之后，这个Cache line变成了M(Modified)状态，其他Core对应的Cache line变成了I(Invalid)状态。

  • E: 独享的（Exclusive)

    • 表示这行数据有效，数据和主内存中的数据一致，并且数据只存在于该cpu的Cache中，其他cpu没有缓存该数据。
    • 一个处于E状态的缓存行，必须时刻监听其他试图读取该缓存行对应的主存地址的操作，如果监听到，则必须把其缓存行状态设置为S。
    • 图示如下图：只有Core 0访问变量x，它的Cache line状态为E(Exclusive)。

  • S: 共享的（Shared)

    • 表示这行数据有效，数据和内存中的数据一致，且数据存在于很多cpu的Cache中。
    • 一个处于S状态的缓存行，必须时刻监听使该缓存行无效或者独享该缓存行的请求，如果监听到，则必须把其缓存行状态设置为I。
    • 图示如下图：多个Core都访问变量x，它们对应的Cache line为S(Shared)状态。

  • I: 无效的（Invalid）

    • 表示这行数据无效
    • 当CPU需要读取数据时，如果其缓存行的状态是I的，则需要从内存中读取，并把自己状态变成S，如果不是I，则可以直接读取缓存中的值，但在此之前，必须要等待其他CPU的监听结果，如其他CPU也有该数据的缓存且状态是M，则需要等待其把缓存更新到内存之后，再读取。

M(Modified)和E(Exclusive)状态的Cache line，数据是独有的，不同点在于M状态的数据是dirty的(和内存的不一致)，E状态的数据是clean的(和内存的一致)。

当CPU需要写数据时，只有在其缓存行是M或者E的时候才能执行，否则需要发出特殊的RFO指令(Read Or Ownership，这是一种总线事务)，通知其他CPU置缓存无效(I)，这种情况下会性能开销是相对较大的。在写入完成后，修改其缓存状态为M。

上面是不是比较难理解呢？没关系，我们说人话：

  • 假如当前有一个cpu A去主内存拿到一个变量x的值初始为1，放到自己的工作内存中。此时它的状态就是独享状态E

  • 然后此时另外一个cpu B也拿到了这个x的值，放到自己的工作内存中。此时之前那个cpu A会不断地监听内存总线，发现这个x有多个cpu在获取，那么这个时候这两个cpu所获得的x的值的状态就都是共享状态S。

  • 然后第一个cpu A将自己工作内存中x的值带入到自己的ALU计算单元去进行计算，返回来x的值变为2，接着会告诉给内存总线，将此时自己的x的状态置为修改状态M。

  • 而另一个cpu B此时也会去不断的监听内存总线，发现这个x已经有别的cpu将其置为了修改状态，所以自己内部的x的状态会被置为无效状态I，等待第一个cpu A将修改后的值刷回到主内存后，重新去获取新的值。

  • 这个谁先改变x的值可能是同一时刻进行修改的，此时cpu就会通过底层硬件在同一个指令周期内进行裁决，裁决是谁进行修改的，就置为修改状态，而另一个就置为无效状态。

当然，MESI也会有失效的时候，缓存的最小单元是缓存行，如果当前的共享数据的长度超过一个缓存行的长度的时候，就会使MESI协议失败，此时的话就会触发总线加锁的机制，第一个线程cpu拿到这个x的时候，其他的线程都不允许去获取这个x的值。

1.4.2 缓存行状态迁移

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

其中：

  • Local Read
    • 表示cpu读自己的Cache中的值
  • Local Write
    • 表示cpu写自己Cache中的值 Remote Read
    • 表示其它cpu读其它Cache中的值
  • Remote Write
    • 表示其它cpu写其它Cache中的值

具体的过程是：

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则不能。

1.5 处理器优化和指令重排

上面提到在在CPU和主存之间增加缓存，在多线程场景下会存在缓存一致性问题。除了这种情况，还有一种硬件问题也比较重要。那就是为了使处理器内部的运算单元能够尽量的被充分利用，处理器可能会对输入代码进行乱序执行处理。这就是处理器优化。

除了现在很多流行的处理器会对代码进行优化乱序处理，很多编程语言的编译器也会有类似的优化，比如Java虚拟机的即时编译器（JIT）也会做指令重排。

可想而知，如果任由处理器优化和编译器对指令重排的话，就可能导致各种各样的问题。

2 java内存模型

2.1 java内存模型的意义

前面说的和硬件有关的概念你可能听得有点蒙，还不知道他到底和软件有啥关系。但是关于并发编程的问题你应该有所了解，比如原子性问题，可见性问题和有序性问题。

其实，原子性问题，可见性问题和有序性问题。是人们抽象定义出来的。而这个抽象的底层问题就是前面提到的缓存一致性问题、处理器优化问题和指令重排问题等。

  • 原子性

    • 是指在一个操作中，cpu不可以在中途暂停然后再调度，既不被中断操作，要不执行完成，要不就不执行。

  • 可见性

    • 是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。

  • 有序性

    • 即程序执行的顺序按照代码的先后顺序执行。

我们发现，缓存一致性问题其实就是可见性问题。而处理器优化则可能会导致原子性问题。指令重排即会导致有序性问题。那么，有没有什么机制可以很好的解决上面的这些问题呢？

为了保证并发编程中可以满足原子性、可见性及有序性。所以需引入一个重要的概念，那就是——内存模型。

2.2 Java内存模型的概念

前面介绍过了计算机内存模型，这是解决多线程场景下并发问题的一个重要规范。那么具体的实现是如何的呢，不同的编程语言，在实现上可能有所不同。

我们知道，Java程序是需要运行在Java虚拟机上面的，Java内存模型（Java Memory Model ,JMM）就是一种符合内存模型规范的，屏蔽了各种硬件和操作系统的访问差异的，保证了Java程序在各种平台下对内存的访问都能保证效果一致的机制及规范。

它规定了：

  1. 所有的变量都存储在主内存中。这是共享数据。
  2. 每条线程还有自己的工作内存，线程的工作内存中保存了该线程中用到的变量的主内存副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存。
  3. 不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量的传递均需要自己的工作内存和主存之间进行数据同步进行。

而JMM就作用于工作内存和主存之间数据同步过程。他规定了如何做数据同步以及什么时候做数据同步。

在JVM的内存模型中，每个线程有自己的工作内存，实际上JAVA线程借助了底层操作系统线程实现，一个JVM线程对应一个操作系统线程，线程的工作内存其实是cpu寄存器和高速缓存的抽象。

3 Java内存模型的实现

了解Java多线程的朋友都知道，在Java中提供了一系列和并发处理相关的关键字，比如volatile、synchronized、final、concurren包等。其实这些就是Java内存模型封装了底层的实现后提供给程序员使用的一些关键字。

在开发多线程的代码的时候，我们可以直接使用synchronized等关键字来控制并发，从来就不需要关心底层的编译器优化、缓存一致性等问题。所以，Java内存模型，除了定义了一套规范，还提供了一系列原语，封装了底层实现后，供开发者直接使用。

3.1 原子性

在Java中，为了保证原子性，提供了两个高级的字节码指令monitorenter和monitorexit。在synchronized原理和锁优化策略(偏向/轻量级/重量级)中我们介绍过，这两个字节码，在Java中对应的关键字就是synchronized。

3.2 可见性

Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值的这种依赖主内存作为传递媒介的方式来实现的。

Java中的volatile关键字提供了一个功能，那就是被其修饰的变量在被修改后可以立即同步到主内存，被其修饰的变量在每次是用之前都从主内存刷新。因此，可以使用volatile来保证多线程操作时变量的可见性。

除了volatile，Java中的synchronized和final两个关键字也可以实现可见性。只不过实现方式不同。

3.3 有序性

在Java中，可以使用synchronized和volatile来保证多线程之间操作的有序性。实现方式有所区别：

volatile关键字会禁止指令重排。synchronized关键字保证同一时刻只允许一条线程操作。

3.4 总结

好了，这里简单的介绍完了Java并发编程中解决原子性、可见性以及有序性可以使用的关键字。读者可能发现了，好像synchronized关键字是万能的，他可以同时满足以上三种特性，这其实也是很多人滥用synchronized的原因。

但是synchronized是比较影响性能的，虽然编译器提供了很多锁优化技术，但是也不建议过度使用。

参考资料

再有人问你Java内存模型是什么，就把这篇文章发给他。

《大话处理器》Cache一致性协议之MESI

0%