Java内存模型以及happens-before规则

1. JMM 介绍

出现线程安全的问题一般是因为主内存和工作内存数据不一致性和重排序导致的，而解决线程安全的问题最重要的就是理解这两种问题是怎么来的，那么，理解它们的核心在于理解 java 内存模型（JMM，Java Memory Model）。

在多线程条件下，多个线程肯定会相互协作完成一件事情，一般来说就会涉及到多个线程间相互通信告知彼此的状态以及当前的执行结果等，另外，为了性能优化，还会涉及到编译器指令重排序和处理器指令重排序。

注：这里提到的是 Java 内存模型，是和并发编程相关的，不是 JVM 内存结构（堆、方法栈这些概念），这两个不是一回事，别弄混了。

Java 内存模型（Java Memory Model ,JMM）就是一种符合内存模型规范的，屏蔽了各种硬件和操作系统的访问差异的，保证了Java 程序在各种平台下对内存的访问都能得到一致效果的机制及规范。目的是解决由于多线程通过共享内存进行通信时，存在的原子性、可见性（缓存一致性）以及有序性问题。

多级硬件架构

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

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

• L1 Cache最接近 CPU, 容量最小（如32K、64K、256K等）、速度最高，每个核上都有一个 L1 Cache。
• L2 Cache容量更大（如256K）、速度更低, 一般情况下，每个核上都有一个独立的 L2 Cache。
• L3 Cache最接近内存，容量最大（如12MB），速度最低，在同一个CPU插槽之间的核共享一个 L3 Cache。

2. 内存模型抽象结构

在并发编程中主要需要解决两个问题：

• 线程之间如何通讯（以何种机制来交换信息）
  • 共享内存
  • 消息传递
• 线程之间如何完成同步

Java 内存模型是共享内存的并发模型，线程之间主要通过读-写共享变量来完成隐式通信。如果程序员不能理解 Java 的共享内存模型在编写并发程序时一定会遇到各种各样关于内存可见性的问题。

2.1 哪些是共享变量

• 在 Java 程序中所有 实例域，静态域和数组元素都是放在堆内存中，所有线程均可访问到，是可以共享的。
• 而局部变量，方法定义参数和异常处理器参数不会在线程间共享。共享数据会出现线程安全的问题，而非共享数据不会出现线程安全的问题。

2.2 JMM 抽象模型结构

我们知道 CPU 的处理速度和主存的读写速度不是一个量级的，为了平衡这种巨大的差距，每个 CPU 都会有缓存。因此，共享变量会先放在主存中，每个线程都有属于自己的工作内存，并且会把位于主存中的共享变量拷贝到自己的工作内存，之后的读写操作均使用位于工作内存的变量副本，并在某个时刻将工作内存的变量副本写回到主存中去。JMM 就从抽象层次定义了这种方式，并且 JMM 决定了一个线程对共享变量的写入何时对其他线程是可见的。

如图为 JMM 抽象示意图，线程A和线程B之间要完成通信的话，要经历如下两步：

1. 线程 A 从主内存中将共享变量读入线程 A 的工作内存后并进行操作，之后将数据重新写回到主内存中；
2. 线程 B 从主存中读取最新的共享变量

内存间交互操作

Java 内存模型定义了 8 个操作来完成主内存和工作内存的交互操作

• read：把一个变量的值从主内存传输到线程的工作内存中
• load：在 read 之后执行，把 read 得到的值放入线程的工作内存的变量副本中
• use：把线程的工作内存中一个变量的值传递给执行引擎
• assign：把一个从执行引擎接收到的值赋给工作内存的变量
• store：把工作内存的一个变量的值传送到主内存中
• write：在 store 之后执行，把 store 得到的值放入主内存的变量中

• lock：作用于主内存的变量，把一个变量标识成一条线程独占的状态
• unlock: 作用于主内存的变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。

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

出现脏读：如果线程 A 更新后数据并没有及时写回到主存，而此时线程 B 读到的是过期的数据，这就出现了「脏读」现象。

脏读的解决：可以通过同步机制（控制不同线程间操作发生的相对顺序）来解决或通过 volatile 关键字使得每次 volatile 修饰的变量都能够强制刷新到主存，从而对每个线程都是可见的。

3. 处理器优化和指令重排

一个好的内存模型实际上会放松对处理器和编译器规则的束缚，也就是说软件技术和硬件技术都为同一个目标而进行奋斗：在不改变程序执行结果的前提下，尽可能提高并行度。JMM 对底层尽量减少约束，使其能够发挥自身优势。因此，在执行程序时，为了提高性能，编译器（JIT）和处理器常常会对指令进行重排序。一般重排序可以分为如下三种：

• 编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序；
• 指令级并行的重排序。现代处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序；
• 内存系统的重排序。由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行的。

面对重排序，如何保证顺序？

重排序

• 编译器重排序 → JMM 的编译器重排序规则会处理器优化和指令重排
• 处理器重排序 → 生成指令序列的时候会通过插入内存屏障指令来禁止某些特殊的处理器重排序。
  • 指令级并行重排序
  • 内存系统重排序

如图，1 属于编译器重排序，而 2 和 3 统称为处理器重排序（处理器优化）。这些重排序会导致线程安全的问题，一个很经典的例子就是 DCL 问题。针对编译器重排序（指令重排），JMM 的编译器重排序规则会处理器优化和指令重排；针对处理器重排序，编译器在生成指令序列的时候会通过插入内存屏障指令来禁止某些特殊的处理器重排序。

如果两个操作访问同一个变量，且这两个操作有一个为写操作，此时这两个操作就存在数据依赖性。这里就存在三种情况：1. 读后写；2.写后写；3. 写后读，这三种操作都是存在数据依赖性的，如果重排序会对最终执行结果会存在影响。编译器和处理器在重排序时，会遵守数据依赖性，编译器和处理器不会改变存在数据依赖性关系的两个操作的执行顺序

3.1 as-if-serial 语义

as-if-serial 语义的意思是：不管怎么重排序（编译器和处理器为了提供并行度），（单线程）程序的执行结果不能被改变（但是多线程可能改变）。as-if-serial 语义把单线程程序保护了起来，遵守 as-if-serial 语义的编译器，runtime 和处理器共同为编写单线程程序的程序员创建了一个幻觉：单线程程序是按程序的顺序来执行的。as-if-serial 语义使程序员不必担心单线程中重排序的问题干扰他们，也无需担心内存可见性问题。

4. happens-before规则

JMM为程序员在上层提供了八具体的一共有六项规则：

1. 程序顺序规则：一个线程中的每个操作，happens-before 于该线程中的任意后续操作。
2. 监视器锁规则：对一个锁的解锁，happens-before 于随后对这个锁的加锁。
3. volatile 变量规则：对一个 volatile 域的写，happens-before 于任意后续对这个 volatile 域的读。
4. 传递性：如果 A happens-before B，且 B happens-before C，那么 A happens-before C。
5. start()规则：如果线程A执行操作ThreadB.start()（启动线程B），那么A线程的ThreadB.start()操作happens-before于线程B中的任意操作。
6. join() 规则：如果线程A执行操作ThreadB.join()并成功返回，那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回。
7. 程序中断规则：对线程interrupted()方法的调用先行于被中断线程的代码检测到中断时间的发生。
8. 对象finalize规则：一个对象的初始化完成（构造函数执行结束）先行于发生它的finalize()方法的开始。

4.1 happens-before 定义

JSR-133 使用 happens-before 的概念来指定两个操作之间的执行顺序。由于这两个操作可以在一个线程之内，也可以是在不同线程之间。因此，JMM可以通过 happens-before 关系向程序员提供跨线程的内存可见性保证（如果A 线程的写操作 a 与 B 线程的读操作 b 之间存在 happens-before 关系，尽管 a 操作和 b 操作在不同的线程中执行，但 JMM 向程序员保证 a 操作将对 b 操作可见）。具体的定义为：

1. 如果一个操作 happens-before 另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前。
2. 两个操作之间存在 happens-before 关系，并不意味着 Java 平台的具体实现必须要按照 happens-before 关系指定的顺序来执行。如果重排序之后的执行结果，与按 happens-before 关系来执行的结果一致，那么这种重排序并不非法（也就是说，JMM 允许这种重排序）。

第一点是 JMM 对程序员的承诺。从程序员的角度来说，可以这样理解 happens-before 关系：如果A happens-before B，那么Java内存模型将向程序员保证——A操作的结果将对B可见，且A的执行顺序排在B之前。注意，这只是Java内存模型向程序员做出的保证！

第二点是 JMM 对编译器和处理器重排序的约束原则。正如前面所言，JMM 其实是在遵循一个基本原则：只要不改变程序的执行结果（指的是单线程程序和正确同步的多线程程序），编译器和处理器怎么优化都行。

因此，happens-before 关系本质上和 as-if-serial 语义是一回事。

as-if-serial VS happens-before

• as-if-serial 语义保证单线程内程序的执行结果不被改变，happens-before 关系保证正确同步的多线程程序的执行结果不被改变。
• as-if-serial 语义给编写单线程程序的程序员创造了一个幻境：单线程程序是按程序的顺序来执行的。happens-before 关系给编写正确同步的多线程程序的程序员创造了一个幻境：正确同步的多线程程序是按 happens-before 指定的顺序来执行的。
• as-if-serial 语义和 happens-before 这么做的目的，都是为了在不改变程序执行结果的前提下，尽可能地提高程序执行的并行度。

5. 总结

5.1 JMM 的设计

5.2 并发编程的问题

原子性问题，可见性问题和有序性问题。是人们抽象定义出来的。而这个抽象的底层问题就是前面提到的缓存一致性问题、处理器优化问题和指令重排问题等。并发编程，为了保证数据的安全，需要满足以下三个特性：

• 原子性：在一个操作中 cpu 不可以在中途暂停然后再调度，既不被中断操作，要不执行完成，要不就不执行。
• 可见性：当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。
• 有序性：即程序执行的顺序按照代码的先后顺序执行。

缓存一致性问题其实就是可见性问题。而处理器优化是可以导致原子性问题的。指令重排即会导致有序性问题。

所以，为了保证并发编程中可以满足原子性、可见性及有序性。有一个重要的概念，那就是——内存模型。为了保证共享内存的正确性（可见性、有序性、原子性），内存模型定义了共享内存系统中多线程程序读写操作行为的规范。通过这些规则来规范对内存的读写操作，从而保证指令执行的正确性。它与处理器有关、与缓存有关、与并发有关、与编译器也有关。他解决了CPU多级缓存、处理器优化、指令重排等导致的内存访问问题，保证了并发场景下的一致性、原子性和有序性。

5.3 什么是 Java 内存模型

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

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

这里面提到的主内存和工作内存，读者可以简单的类比成计算机内存模型中的主存和缓存的概念。特别需要注意的是，主内存和工作内存与JVM内存结构中的Java堆、栈、方法区等并不是同一个层次的内存划分，无法直接类比。《深入理解Java虚拟机》中认为，如果一定要勉强对应起来的话，从变量、主内存、工作内存的定义来看，主内存主要对应于Java堆中的对象实例数据部分。工作内存则对应于虚拟机栈中的部分区域。

所以，再来总结下，JMM 是一种规范，目的是解决由于多线程通过共享内存进行通信时，存在的本地内存数据不一致、编译器会对代码指令重排序、处理器会对代码乱序执行等带来的问题。

5.4 Java 内存模型的实现

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

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

6. 其他资料

• Java 多线程 - Java 内存模型链接