[转] Java 内存模型

DEDEZHANG
115 阅读13分钟

JMM —— Java 内存模型

Java 内存模型

Java 内存模型即 Java Memory Model，简称 JMM。

「内存模型」可以理解为在特定操作协议下，对特定的内存或高速缓存进行读写访问的过程抽象。

不同架构的物理计算机可以有不一样的内存模型，Java虚拟机也有自己的内存模型。

Java虚拟机规范中试图定义一种「 Java 内存模型」来屏蔽掉各种硬件和操作系统的内存访问差异，以实现让 Java 程序在各种平台下都能达到一致的内存访问效果，不必因为不同平台上的物理机的内存模型的差异，对各平台定制化开发程序。

Java 内存模型的主要目标是定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。这里的变量与我们写 Java 代码中的变量不同，它包括了实例字段、静态字段和构成数组对象的元素，但不包括局部变量和方法参数，因为他们是线程私有的，不会被共享。

JMM 组成

  • 主内存：Java 内存模型规定了所有变量都存储在主内存( Main Memory ) 中，（此处的主内存与物理硬件的主内存 RAM 名字一样，两者可以互相类比，但此处仅是虚拟机内存的一部分）

  • 工作内存：每条线程都有自己的工作内存( Working Memort , 又称本地内存，可与 CPU 高速缓存类比)，线程的工作内存中保存了该线程使用到的主内存中的共享变量的副本拷贝。线程对变量的所有操作都必须在工作内存进行，而不能直接读写主内存中的变量。工作内存是 JMM 的一个抽象概念，并不真实存在。

    img

JMM 与 JVM 内存结构

​ JMM 与 Java 内存区域中的堆、栈、方法区等并不是同一个层次的内存划分，两者基本没有关系。如果一定要勉强对应，那从变量、主内存、工作内存的定义看，主内存主要对应 Java 堆中的对象实例数据部分，工作内存则对应虚拟机栈的部分区域。

img

JMM 与计算机内存结构

​ Java 内存模型和硬件内存体系结构也没有都很么关系。硬件内存体系结构不区分堆和栈。在硬件上，线程堆和栈都位于主内存中。线程栈和堆的一部分有时可能出现在高速缓存和 CPU 寄存器中。如下图所示：

img

当对象和变量都可以存储在计算机中不同的内存区域时，这就可能会出现某些问题。两个主要问题是：

  • 线程更新（写）到共享变量的可见性
  • 读取、检查和写入共享变量时的竞争条件

可见性问题

​ 如果两个或多个线程共享一个对象，则一个线程对共享对象的更新可能对其他线程不可见（当然可以用 Java 提供的关键字 volatile ）。假设共享对象最初存储在主内存中。在 CPU 1 上运行的线程将共享对象读入它的 CPU 缓存后修改，但是还没来得及刷新回主内存，这时其他 CPU 上运行的线程就不会看到共享对象的更改。这样，每个线程都可能以自己的线程结束，就会出现可见性问题，如下：

img

竞争条件

​ 这个其实就是我们常说的原子问题。

​ 如果两个或多个线程共享一个对象，并且多个线程更新该共享对象中的变量，则可能出现竞争条件。

​ 想象一下，如果线程 A 将一个共享对象的变量读入到它的 CPU 缓存中。此时，线程 B 执行相同的操作，但是进入不同的 CPU 缓存。现在线程 A 执行 +1 操作，线程 B 也这样做。现在该变量增加了两次，在每个 CPU 缓存中一次。

​ 如果这些增量 时按顺序执行的，则变量结果会是 3，并将原始值 +2 写回主内存。但是，这两个增量是同时执行的，没有适当的同步。不管将哪个线程的结果写回主内存，更新后的值只会比原始值高 1，显然是有问题的，如下（当然可以用 Java 提供的关键字 Synchronized ）

img

JMM 特性

​ JMM 就是用来解决如上问题的。JMM 是围绕着并发过程中如何处理可见性、原子性、和有序性这 3 个特性建立起来的

  • 可见性：可见性是指当一个线程修改了共享变量的值，其他线程能够立即得知这个修改。Java 中的 volatile 、synchronzied 、final 都可以实现可见性

  • 原子性：即一个操作或者多个操作，要么全部执行并且执行的过程不会被任何因素打断，要么都不执行。即使多个线程一起执行的时候，一个操作一旦开始，就不会被其他线程所干扰

  • 有序性：计算机在执行程序时，为了提高性能，编译器和处理器常常会对指令做重排，一般分为以下三种：

    img

    • 单线程环境里确保程序最终执行结果和代码顺序执行的结果一致

    • 处理器在进行重排序时必须要考虑指令之间的数据依赖性

    • 多线程环境中线程交替执行，由于编译器优化重排的结果，两个线程使用的变量能否保证一致性是无法确定的，结果无法预测

内存之间的交互操作

内存之间的交互操作

​ 关于主内存和工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存之间的实现细节，Java 内存模型中定义了 8 种操作来完成，虚拟机实现必须保证每一种操作都是原子性的、不可再拆分的（double 和 long 类型例外）

  • lock (锁)：作用于主内存的变量，它把一个变量标识为一条线程独占的状态

  • unlock(解锁)：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定

  • read(读取)：作用于主内存的变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的 load 动作使用

  • load(载入)：作用于工作内存的变量，它把 read 操作从主内存中得到的变量放入工作内存的变量副本中

  • use(使用)：作用于工作内存的变量，它把工作内存中一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用到变量的值的字节码指令时将会执行这个操作

  • assign(赋值)：作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作

  • store(存储)：作用于工作内存的变量，它把工作内存中一个变量的值传送到主内存中，以便随后的 write 操作使用

  • write(写入)：作用于主内存中的变量，它把 store 操作从工作内存中得到的变量的值放到主内存的变量中

    ​ 由此可见，如果需要把一个变量从主内存复制到工作内存，那就要顺序地执行 read 和 load 操作，如果要把变量从工作内存同步回主内存，就要顺序地执行 store 和 write 操作。注意，Java 内存模型只要求上述两个操作必须按顺序执行，而没有保证是连续执行。也就是说 read 与 load 之间、store 与 write 之间是可以插入其他指令的，如对主内存中的变量 a 、b 进行访问时，一种可能出现的顺序是：read a -> read b -> load b -> load a 。

    img

​ 除此之外，Java 内存模型还规定了在执行了上述 8 种基本操作时必须满足如下规则：

  • 不允许 read 和 load、store 和 write 操作之一单独出现，即不允许一个变量从主内存读取了但工作内存不接受，或者从工作内存发起回写了但主内存不接受的情况出现
  • 不允许一个线程丢弃它的最近的 assign 操作，即变量在工作内存中改变了之后，必须把该变化同步回主内存
  • 不允许一个线程无原因地（没有发生过任何 assign 操作）把数据从从线程地工作内存同步回主内存
  • 一个新的变量只能在主内存中“诞生”，不允许在工作内存中直接使用一个未被初始化（load 或 assig ）的变量，换句话说，就是对一个变量实施 use 、store 操作之间，必须先执行过了 assig 和 load 操作
  • 一个变量在同一时刻只允许一条线程对其进行 lock 操作，但 lock 操作可以被同一条线程重复执行多次，多次执行 lock 后，只有执行相同次数的 unlock 操作，变量才会被解锁
  • 如果对一个变量执行 lock 操作，那将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行 load 或 assign 操作初始化变量的值
  • 如果一个变量事先没有被 load 操作锁定， 那就不允许对它执行 unlock 操作，也不允许去 unlock 一个被其他线程锁定住的变量
  • 对一个变量执行 unlock 操作之前，必须先把此变量同步回主内存中（执行 store 、write 操作）

long 和 double 型变量的特殊性

​ Java 内存模型要求 lock、unlock、read、load、assign、use、store、write 这 8 个操作都具有原子性，但对于 64 位的数据类型（long 或 double），在模型中定义了一条相对宽松的规定，允许虚拟机将没有被 volatile 修饰的 64 位数据的读写操作划分位两次 32 位的操作来进行，即允许虚拟机实现选择可以不保证 64 位数据类型的 load 、store 、read 、write 这 4 个操作的原子性，即 long 和 double 的非原子性协定

	如果多线程的情况下 double 或 long 类型并未声明为 `volatile` ，可能会出现“半个变量”的数值，也就是既非原值，也非修改后的值

​ 虽然 Java 规范允许上面的实现，但商用虚拟机中基本都采用了原子性的操作，因此在日常使用中几乎不会出现读取到“半个变量”的情况。

先行发生原则

​ 先行发生（happens-before）是 Java 内存模型中定义的两项操作之间的偏序关系，如果操作 A 先行发生于操作 B，那么 A 的结果对 B 可见。happens-before 关系的分析需要分为单线程和多线程 的情况：

  • 单线程下的 happens-before ：字节码的先后顺序天然包含 happens-before 关系：因为单线程共享一份工作内存，不存在数据一致性问题。在程序控制流路径中考靠前的字节码 happens-before 靠后的字节码，即靠前的字节码执行完毕之后操作结果对靠后的字节码可见。然而，这并不意味着前者一定在后者之前执行。实际上，如果后者不依赖前者的运行结果，那么它们可能被重新排序
  • **多线程下的 happens-before ** ：多线程由于每个线程共享变量的副本，如果没有对共享变量做同步处理，线程 1 更新执行操作 A 共享变量的值之后，线程 2 开始执行操作 B ，此时操作 A 产生的结果对操作 B 不一定可见

为了方便程序开发，Java 内存模型实现了下述的先行发生关系：

  • 程序次序规则：一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作
  • 管程锁定规则：一个 unlock 操作先行发生于后面对同一个锁的 lock 操作
  • volatile 变量规则：对一个变量的写操作 happens-before 后面对这个变量的读操作
  • 传递规则：如果操作 A 先行发生于操作 B ，而操作 B 又先行发生于操作 C ，则可以得出操作 A 先行发生于操作 C
  • 线程启动规则：Thread 对象的 start() 方法先行发生于此线程的每一个动作
  • 线程中断规则：对线程 interrupt() 方法的调用先行发生于被中断线程的代码检测到中断事件的发生
  • 线程终结规则：线程中所有的操作都先行发生于线程的终止检测，我们可以通过 Thread.join() 方法结束、Thread.isAlive() 的返回值手段检测到线程已终止运行
  • 对象终结规则：一个对象的初始化完成先行发生于它的 finalize() 方法的开始

内存屏障

​ 上边的一系列操作保证了数据一致性，Java 中如何保证底层操作的有序性和可见性？可以通过内存屏障。

内存屏障是被插入两个 CPU 指令之间的一种指令，用来禁止处理器指令发生重排序（像屏障一样），从而保障有序性的。另外，为了达到屏障的效果，它也会使处理器写入、读取值之前，将主内存的值写入高速缓存，清空无效队列，从而保障可见性

eg:

Store1;
Store2;
Load1;
StoreLoad;  //内存屏障
Store3;
Load2;
Load3;

对于上面一组 CPU 指令（store 表示写入指令，load 标识读取指令），StoreLoad 屏障之前的 store 指令无法与 StoreLoad 屏障之后的 load 指令进行交换位置，即重排序。但是 StoreLoad 屏障之前和之后的指令是可以交互位置的，即 store 1 可以与 store 2 交换， load 2 可以与 load 3 互换

常见的 4 种屏障：

  • LoadLoad 屏障：对于这样的语句 Load1; LoadLoad; Load2，在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕。
  • StoreStore 屏障：对于这样的语句 Store1; StoreStore; Store2，在Store2及后续写入操作执行前，保证Store1的写入操作对其它处理器可见。
  • LoadStore 屏障：对于这样的语句Load1; LoadStore; Store2，在Store2及后续写入操作被执行前，保证Load1要读取的数据被读取完毕。
  • StoreLoad 屏障：对于这样的语句Store1; StoreLoad; Load2，在Load2及后续所有读取操作执行前，保证Store1的写入对所有处理器可见。它的开销是四种屏障中最大的（冲刷写缓冲器，清空无效化队列）。在大多数处理器的实现中，这个屏障也被称为全能屏障，兼具其它三种内存屏障的功能。

​ Java 中对内存屏障的使用在一般的代码中不太容易见到，常见的有 volatile 和 synchronized 关键字修饰的代码块，还可以通过 Unsafe 这个类来使用内存屏障。（下一章扯扯这些）

Java 内存模型就是通过定义的这些来解决可见性、原子性和有序性的。

avatar
文章
阅读
粉丝