[TOC] ## Java 内存模型（JMM） Java 内存模型试图屏蔽各种硬件和操作系统的内存访问差异，以实现让 Java 程序在各种平台下都能达到一致的内存访问效果。 ### 主内存与工作内存 处理器上的寄存器的读写的速度比内存快几个数量级，为了解决这种速度矛盾，在它们之间加入了高速缓存。 加入高速缓存带来了一个新的问题：缓存一致性。如果多个缓存共享同一块主内存区域，那么多个缓存的数据可能会不一致，需要一些协议来解决这个问题。 [](https://github.com/frank-lam/fullstack-tutorial/blob/master/notes/JavaArchitecture/assets/1195582-20180508173147029-1341787720.png) 所有的变量都存储在**主内存**中，每个线程还有自己的**工作内存**，工作内存存储在高速缓存或者寄存器中，保存了该线程使用的变量的主内存副本拷贝。 线程只能直接操作工作内存中的变量，不同线程之间的变量值传递需要通过主内存来完成。 **Java内存模型和硬件关系图** [](https://github.com/frank-lam/fullstack-tutorial/blob/master/notes/JavaArchitecture/assets/v2-4015322359279c5568263aeb7f41c36d.jpg) **Java内存模型抽象结构图** [](https://github.com/frank-lam/fullstack-tutorial/blob/master/notes/JavaArchitecture/assets/1135283-20170403195814660-1521573510.png) ### 内存间交互操作 Java 内存模型定义了 8 个操作来完成主内存和工作内存的交互操作。 [](https://github.com/frank-lam/fullstack-tutorial/blob/master/notes/JavaArchitecture/assets/536c6dfd-305a-4b95-b12c-28ca5e8aa043.png) * read：把一个变量的值从主内存传输到工作内存中 * load：在 read 之后执行，把 read 得到的值放入工作内存的变量副本中 * use：把工作内存中一个变量的值传递给执行引擎 * assign：把一个从执行引擎接收到的值赋给工作内存的变量 * store：把工作内存的一个变量的值传送到主内存中 * write：在 store 之后执行，把 store 得到的值放入主内存的变量中 * lock：作用于主内存的变量，把一个变量标识为一条线程独占状态 * unlock：作用于主内存变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定 如果要把一个变量从主内存中复制到工作内存，就需要按顺寻地执行 read 和 load 操作，如果把变量从工作内存中同步回主内存中，就要按顺序地执行 store 和 write 操作。Java内存模型只要求上述操作必须按顺序执行，而没有保证必须是连续执行。也就是 read 和 load 之间，store 和 write 之间是可以插入其他指令的，如对主内存中的变量a、b进行访问时，可能的顺序是read a，read b，load b， load a。 **Java内存模型还规定了在执行上述8种基本操作时，必须满足如下规则：** * 不允许 read 和 load、store 和 write 操作之一单独出现 * 不允许一个线程丢弃它的最近 assign 的操作，即变量在工作内存中改变了之后必须同步到主内存中 * 不允许一个线程无原因地（没有发生过任何assign操作）把数据从工作内存同步回主内存中 * 一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化（load 或 assign）的变量。即就是对一个变量实施 use 和 store 操作之前，必须先执行过了 assign 和 load 操作。 * 一个变量在同一时刻只允许一条线程对其进行lock操作，lock 和 unlock必须成对出现 * 如果对一个变量执行 lock 操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前需要重新执行 load 或 assign 操作初始化变量的值 * 如果一个变量事先没有被 lock 操作锁定，则不允许对它执行 unlock 操作；也不允许去 unlock 一个被其他线程锁定的变量。 * 对一个变量执行 unlock 操作之前，必须先把此变量同步到主内存中（执行 store 和 write 操作）。 参考资料： [volatile关键字与Java内存模型(JMM) - yzwall - 博客园](https://www.cnblogs.com/yzwall/p/6661528.html) ### 内存模型三大特性 #### 1\. 原子性 * 概念 * 事物有原子性，这个概念大概都清楚，即一个操作或多个操作要么执行的过程中不被任何因素打断，要么不执行。 * 如何实现原子性？ * 通过同步代码块 synchronized 或者 local 锁来确保原子性 Java 内存模型保证了 read、load、use、assign、store、write、lock 和 unlock 操作具有原子性，例如对一个 int 类型的变量执行 assign 赋值操作，这个操作就是原子性的。但是 Java 内存模型允许虚拟机将没有被 volatile 修饰的 64 位数据（long，double）的读写操作划分为两次 32 位的操作来进行，即 load、store、read 和 write 操作可以不具备原子性。 有一个错误认识就是，int 等原子性的变量在多线程环境中不会出现线程安全问题。前面的线程不安全示例代码中，cnt 变量属于 int 类型变量，1000 个线程对它进行自增操作之后，得到的值为 997 而不是 1000。 为了方便讨论，将内存间的交互操作简化为 3 个：load、assign、store。 下图演示了两个线程同时对 cnt 变量进行操作，load、assign、store 这一系列操作整体上看不具备原子性，那么在 T1 修改 cnt 并且还没有将修改后的值写入主内存，T2 依然可以读入该变量的值。可以看出，这两个线程虽然执行了两次自增运算，但是主内存中 cnt 的值最后为 1 而不是 2。因此对 int 类型读写操作满足原子性只是说明 load、assign、store 这些单个操作具备原子性。 [](https://github.com/frank-lam/fullstack-tutorial/blob/master/notes/JavaArchitecture/assets/ef8eab00-1d5e-4d99-a7c2-d6d68ea7fe92-1534148019548.png) AtomicInteger 能保证多个线程修改的原子性。 [](https://github.com/frank-lam/fullstack-tutorial/blob/master/notes/JavaArchitecture/assets/952afa9a-458b-44ce-bba9-463e60162945-1534148027104.png) 使用 AtomicInteger 重写之前线程不安全的代码之后得到以下线程安全实现： ~~~java public class AtomicExample { private AtomicInteger cnt = new AtomicInteger(); public void add() { cnt.incrementAndGet(); } public int get() { return cnt.get(); } } ~~~ ~~~java public static void main(String[] args) throws InterruptedException { final int threadSize = 1000; AtomicExample example = new AtomicExample(); // 只修改这条语句 final CountDownLatch countDownLatch = new CountDownLatch(threadSize); ExecutorService executorService = Executors.newCachedThreadPool(); for (int i = 0; i < threadSize; i++) { executorService.execute(() -> { example.add(); countDownLatch.countDown(); }); } countDownLatch.await(); executorService.shutdown(); System.out.println(example.get()); } ~~~ ~~~ 1000 ~~~ 除了使用原子类之外，也可以使用 synchronized 互斥锁来保证操作的原子性。它对应的内存间交互操作为：lock 和 unlock，在虚拟机实现上对应的字节码指令为 monitorenter 和 monitorexit。 ~~~java public class AtomicSynchronizedExample { private int cnt = 0; public synchronized void add() { cnt++; } public synchronized int get() { return cnt; } } public static void main(String[] args) throws InterruptedException { final int threadSize = 1000; AtomicSynchronizedExample example = new AtomicSynchronizedExample(); final CountDownLatch countDownLatch = new CountDownLatch(threadSize); ExecutorService executorService = Executors.newCachedThreadPool(); for (int i = 0; i < threadSize; i++) { executorService.execute(() -> { example.add(); countDownLatch.countDown(); }); } countDownLatch.await(); executorService.shutdown(); System.out.println(example.get()); } ~~~ ~~~ 1000 ~~~ #### 2\. 可见性 可见性指当一个线程修改了共享变量的值，其它线程能够立即得知这个修改。Java 内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值来实现可见性的。 主要有有三种实现可见性的方式： * volatile * synchronized，对一个变量执行 unlock 操作之前，必须把变量值同步回主内存。 * final，被 final 关键字修饰的字段在构造器中一旦初始化完成，并且没有发生 this 逃逸（其它线程通过 this 引用访问到初始化了一半的对象），那么其它线程就能看见 final 字段的值。 对前面的线程不安全示例中的 cnt 变量使用 volatile 修饰，不能解决线程不安全问题，因为 volatile 并不能保证操作的原子性。 #### 3\. 有序性 有序性是指：在本线程内观察，所有操作都是有序的。在一个线程观察另一个线程，所有操作都是无序的，无序是因为发生了指令重排序。 在 Java 内存模型中，允许编译器和处理器对指令进行重排序，重排序过程不会影响到单线程程序的执行，却会影响到多线程并发执行的正确性。 volatile 关键字通过添加内存屏障的方式来禁止指令重排，即重排序时不能把后面的指令放到内存屏障之前。 也可以通过 synchronized 来保证有序性，它保证每个时刻只有一个线程执行同步代码，相当于是让线程顺序执行同步代码。 ### 指令重排序 在执行程序时为了提高性能，编译器和处理器常常会对指令做重排序。 指令重排序包括：**编译器重排序**和**处理器重排序** 重排序分三种类型： 1. **编译器优化的重排序**。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。 2. **指令级并行的重排序**。现代处理器采用了指令级并行技术（Instruction-Level Parallelism， ILP）来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。 3. **内存系统的重排序**。由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。 从 Java 源代码到最终实际执行的指令序列，会分别经历下面三种重排序： [](https://github.com/frank-lam/fullstack-tutorial/blob/master/notes/JavaArchitecture/assets/33-1534150864535.png) **上述的 1 属于编译器重排序，2 和 3 属于处理器重排序**。这些重排序都可能会导致多线程程序出现内存可见性问题。对于编译器，JMM 的编译器重排序规则会禁止特定类型的编译器重排序（不是所有的编译器重排序都要禁止）。对于处理器重排序，JMM 的处理器重排序规则会要求 Java 编译器在生成指令序列时，插入特定类型的内存屏障（memory barriers，intel 称之为 memory fence）指令，通过内存屏障指令来禁止特定类型的处理器重排序（不是所有的处理器重排序都要禁止）。 JMM 属于语言级的内存模型，它确保在不同的编译器和不同的处理器平台之上，通过禁止特定类型的编译器重排序和处理器重排序，为程序员提供一致的内存可见性保证。 #### 数据依赖性 如果两个操作访问同一个变量，且这两个操作中有一个为写操作，此时这两个操作之间就存在数据依赖性。数据依赖分下列三种类型： | 名称 | 代码示例 | 说明 | | --- | --- | --- | | 写后读 | a = 1;b = a; | 写一个变量之后，再读这个位置。 | | 写后写 | a = 1;a = 2; | 写一个变量之后，再写这个变量。 | | 读后写 | a = b;b = 1; | 读一个变量之后，再写这个变量。 | 上面三种情况，只要重排序两个操作的执行顺序，程序的执行结果将会被改变。 前面提到过，编译器和处理器可能会对操作做重排序。编译器和处理器在重排序时，会遵守数据依赖性，编译器和处理器不会改变存在数据依赖关系的两个操作的执行顺序。 注意，这里所说的数据依赖性仅针对单个处理器中执行的指令序列和单个线程中执行的操作，不同处理器之间和不同线程之间的数据依赖性不被编译器和处理器考虑。 #### as-if-serial语义 as-if-serial 语义的意思指：不管怎么重排序（编译器和处理器为了提高并行度），（单线程）程序的执行结果不能被改变。编译器，runtime 和 处理器 都必须遵守 as-if-serial 语义。 为了遵守 as-if-serial 语义，编译器和处理器不会对存在数据依赖关系的操作做重排序，因为这种重排序会改变执行结果。但是，如果操作之间不存在数据依赖关系，这些操作可能被编译器和处理器重排序。为了具体说明，请看下面计算圆面积的代码示例： ~~~java double pi = 3.14; //A double r = 1.0; //B double area = pi * r * r; //C ~~~ 上面三个操作的数据依赖关系如下图所示： [](https://github.com/frank-lam/fullstack-tutorial/blob/master/notes/JavaArchitecture/assets/11.png) 如上图所示，A 和 C 之间存在数据依赖关系，同时 B 和 C 之间也存在数据依赖关系。因此在最终执行的指令序列中，C 不能被重排序到 A 和 B 的前面（C 排到 A 和 B 的前面，程序的结果将会被改变）。但 A 和 B 之间没有数据依赖关系，编译器和处理器可以重排序 A 和 B 之间的执行顺序。下图是该程序的两种执行顺序： [](https://github.com/frank-lam/fullstack-tutorial/blob/master/notes/JavaArchitecture/assets/22.png) as-if-serial 语义把单线程程序保护了起来，遵守 as-if-serial 语义的编译器，runtime 和处理器共同为编写单线程程序的程序员创建了一个幻觉：单线程程序是按程序的顺序来执行的。as-if-serial 语义使单线程程序员无需担心重排序会干扰他们，也无需担心内存可见性问题。 #### 程序顺序规则 根据 happens- before 的程序顺序规则，上面计算圆的面积的示例代码存在三个 happens- before 关系： 1. A happens- before B； 2. B happens- before C； 3. A happens- before C； 这里的第 3 个 happens- before 关系，是根据 happens- before 的传递性推导出来的。 这里 A happens- before B，但实际执行时 B 却可以排在 A 之前执行（看上面的重排序后的执行顺序）。如果A happens- before B，JMM 并不要求 A 一定要在 B 之前执行。JMM 仅仅要求前一个操作（执行的结果）对后一个操作可见，且前一个操作按顺序排在第二个操作之前。这里操作 A 的执行结果不需要对操作 B 可见；而且重排序操作 A 和操作 B 后的执行结果，与操作 A 和操作 B 按 happens- before 顺序执行的结果一致。在这种情况下， JMM 会认为这种重排序并不非法（not illegal），JMM 允许这种重排序。 在计算机中，软件技术和硬件技术有一个共同的目标：在不改变程序执行结果的前提下，尽可能的开发并行度。编译器和处理器遵从这一目标，从 happens- before 的定义我们可以看出，JMM 同样遵从这一目标。 #### 重排序对多线程的影响 现在让我们来看看，重排序是否会改变多线程程序的执行结果。请看下面的示例代码： ~~~java class ReorderExample { int a = 0; boolean flag = false; public void writer() { a = 1; // 1 flag = true; // 2 } Public void reader() { if (flag) { // 3 int i = a * a; // 4 …… } } } ~~~ flag 变量是个标记，用来标识变量 a 是否已被写入。这里假设有两个线程 A 和 B，A首先执行 writer() 方法，随后 B 线程接着执行 reader() 方法。线程 B 在执行操作 4 时，能否看到线程 A 在操作 1 对共享变量 a 的写入？ 答案是：不一定能看到。 由于操作 1 和操作 2 没有数据依赖关系，编译器和处理器可以对这两个操作重排序；同样，操作 3 和操作 4 没有数据依赖关系，编译器和处理器也可以对这两个操作重排序。让我们先来看看，当操作 1 和操作 2 重排序时，可能会产生什么效果？请看下面的程序执行时序图： [](https://github.com/frank-lam/fullstack-tutorial/blob/master/notes/JavaArchitecture/assets/33.png) 如上图所示，操作 1 和操作 2 做了重排序。程序执行时，线程 A 首先写标记变量 flag，随后线程 B 读这个变量。由于条件判断为真，线程 B 将读取变量 a。此时，变量 a 还根本没有被线程 A 写入，在这里多线程程序的语义被重排序破坏了！ ※注：本文统一用红色的虚箭线表示错误的读操作，用绿色的虚箭线表示正确的读操作。 下面再让我们看看，当操作 3 和操作 4 重排序时会产生什么效果（借助这个重排序，可以顺便说明控制依赖性）。下面是操作 3 和操作 4 重排序后，程序的执行时序图： [](https://github.com/frank-lam/fullstack-tutorial/blob/master/notes/JavaArchitecture/assets/44.png) 在程序中，操作 3 和操作 4 存在控制依赖关系。当代码中存在控制依赖性时，会影响指令序列执行的并行度。为此，编译器和处理器会采用猜测（Speculation）执行来克服控制相关性对并行度的影响。以处理器的猜测执行为例，执行线程 B 的处理器可以提前读取并计算 a\*a，然后把计算结果临时保存到一个名为重排序缓冲（reorder buffer ROB）的硬件缓存中。当接下来操作3的条件判断为真时，就把该计算结果写入变量 i 中。 从图中我们可以看出，猜测执行实质上对操作 3 和 4 做了重排序。重排序在这里破坏了多线程程序的语义！ 在单线程程序中，对存在控制依赖的操作重排序，不会改变执行结果（这也是 as-if-serial 语义允许对存在控制依赖的操作做重排序的原因）；但在多线程程序中，对存在控制依赖的操作重排序，可能会改变程序的执行结果。 参考资料： * [深入理解Java内存模型（一）——基础](http://www.infoq.com/cn/articles/java-memory-model-1) * [深入理解Java内存模型（二）——重排序](http://www.infoq.com/cn/articles/java-memory-model-2) ### 先行发生原则（happens-before） Happens-before 是用来指定两个操作之间的执行顺序。提供跨线程的内存可见性。 在 Java 内存模型中，如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必然存在 happens-before 关系。 上面提到了可以用 volatile 和 synchronized 来保证有序性。除此之外，JVM 还规定了先行发生原则，让一个操作无需控制就能先于另一个操作完成。 主要有以下这些原则： #### 1\. 单一线程原则 > Single Thread rule 在一个线程内，在程序前面的操作先行发生于后面的操作。 [](https://github.com/frank-lam/fullstack-tutorial/blob/master/notes/JavaArchitecture/assets/single-thread-rule-1534148720379.png) #### 2\. 管程锁定规则 > Monitor Lock Rule 对一个锁的解锁（unlock ），总是 happens-before 于随后对这个锁的加锁（lock） [](https://github.com/frank-lam/fullstack-tutorial/blob/master/notes/JavaArchitecture/assets/monitor-lock-rule-1534148737603.png) #### 3\. volatile 变量规则 > Volatile Variable Rule 对一个 volatile 变量的写操作先行发生于后面对这个变量的读操作。 [](https://github.com/frank-lam/fullstack-tutorial/blob/master/notes/JavaArchitecture/assets/volatile-variable-rule-1534148747964.png) #### 4\. 线程启动规则 > Thread Start Rule Thread 对象的 start() 方法调用先行发生于此线程的每一个动作。 [](https://github.com/frank-lam/fullstack-tutorial/blob/master/notes/JavaArchitecture/assets/thread-start-rule-1534148760654.png) #### 5\. 线程加入规则 > Thread Join Rule Thread 对象的结束先行发生于 join() 方法返回。 [](https://github.com/frank-lam/fullstack-tutorial/blob/master/notes/JavaArchitecture/assets/thread-join-rule-1534148774041.png) #### 6\. 线程中断规则 > Thread Interruption Rule 对线程 interrupt() 方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过 interrupted() 方法检测到是否有中断发生。 #### 7\. 对象终结规则 > Finalizer Rule 一个对象的初始化完成（构造函数执行结束）先行发生于它的 finalize() 方法的开始。 #### 8\. 传递性 > Transitivity 如果操作 A 先行发生于操作 B，操作 B 先行发生于操作 C，那么操作 A 先行发生于操作 C。