什么是JMM模型
Java内存模型(Java Memory Model简称JMM)是一种抽象的概念，并不真实存在，它描述的是一组规则或规范，通过这组规范定义了程序中各个变量（包括实例字段，静态字段 和构成数组对象的元素）的访问方式。JVM运行程序的实体是线程，而每个线程创建时 JVM都会为其创建一个工作内存(有些地方称为栈空间)，用于存储线程私有的数据，而Java 内存模型中规定所有变量都存储在主内存，主内存是共享内存区域，所有线程都可以访问， 但线程对变量的操作(读取赋值等)必须在工作内存中进行，首先要将变量从主内存拷贝的自 己的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，不能直接操作 主内存中的变量，工作内存中存储着主内存中的变量副本拷贝，前面说过，工作内存是每个 线程的私有数据区域，因此不同的线程间无法访问对方的工作内存，线程间的通信(传值)必 须通过主内存来完成。JMM是围绕 原子性，有序性、可见性展开。
并发和并行
目标都是最大化CPU的使用率
并行(parallel)：指在同一时刻，有多条指令在多个处理器上同时执行。所以无论从微观还是从宏观来看，二者都是一起执行的。
并发(concurrency)：指在同一时刻只能有一条指令执行，但多个进程指令被快速的轮换执行，使得在宏观上具有多个进程同时执行的效果，但在微观上并不是同时执行的，只是把时间分成若干段，使多个进程快速交替的执行。
并行在多处理器系统中存在，而并发可以在单处理器和多处理器系统中都存在，并发能够在单处理器系统中存在是因为并发是并行的假象，并行要求程序能够同时执行多个操作，而并发只是要求程序假装同时执行多个操作（每个小时间片执行一个操作，多个操作快速切换执行）
并发三大特性
可见性、原子性和有序性问题
可见性
当一个线程修改了共享变量的值，其他线程能够看到修改的值。Java 内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方法来实现可见性的。
public class VolatileTestDemo {
// 不加 volatile关键字 read() 方法中的循环不会退出
private Boolean flag = true;
public void refresh() {
flag = false;
System.out.println(Thread.currentThread().getName() + " , 修改 flag = " + flag);
}
public void read() {
int i = 0;
while (flag) {
i++;
// System.out.println(i); 这里不用加println打印 ，println使用了synchronize同步关键字
}
System.out.println(Thread.currentThread().getName() + "跳出循环 , i = " + i);
}
public static void main(String[] args) throws InterruptedException {
VolatileTestDemo volatileTestDemo = new VolatileTestDemo();
Thread threada = new Thread(() -> {
volatileTestDemo.read();
}, "threada");
threada.start();
Thread.sleep(1000);
Thread threadb = new Thread(() -> {
volatileTestDemo.refresh();
}, "threadb");
threadb.start();
}
}
flag 加上volatile修饰，运行程序会退出， 不加volatile修饰，程序不会立刻退出。如何保证可见性
通过 volatile 关键字保证可见性。
通过 内存屏障保证可见性。
通过 synchronized 关键字保证可见性。
通过 Lock保证可见性。
通过 final 关键字保证可见性
有序性
即程序执行的顺序按照代码的先后顺序执行。JVM 存在指令重排，所以存在有序性问题。
如何保证有序性
通过 volatile 关键字保证有序性。
通过 内存屏障保证有序性。
通过 synchronized关键字保证有序性。
通过 Lock保证有序性。
原子性
一个或多个操作，要么全部执行且在执行过程中不被任何因素打断，要么全部不执行。在 Java 中，对基本数据类型的变量的读取和赋值操作是原子性操作（64位处理器）。不采取任何的原子性保障措施的自增操作并不是原子性的。
如何保证原子性
通过 synchronized 关键字保证原子性。
通过 Lock保证原子性。
通过 CAS保证原子性。
JMM与硬件内存架构的关系
Java内存模型与硬件内存架构之间存在差异。硬件内存架构没有区分线程栈和堆。对于硬件，所有的线程栈和堆都分布在主内存中。部分线程栈和堆可能有时候会出现在CPU缓存中和CPU内部的寄存器中。如下图所示，Java内存模型和计算机硬件内存架构是一个交叉关系：
数据同步八大原子操作
关于主内存与工作内存之间的具体交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步到主内存之间的实现细节，Java内存模型定义了以下八种操作来完成：
lock（锁定）：作用于主内存的变量，把一个变量标识为一条线程独占状态。
unlock（解锁）：作用于主内存变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。
read（读取）：作用于主内存变量，把一个变量值从主内存传输到线程的工作内存中，以便随后的load动作使用
load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。
use（使用）：作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎，每当虚拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作。
assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋值给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
store（存储）：作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以便随后的write的操作。
write（写入）：作用于主内存的变量，它把store操作从工作内存中一个变量的值传送到主内存的变量中
Java内存模型还规定了在执行上述八种基本操作时，必须满足如下规则：
如果要把一个变量从主内存中复制到工作内存，就需要按顺寻地执行read和load操作， 如果把变量从工作内存中同步回主内存中，就要按顺序地执行store和write操作。但Java内存模型只要求上述操作必须按顺序执行，而没有保证必须是连续执行。
不允许read和load、store和write操作之一单独出现
不允许一个线程丢弃它的最近assign的操作，即变量在工作内存中改变了之后必须同步到主内存中。
不允许一个线程无原因地（没有发生过任何assign操作）把数据从工作内存同步回主内存中。
一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量。即就是对一个变量实施use和store操作之前，必须先执行过了assign和load操作。
一个变量在同一时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。lock和unlock必须成对出现
如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前需要重新执行load或assign操作初始化变量的值
如果一个变量事先没有被lock操作锁定，则不允许对它执行unlock操作；也不允许去unlock一个被其他线程锁定的变量。
对一个变量执行unlock操作之前，必须先把此变量同步到主内存中（执行store和write操作）。
JMM的内存可见性保证
按程序类型，Java程序的内存可见性保证可以分为下列3类：
单线程程序。单线程程序不会出现内存可见性问题。编译器、runtime和处理器会共同确保单线 程程序的执行结果与该程序在顺序一致性模型中的执行结果相同。
正确同步的多线程程序。正确同步的多线程程序的执行将具有顺序一致性（程序的执行结果与该 程序在顺序一致性内存模型中的执行结果相同）。这是JMM关注的重点，JMM通过限制编译器和处 理器的重排序来为程序员提供内存可见性保证。
未同步/未正确同步的多线程程序。JMM为它们提供了最小安全性保障：线程执行时读取到的 值，要么是之前某个线程写入的值，要么是默认值。未同步程序在JMM中执行时，整体上是无序 的，其执行结果无法预知。 JMM不保证未同步程序的执行结果与该程序在顺序一致性模型中的执行 结果一致。
未同步程序在JMM中的执行时，整体上是无序的，其执行结果无法预知。未同步程序在两个模型中的 执行特性有如下几个差异。
1）顺序一致性模型保证单线程内的操作会按程序的顺序执行，而JMM不保证单线程内的操作会按程序 的顺序执行，比如正确同步的多线程程序在临界区内的重排序。
2）顺序一致性模型保证所有线程只能看到一致的操作执行顺序，而JMM不保证所有线程能看到一致的 操作执行顺序。
3）顺序一致性模型保证对所有的内存读/写操作都具有原子性，而JMM不保证对64位的long型和 double型变量的写操作具有原子性（32位处理器）。
volatile的内存语义
volatile的特性
可见性：对一个volatile变量的读，总是能看到（任意线程）对这个volatile变量最后的写入。
原子性：对任意单个volatile变量的读/写具有原子性，但类似于volatile++这种复合操作不具有原子性（基于这点，我们通过会认为volatile不具备原子性）。volatile仅仅保证对单个volatile变量的读/写具有原子性，而锁的互斥执行的特性可以确保对整个临界区代码的执行具有原子性。
64位的long型和double型变量，只要它是volatile变量，对该变量的读/写就具有原子性。
有序性：对volatile修饰的变量的读写操作前后加上各种特定的内存屏障来禁止指令重排序来保障有序性。
在JSR-133之前的旧Java内存模型中，虽然不允许volatile变量之间重排序，但旧的Java内存模型允许volatile变量与普通变量重排序。为了提供一种比锁更轻量级的线程之间通信的机制，JSR-133专家组决定增强volatile的内存语义：严格限制编译器和处理器对volatile变量与普通变量的重排序，确保volatile的写-读和锁的释放-获取具有相同的内存语义。
volatile写-读的内存语义
当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量值刷新到主内存。
当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效，线程接下来将从主内存中读取共享变量。
volatile可见性实现原理
JMM内存交互层面实现
volatile修饰的变量的read、load、use操作和assign、store、write必须是连续的，即修改后必须立即同步回主内存，使用时必须从主内存刷新，由此保证volatile变量操作对多线程的可见性。
硬件层面实现
通过lock前缀指令，会锁定变量缓存行区域并写回主内存，这个操作称为“缓存锁定”，缓存一致性机制会阻止同时修改被两个以上处理器缓存的内存区域数据。一个处理器的缓存回写到内存会导致其他处理器的缓存无效。
指令重排序
Java语言规范规定JVM线程内部维持顺序化语义。即只要程序的最终结果与它顺序化情况的结果相等，那么指令的执行顺序可以与代码顺序不一致，此过程叫指令的重排序。
指令重排序的意义：JVM能根据处理器特性（CPU多级缓存系统、多核处理器等）适当的对机器指令进行重排序，使机器指令能更符合CPU的执行特性，最大限度的发挥机器性能。
在编译器与CPU处理器中都能执行指令重排优化操作
volatile禁止重排序场景：
1. 第二个操作是volatile写，不管第一个操作是什么都不会重排序
2. 第一个操作是volatile读，不管第二个操作是什么都不会重排序
3. 第一个操作是volatile写，第二个操作是volatile读，也不会发生重排序
JMM内存屏障插入策略
1. 在每个volatile写操作的前面插入一个StoreStore屏障
2. 在每个volatile写操作的后面插入一个StoreLoad屏障
3. 在每个volatile读操作的后面插入一个LoadLoad屏障
4. 在每个volatile读操作的后面插入一个LoadStore屏障
JVM层面的内存屏障
在JSR规范中定义了4种内存屏障：
LoadLoad屏障：（指令Load1; LoadLoad; Load2），在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕。
LoadStore屏障：（指令Load1; LoadStore; Store2），在Store2及后续写入操作被刷出前，保证Load1要读取的数据被读取完毕。
StoreStore屏障：（指令Store1; StoreStore; Store2），在Store2及后续写入操作执行前，保证Store1的写入操作对其它处理器可见。
StoreLoad屏障：（指令Store1; StoreLoad; Load2），在Load2及后续所有读取操作执行前，保证Store1的写入对所有处理器可见。它的开销是四种屏障中最大的。在大多数处理器的实现中，这个屏障是个万能屏障，兼具其它三种内存屏障的功能
由于x86只有store load可能会重排序，所以只有JSR的StoreLoad屏障对应它的mfence或lock前缀指令，其他屏障对应空操作
硬件层内存屏障
硬件层提供了一系列的内存屏障 memory barrier / memory fence(Intel的提法)来提供一致性的能力。拿X86平台来说，有几种主要的内存屏障：
1. lfence，是一种Load Barrier 读屏障
2. sfence, 是一种Store Barrier 写屏障
3. mfence, 是一种全能型的屏障，具备lfence和sfence的能力
4. Lock前缀，Lock不是一种内存屏障，但是它能完成类似内存屏障的功能。Lock会对CPU总线和高速缓存加锁，可以理解为CPU指令级的一种锁。它后面可以跟ADD, ADC, AND, BTC, BTR, BTS, CMPXCHG, CMPXCH8B, DEC, INC, NEG, NOT, OR, SBB, SUB, XOR, XADD, and XCHG等指令。
内存屏障有两个能力：
1. 阻止屏障两边的指令重排序
2. 刷新处理器缓存/冲刷处理器缓存
对Load Barrier来说，在读指令前插入读屏障，可以让高速缓存中的数据失效，重新从主内存加载数据；对Store Barrier来说，在写指令之后插入写屏障，能让写入缓存的最新数据写回到主内存。
Lock前缀实现了类似的能力，它先对总线和缓存加锁，然后执行后面的指令，最后释放锁后会把高速缓存中的数据刷新回主内存。在Lock锁住总线的时候，其他CPU的读写请求都会被阻塞，直到锁释放。
不同硬件实现内存屏障的方式不同，Java内存模型屏蔽了这种底层硬件平台的差异，由JVM来为不同的平台生成相应的机器码。
as-if-serial语义
as-if-serial语义的意思是：不管怎么重排序（编译器和处理器为了提高并行度），（单线 程）程序的执行结果不能被改变。编译器、runtime和处理器都必须遵守as-if-serial语义。
为了遵守as-if-serial语义，编译器和处理器不会对存在数据依赖关系的操作做重排序，因为 这种重排序会改变执行结果。但是，如果操作之间不存在数据依赖关系，这些操作就可能被编译 器和处理器重排序。
double pi = 3.14; // A
double r = 1.0; // B
double area = pi * r * r; // CA和C之间存在数据依赖关系，同时B和C之间也存在数据依赖关系。因此在最终执行的指令序 列中，C不能被重排序到A和B的前面（C排到A和B的前面，程序的结果将会被改变）。但A和B之 间没有数据依赖关系，编译器和处理器可以重排序A和B之间的执行顺序
happens-before 原则
从JDK 5 开始，JMM使用happens-before的概念来阐述多线程之间的内存可见性。在JMM 中，如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在happens- before关系。 happens-before和JMM关系如下图
happens-before原则非常重要，它是判断数据是否存在竞争、线程是否安全的主要依据，依 靠这个原则，我们解决在并发环境下两操作之间是否可能存在冲突的所有问题。下面我们就一个简单的例子稍微了解下happens-before ：
a = 1; //线程A执行
b = i ; //线程B执行b 是否等于1呢？假定线程A的操作（a = 1）happens-before线程B的操作（b = a）,那么可以 确定线程B执行后b = 1 一定成立，如果他们不存在happens-before原则，那么b = 1 不一定成 立。这就是happens-before原则的威力。
happens-before原则定义如下：
1. 如果一个操作happens-before另一个操作，那么第一个操作的执行结果将对第二个操作 可见，而且第一个操作的执行顺序排在第二个操作之前。
2. 两个操作之间存在happens-before关系，并不意味着一定要按照happens-before原则 制定的顺序来执行。如果重排序之后的执行结果与按照happens-before关系来执行的结果 一致，那么这种重排序并不非法。
happens-before原则规则：
1.程序次序规则：一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操 作；
2.锁定规则：一个unLock操作先行发生于后面对同一个锁的lock操作；
3.volatile变量规则：对一个变量的写操作先行发生于后面对这个变量的读操作；
4.传递规则：如果操作A先行发生于操作B，而操作B又先行发生于操作C，则可以得出操作A 先行发生于操作C；
5.线程启动规则：Thread对象的start()方法先行发生于此线程的每个一个动作；
6.线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件 的发生；
7.线程终结规则：线程中所有的操作都先行发生于线程的终止检测，我们可以通过 Thread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行；
8.对象终结规则：一个对象的初始化完成先行发生于他的finalize()方法的开始；