文章目录
本文参考于《深入理解Java虚拟机》、Java面试官告诉你JMM是什么和面什么、面试官：volatile是如何保证可见性和有序性的？、happen-before原则
1、 为什么要有Java内存模型？
1.1、 CPU和缓存一致性
1. 缓存一致性问题出现的原因
CPU的执行速度和内存的读取速度差距越来越大，导致CPU每次操作内存都要耗费很多等待时间。为解决这个问题，早期的程序员大佬提出了“CPU和物理内存上新增高速缓存”。将运算所需要的数据从主内存复制一份到CPU的高速缓存中，当CPU进行计算时就可以直接从高速缓存中读数据和写数据了，当运算结束再将数据刷新到主内存就可以了。在多核 CPU和多线程的情形 中，每个线程都有自己的缓存，关于同一个线程共享数据的缓存内容可能不一致。
1.2、 处理器优化和指令重排
1. 处理器优化
为了使处理器内部的运算单元能够被充分利用，处理器可能会对程序代码进行乱序执行处理，这就是处理器优化。
2. 指令重排
除了现在很多流行的处理器会对代码进行优化乱序处理，很多编程语言的编译器也会有类似的优化，比如 Java 虚拟机的即时编译器（JIT）也会做指令重排。
1.3、 并发编程带来的问题
1. 三大问题
原子性问题，可见性问题和有序性问题。其实就是上面讲的『缓存一致性』、『处理器优化』、『指令重排序』造成的。
2. 并发编程保证数据安全需要满足的特性
- 原子性：指的是在一个操作中CPU 不可以在中途暂停然后再调度，
要么不执行，要么就执行完成。 - 可见性：指的是
多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改后的值。 - 有序性：指的是
程序执行的顺序按照代码的先后顺序执行，而不能瞎几把重排，导致程序出现不一致的结果。
1.4、 JMM诞生的原因
Java
为了保证并发编程中可以满足原子性、可见性及有序性，诞生出了一个重要的概念，那就是Java内存模型，内存模型定义了共享内存系统中多线程程序读写操作行为的规范。通过这些规则来规范对内存的读写操作，从而保证指令执行的正确性，它解决了 CPU 多级缓存、处理器优化、指令重排等导致的内存访问问题，保证了并发场景下的一致性、原子性和有序性。
- JMM 内存模型解决并发问题主要采用两种方式：
限制处理器优化和使用内存屏障。
2、Java内存模型
2.1、JMM对内存的划分
1. JMM对内存的划分和工作运作规则
JMM规定了内存主要划分为主内存和工作内存两种。Java内存模型规定了所有的变量都存储在主内存中（此处的主内存与介绍物理硬件时提到的主内存名字一样，两者也可以类比，但物理上它仅是虚拟机内存的一部分）。每条线程还有自己的工作内存（可与前面讲的处理器高速缓存类比），线程的工作内存中保存了被该线程使用的变量的主内存副本，线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的数据。不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成。
2. 线程、主内存、工作内存三者的交互关系如下图：
2.2 、完成主内存和工作内存交互的操作
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。除此之外，Java内存模型还规定了在执行上述8种基本操作时必须满足如下规则：
不允许read和load、store和write操作之一单独出现，即不允许一个变量从主内存读取了但工作内存不接受，或者工作内存发起回写了但主内存不接受的情况出现。不允许一个线程丢弃它最近的assign操作，即变量在工作内存中改变了之后必须把该变化同步回主内存。不允许一个线程无原因地（没有发生过任何assign操作）把数据从线程的工作内存同步回主内存中。- 一个新的变量只能在主内存中“诞生”，
不允许在工作内存中直接使用一个未被初始化（load或assign）的变量，换句话说就是对一个变量实施use、store操作之前，必须先执行assign和load操作。 - 一个变量在同一个时刻
只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。 - 如果对一个变量执行lock操作，那将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行load或assign操作以初始化变量的值。
- 如果一个变量事先没有被lock操作锁定，那就不允许对它执行unlock操作，也不允许去unlock一个被其他线程锁定的变量。
- 对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store、write操作）。
2.3、线程间的通信机制
1. 线程之间的通信机制有哪些呢？
- 共享内存
- 消息传递
2. Java的并发采用的是哪种？
目前Java的并发通信采用的是共享内存的方式。
2.4、volatile关键字解析
2.4.1、volatile关键字的特性
- 第一项是保证此变量对所有线程的可见性。这里的“可见性”是指
当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的。而普通变量并不能做到这一点，普通变量的值在线程间传递时均需要通过主内存来完成。 - 使用volatile变量的第二个语义是禁止指令重排序优化，普通的变量仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。
而volatile变量的赋值操作的顺序与程序代码中的执行顺序一致。
2.4.2 、volatile关键字可见性问题
public class test {
public static boolean flag = true;
public static void main(String[] args) throws InterruptedException {
new Thread(()->{
while(flag){
}
}).start();
Thread.sleep(1000L);
new Thread(()->{
flag = false;
}).start();
}
}
程序的运行结果是一个死循环。一个线程在访问一个共享变量的时候，
其他线程对该共享变量的修改对于第一个线程来说是不可见的。
解决办法
public volatile static boolean flag = true;
2.4.3、volatile关键字是如何保证可见性？
1.变量被volatile关键字修饰的情形
-
当一个共享变量被 volatile 修饰时，它
会保证修改的值会被立即更新到主内存中，当有其他线程读取该值时，也不会直接读取工作内存中的值，而是直接去主内存中读取。 -
被volatile关键字修饰的变量，
在每个写操作之后，都会加入一条store内存屏障命令，此命令强制将此变量的最新值从工作内存同步至主内存；在每个读操作之前，都会加入一条load内存屏障命令，此命强制从主内存中将此变量的最新值加载至当前线程的工作内存中。
2. 变量未被volatile关键字修饰的情形
而普通的共享变量不能保证可见性的，因为普通共享变量被修改后，写入了工作内存中，什么时候写入主内存其实是不可知的，当其他线程去读取时，此时无论是工作内存还是主内存，可能还是原来的值，因此无法保证可见性。
2.4.4、volatile关键字保证有序性的原理
1. 有序性问题说明
有序性问题就是程序代码执行的顺序与程序员编写程序的顺序不一致，导致程序结果不正确的问题。而加了volatile修饰的共享变量，则通过内存屏障解决了多线程下有序性问题。
2. 原理解析
编译器在生成字节码时，会
在指令序列中插入内存屏障来禁止特定类型的处理器重排序。
在每个volatile写操作的前面插入一个StoreStore屏障。在每个volatile写操作的后面插入一个StoreLoad屏障。在每个volatile读操作的后面插入一个LoadLoad屏障。在每个volatile读操作的后面插入一个LoadStore屏障。
写操作之前后插入内存屏障后生成指令序列的示意图
读操作之后插入内存屏障后生成指令序列的示意图
2.5、针对long和double型变量的特殊规则
2.5.1、特殊规则说明
Java内存模型要求lock、unlock、read、load、assign、use、store、write这八种操作都具有原子性，但是对于64位的数据类型（long和double），在模型中特别定义了一条宽松的规定：允许虚拟机将没有被volatile修饰的64位数据的读写操作划分为两次32位的操作来进行，即允许虚拟机实现自行选择是否要保证64位数据类型的load、store、read和write这四个操作的原子性，这就是所谓的 “long和double的非原子性协定”。
2.5.2、特殊规则下的可能出现的情况
如果有多个线程共享一个并未声明为volatile的long或double类型的变量，并且同时对它们进行读取和修改操作，那么某些线程可能会读取到一个既不是原值，也不是其他线程修改值的代表了“半个变量”的数值。不过这种读取到“半个变量”的情况是非常罕见的，经过实际测试，在目前主流平台下商用的64位Java虚拟机中并不会出现非原子性访问行为，但是对于32位的Java虚拟机，譬如 比较常用的32位x86平台下的HotSpot虚拟机，对long类型的数据确实存在非原子性访问的风险。
2.6、happens-before原则
2.6.1、什么是happens-before原则？
JMM可以通过happens-before关系向程序员提供跨线程的内存可见性保证（如果A线程的写操作a与B线程的读操作b之间存在happens-before关系，尽管a操作和b操作在不同的线程中执行，但JMM向程序员保证a操作将对b操作可见）。
2.6.2、happens-before原则的特点
-
如果一个操作happens-before另一个操作，那么
第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前。 -
两个操作之间存在happens-before关系，并不意味着Java平台的具体实现必须要按照happens-before关系指定的顺序来执行。
如果重排序之后的执行结果，与按happens-before关系来执行的结果一致，那么这种重排序并不非法（也就是说，JMM允许这种重排序）。
2.6.3、happens-before原则的8大规则
- 程序次序规则：在一个线程内，
按照控制流顺序，书写在前面的操作先行发生于书写在后面的操作。注意，这里说的是控制流顺序而不是程序代码顺序，因为要考虑分支、循环等结构。 - 管程锁定规则：
一个unlock操作先行发生于后面对同一个锁的lock操作。这里必须强调的是“同一个锁”，而“后面”是指时间上的先后。 - volatile变量规则：
对一个volatile变量的写操作先行发生于后面对这个变量的读操作，这里的“后面”同样是指时间上的先后。 - 线程启动规则：Thread对象的
start()方法先行发生于此线程的每一个动作。 - 线程终止规则：线程中的
所有操作都先行发生于对此线程的终止检测，我们可以通过Thread::join()方法是否结束、Thread::isAlive()的返回值等手段检测线程是否已经终止执行。 - 线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread::interrupted()方法检测到是否有中断发生。
- 对象终结规则：一个对象的
初始化完成（构造函数执行结束）先行发生于它的finalize()方法的开始。 - 传递性：如果操作A先行发生于操作B，操作B先行发生于操作C，那就可以得出操作A先行发生于操作C的结论。