文章目录1、为什么需要Java内存模型？ 1.1、CPU和高速缓存一致性1.2、处理器优化和指令重定位1.3、并发编程问题1.4、JMM诞生原因2、Java内存模型2.1、JMM内存分割2.2、完成主内存和工作内存的交互volatile关键字解析2.4.1、volatile 2.4.4、volatile关键字保证有序性的原理2.5、对long和double型变量的特殊规则2.5.1、特殊规则说明2.5.2、特殊规则happeens是什么2.6.2、happens-before原则的特点2.6.3、happens-before原则的8条规则
本文题目《深入理解Java虚拟机》、Java面试官问你什么是JMM，面试官： volatile如何保证可见性和有序性？happen-before原则
1、为什么需要Java内存模型？ 1.1、CPU和缓存完整性1. 缓存一致性问题出现的原因
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 (lock ) )是作用于主存储器的变量，将1个变量作为线程独占的状态识别。 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的结论。