1. volatile的应用
1.1 volatile的定义
Java ，为了确保共享变量能被准确和一致的更新，线程应该确保通过排它锁单独获取这个变量。
java语言提供了volatile，在某些情况下比加锁更加方便。如果一个字段被声明为volatile，Java线程内存模型确保所有线程看到这个变量的值是一致的。
1.2 通过代码演示volatile的使用
public class VolatileDemo {
private static boolean stop = true;
public static void main(String[] args) throws InterruptedException {
Thread thread = new Thread(() -> {
int i = 0;
while (stop) {
i++;
}
// stop用volatile修饰，可以停止whie死循环
System.out.println("child thread stop");
});
thread.start();
TimeUnit.SECONDS.sleep(5);
stop = false;
}
}
通过运行发现线程并没有停止，main线程修改stop变量，貌似没有起到作用。但是如果使用volatile修饰变量，此问题就会解决。为什么呢？
volatile可以使得在多处理器环境下保证了共享变量的可见性。
1.3 什么是可见性？
在单线程的环境下，如果向一个变量先写入一个值，然后在没有写干涉的情况下读取这个变量的值，那这个时候读取到的这个变量的值应该是之前写入的那个值。这本来是一个很正常的事情。但是在多线程环境下，读和写发生在不同的线程中的时候，可能会出现：读线程不能及时的读取到其他线程写入的最新的值。这就是所谓的可见性。为了实现跨线程写入的内存可见性，必须使用到一些机制来实现，而 volatile 就是这样一种机制。
1.3.1 volatile是如何保证可见性的？
我们可以使用hsdis这个工具，来查看前面演示的这段代码的汇编指令。
工具：下载hsdis-amd64.dll 放在 $JAVA_HOME/jre/bin/server 目录下
配置JVM参数：-server -Xcomp -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:CompileCommand=compileonly,*VolatileDemo.
输出结果：lock add dword ptr [rsp],0h ;*putstatic stop; - com.scarecrow.gupao.day03.VolatileDemo::<clinit>@1 (line 7)
在输出的结果中，会有 lock 指令，会发现在修改带有 volatile 修饰的成员变量时，会多一个 lock 指令。lock是一种控制指令，在多处理器环境下，lock 汇编指令可以基于总线锁或者缓存锁的机制来达到可见性的一个效果。
1.3.2 lock前缀的指令
lock前缀的指令在多核处理器下会引发两件事情：
- 将当前处理器缓存行的数据写回到系统内存。
- 这个写回内存的操作会使在其他cpu里缓存了该内存地址的数据无效。
2. 从硬件层面了解可见性的本质
2.1 计算机发展历史
一台计算机中最核心的组件是 CPU、内存、以及 I/O 设备。在整个计算机的发展历程中，除了 CPU、内存以及 I/O 设备不断迭代升级来提升计算机处理性能之外，还有一个非常核心的矛盾点，就是这三者在处理速度的差异。CPU 的计算速度是非常快的，内存次之、最后是 IO 设备比如磁盘。而在绝大部分的程序中，一定会存在内存访问，有些可能还会存在 I/O 设备的访问。为了提升计算性能，CPU 从单核升级到了多核甚至用到了超线程技术最大化提高 CPU 的处理性能，但是仅仅提升CPU 性能还不够，如果后面两者的处理性能没有跟上，意味着整体的计算效率取决于最慢的设备。为了平衡三者的速度差异，最大化的利用 CPU 提升性能，从硬件、操作系统、编译器等方面都做出了很多的优化。
- CPU 增加了高速缓存
- 操作系统增加了进程、线程。通过 CPU 的时间片切换最大化的提升 CPU 的使用率
- 编译器的指令优化，更合理的去利用好 CPU 的高速缓存
然后每一种优化，都会带来相应的问题，而这些问题也是导致线程安全性问题的根源。为了了解前面提到的可见性问题的本质，我们有必要去了解这些优化的过程。
2.2 CPU高速缓存
线程是 CPU 调度的最小单元，线程设计的目的最终仍然是更充分的利用计算机处理的效能，但是绝大部分的运算任务不能只依靠处理器“计算”就能完成，处理器还需要与内存交互，比如读取运算数据、存储运算结果，这个 I/O 操作是很难消除的。而由于计算机的存储设备与处理器的运算速度差距非常大，所以现代计算机系统都会增加一层读写速度尽可能接近处理器运算速度的高速缓存来作为内存和处理器之间的缓冲：将运算需要使用的数据复制到缓存中，让运算能快速进行，当运算结束后再从缓存同步到内存之中。
通过高速缓存的存储交互很好的解决了处理器与内存的速度矛盾，但是也为计算机系统带来了更高的复杂度，因为它引入了一个新的问题，缓存一致性。
2.3 什么是缓存一致性
首先，有了高速缓存的存在以后，每个 CPU 的处理过程是，先将计算需要用到的数据缓存在 CPU 高速缓存中，在 CPU进行计算时，直接从高速缓存中读取数据并且在计算完成之后写入到缓存中。在整个运算过程完成后，再把缓存中的数据同步到主内存。
由于在多 CPU中，每个线程可能会运行在不同的 CPU 内，并且每个线程拥有自己的高速缓存。同一份数据可能会被缓存到多个 CPU 中，如果在不同 CPU 中运行的不同线程看到同一份内存的缓存值不一样就会存在缓存不一致问题。为了解决缓存不一致的问题，在 CPU 层面做了很多事情，主要提供了两种解决办法。
-
总线锁
总线锁，简单来说就是，在多 cpu 下，当其中一个处理器要对共享内存进行操作的时候，在总线上发出信号，这个信号使得其他处理器无法通过总线来访问到共享内存中的数据，总线锁定把 CPU 和内存之间的通信锁住了，这使得锁定期间，其他处理器不能操作其他内存地址的数据，所以总线锁定的开销比较大，这种机制显然是不合适的。
-
缓存锁
控制锁的保护粒度，我们只需要保证对于被多个 CPU 缓存的同一份数据是一致的就行。所以引入了缓存锁，它核心机制是基于缓存一致性协议来实现的。
2.5 可见性的本质
由于CPU 高速缓存的出现使得如果多个cpu同时缓存了相同的共享数据时，可能存在可见性问题。也就是CPU0修改了自己本地缓存的值对于 CPU1不可见。不可见导致的后果是 CPU1 后续在对该数据进行写入操作时，是使用的脏数据。使得数据最终的结果不可预测。
2.5 缓存一致性
为了达到数据访问的一致，需要各个处理器在访问缓存时遵循一些协议，在读写时根据协议来操作，常见的协议有MSI，MESI，MOSI 等。最常见的就是 MESI 协议。
2.5.1 MESI协议
MESI（Modified Exclusive Shared Or Invalid）是一种广泛使用的支持写回策略的缓存一致性协议。为了保证多个CPU缓存中共享数据的一致性，定义了缓存行(Cache Line)的四种状态，而CPU对缓存行的四种操作可能会产生不一致的状态，因此缓存控制器监听到本地操作和远程操作的时候，需要对地址一致的缓存行的状态进行一致性修改，从而保证数据在多个缓存之间保持一致性。
之所以叫 MESI，是因为这套方案把一个缓存行（cache line）区分出四种不同的状态标记，他们分别是 Modified、Exclusive、Shared 和 Invalid。这四种状态分别具备一定的意义：
在 MESI 协议中，每个cpu缓存的缓存控制器不仅知道自己的读写操作，而且也监听(snoop)其它 Cache 的读写操作，这是总线嗅探机制。
对于MESI协议，从CPU读写角度来说会遵循以下原则：
CPU读请求：缓存处于M、E、S 状态都可以被读取，I 状态CPU只能从主存中读取数据。
CPU写请求：缓存处于 M、E 状态才可以被写。对于 S 状态的写，需要将其他 CPU 中缓存行置为无效才可写。
2.5.2 MESI优化带来的可见性问题
MESI带来的问题：
各个 CPU 缓存行的状态是通过消息传递来进行的。如果CPU0要对一个在缓存中共享的变量（S状态）进行写入，首先需要发送一个失效的消息给到其他缓存了该数据的 CPU。并且要等到他们的确认回执，CPU0 在这段时间内都会处于阻塞状态。这对于频率很高的CPU来说，简直不能接受。执行过程如下
2.5.2.1 Store Buffer
为了解决此问题，cpu层面引入了Store Buffer。此时的执行过程为：
CPU0只需要在写入共享数据时，直接把数据写入到store buffer 中，同时发送 invalidate 消息，然后继续去处理其他指令。当收到其他所有CPU发送了invalidate acknowledge消息时，再将 store buffer 中的数据数据存储至 cache line中。最后再从缓存行同步到主内存。
2.5.2.2 Store Forwarding
引入store buffer之后又带了新的问题，单个 CPU 在顺序执行指令的过程中，有可能出现，前面的已经执行写入变更，但对后面的代码逻辑不可见
a=1
b=a+1
assert(a==2)
cpu对a赋值为1，此时a变量进入到store buffer,缓存中的a还是等于0，此时执行b=a+1得到的结果是b=1,assert不通过。
解决方案就是采用Store Forwarding
对于同一个 CPU 而言，在读取 a 变量的时候，如若发现 Store Buffer中有尚未写入到缓存的数据 a，则直接从 Store Buffer 中读取。这就保证了，逻辑上代码执行顺序，也保证了可见性。
2.5.2.3 优化引发的问题
通过 Store Forwarding 解决了单个 CPU 执行顺序性和内存可见性问题，但是在全局多 CPU 的环境下，这种内存可见性恐怕就很难保证了。
a = 0;
isfinsh = false;
void cpu0run()
{
a = 1;
isfinsh = true;
// 其他操作
}
void cpu1run()
{
while (isfinsh) continue;
assert(a == 1);
// 其他操作
}
假设上面的 cpu0run方法被CPU0执行，cpu1run方法被CPU1执行，也就是我们常说的多线程环境。试想，即便在多线程环境下，cpu0run 和 cpu1run 如若严格按照理想的顺序执行，是无论如何都不会出现 assert failed 的情况的。但往往事与愿违，这种看似很诡异的且有一定几率发生的 assert failed ，结合上面所说的 Store Buffer 就一点都不难理解了。
我们来还原 assert failed 的整个过程，假设 a初始值为0，isfinsh为false，a被CPU0和CPU1共同持有（S状态），isfinsh被CPU0 独占（E状态）；
CPU 0 处理 a=1 之前发送 Invalidate 消息给 CPU1 ，并将其放入 Store Buffer ，尚未及时刷入缓存；
CPU 0 转而处理 isfinsh = true ，此时 isfinsh = true 直接被刷入缓存；
CPU 1 发出 Read 消息读取 isfinsh 的值，发现 isfinsh = true ，跳出 while 语句；
CPU 1 发出 Read 消息读取 a 的值，发现 a 却为旧值 0，assert failed。
在日常开发过程中也是完全有可能遇到上面的情况，由于 a 的变更对 CPU1 不可见，虽然执行指令的时序没有真正被打乱，但对于 CPU1 来说，这造成了
isfinsh = true 先于 a=1 执行的假象，这种看是乱序的问题，通常称为 “重排序”。当然上面所说的情况，只是指令重排序的一种可能。
2.5.2.4 Memory Barriers
从硬件层面很难去知道软件层面上的这种前后依赖关系，所以没有办法通过某种手段自动去解决。所以在 CPU 层面提供了 memory barrier(内存屏障)的指
令，从硬件层面来看这个 memroy barrier 就是 CPU flush store bufferes 中的指令。软件层面可以决定在适当的地方来插入内存屏障。
什么是内存屏障?
从前面的内容基本能有一个初步的猜想，内存屏障就是将 store bufferes 中的指令写入到内存，从而使得其他访问同一共享内存的线程的可见性。
X86 的 memory barrier 指令包括 lfence(读屏障) sfence(写屏障) mfence(全屏障)
- Store Memory Barrier(写屏障) 处理器在写屏障之前的所有已经存储在存储缓存(store bufferes)中的数据同步到主内存，简单来说就是使得写屏障之前指令的结果对屏障之后的读或者写是可见的。
- Load Memory Barrier(读屏障) 处理器在读屏障之后的读操作,都在读屏障之后执行。配合写屏障，使得写屏障之前的内存更新对于读屏障之后的读操作是可见的。
- Full Memory Barrier(全屏障) 确保屏障前的内存读写操作的结果提交到内存之后，再执行屏障后的读写操作。
有了内存屏障以后，对于上面这个例子，我们可以这么来改，从而避免出现可见性问题。
a = 0;
isfinsh = false;
void cpu0run()
{
a = 1;
// 写屏障，使得isfinsh写会主内存
Store Memory Barrier();
isfinsh = true;
// 其他操作
}
void cpu1run()
{
while (isfinsh) continue;
// 读屏障，使得CPU1从主内存获得isfinsh的最新数据
assert(a == 1);
// 其他操作
}
总的来说，内存屏障的作用可以通过防止 CPU 对内存的乱序访问来保证共享数据在多线程并行执行下的可见性但是这个屏障怎么来加呢？回到最开始我们讲 volatile 关键字的代码，这个关键字会生成一个 Lock 的汇编指令，这个指令其实就相当于实现了一种内存屏障。
3 JMM(JAVA内存模型)
内存屏障、重排序这些东西好像是和平台以及硬件架构有关系的。作为 Java 语言的特性，一次编写多处运行。我们不应该考虑平台相关的问题，并且这些所谓的内存屏障也不应该让程序员来关心。因此引入了JMM
3.1 什么是JMM
JMM 全称是 Java Memory Model。通过前面的分析发现，导致可见性问题的根本原因是缓存以及重排序。 而 JMM 实际上就是提供了合理的禁用缓存以及禁止重排序的方法。所以它最核心的价值在于解决可见性和有序性。
JMM 属于语言级别的抽象内存模型，可以简单理解为对硬件模型的抽象，它定义了共享内存中多线程程序读写操作的行为规范：在虚拟机中把共享变量存储到内存以及从内存中取出共享变量的底层实现细节。通过这些规则来规范对内存的读写操作从而保证指令的正确性，它解决了CPU多级缓存、处理器优化、指令重排序导致的内存访问问题，保证了并发场景下的可见性。
需要注意的是，JMM并没有限制执行引擎使用处理器的寄存器或者高速缓存来提升指令执行速度，也没有限制编译器对指令进行重排序。也就是说在 JMM 中，也会存在缓存一致性问题和指令重排序问题。只是JMM把底层的问题抽象到JVM层面，再基于 CPU 层面提供的内存屏障指令，以及限制编译器的重排序来解决并发问题。
JMM 抽象模型分为主内存、工作内存；主内存是所有线程共享的，一般是实例对象、静态字段、数组对象等存储在堆内存中的变量。工作内存是每个线程独占的，线程对变量的所有操作都必须在工作内存中进行，不能直接读写主内存中的变量，线程之间的共享变量值的传递都是基于主内存来完成。
3.2 JMM 是如何解决可见性有序性问题的
简单来说，JMM 提供了一些禁用缓存以及进制重排序的方法，来解决可见性和有序性问题。这些方法大家都很熟悉：volatile、synchronized、final。
3.3 重排序
为了提高程序的执行性能，编译器和处理器都会对指令做重排序。所谓的重排序其实就是指执行的指令顺序。
编译器的重排序指的是程序编写的指令在编译之后，指令可能会产生重排序来优化程序的执行性能。
编译器的重排序指的是程序编写的指令在编译之后，指令可能会产生重排序来优化程序的执行性能。
上述的1属于编译器重排序，2 和 3 属于处理器重排序，这些重排序可能会导致多线程程序的内存可见性问题。
编译器的重排序，JMM 提供了禁止特定类型的编译器重排序。
处理器重排序，JMM 会要求编译器生成指令时，会插入内存屏障来禁止处理器重排序。
当然并不是所有的程序都会出现重排序问题
编译器的重排序和 CPU 的重排序的原则一样，会遵守数据依赖性原则，编译器和处理器不会改变存在数据依赖关系的两个操作的执行顺序。
a=1; b=a;
a=1; a=2;
a=b; b=1;
以上这三种情况在单线程里面如果改变代码的执行顺序，都会导致结果不一致，所以重排序不会对这类的指令做优化。
3.4 as-if-serial
不管怎么重排序，对于单个线程来说执行结果不能改变。
为了遵守as-if-serial协议，编译器和处理器不会对存在数据依赖关系的两个操作的执行顺序。为了遵守as-if-serial语义，编译器和处理器不会对存在数据依赖关系的操作做重排序，因为这种重排序会改变执行结果。如果不存在数据依赖关系，这些操作久可能被编译器和处理器重排序。
int a=2; //1
int b=3; //2
int rs=a*b; //3
1 和 3、2 和 3 存在数据依赖，所以在最终执行的指令中，3 不能重排序到 1 和 2 之前，否则程序会报错。由于 1 和 2不存在数据依赖，所以可以重新排列 1 和 2 的顺序。
3.5 Java 层面的内存屏障
为了保证内存可见性，Java 编译器在生成指令序列的适当位置会插入内存屏障来禁止特定类型的处理器的重排序，在 JMM 中把内存屏障分为四类。
3.6 Happen-Before
如果前一个操作的结果对于后续操作是可见的，那么这两个操作之间必须存在Happen-Before关系。这里提到的两个操作既可以在一个线程内，也可以在不同的线程之间。
A happen-before B，JMM并不要求A一定要在B之前执行，Happens-Before仅仅要求前一个操作（执行结果）对后一个操作可见。且前一个操作按顺序排在第二个操作之前。
- 程序顺序规则：一个线程中的每个操作，happens-before于该线程中的任意后续操作。
- 监视器锁规则：对一个锁的解锁，happens-before于随后对这个锁的加锁。
- volatile变量规则：对一个volatile域的写，happens-before于任意后续对这个volatile域的读。
- 传递性：如果A happens-before B，且B happens-before C，那么A happens-before C。
- start()规则：如果线程A执行操作ThreadB.start()（启动线程B），那么A线程的ThreadB.start()操作happens-before于线程B中的任意操作。
- Join()规则：如果线程A执行操作ThreadB.join()并成功返回，那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回。
3.7 volatile
volatile 限制以下重排序
