JUC 进阶成神系列07—共享模型之内存

Java 内存模型

让开发人员直接面对底层内存管理太复杂，因此抽象内存概念。

JVM 即 Java Memory Model，它定义了主存、工作内存抽象概念，底层对应着 CPU 寄存器、缓存、硬件内存、CPU 指令优化等。

JMM 体现在以下三个方面：
原子性：保证指令不会受到线程上下文切换的影响。
可见性：保证指令不会受 CPU 指令并行优化的影响。
有序性：保证指令不会受 CPU 缓存的影响。

可见性

现象：main 线程对 run 变量的修改对于 t 线程不可见，导致 t 线程无法停止。
分析

1. 初始状态，t 线程刚开始从主内存读取了 run 的值到工作内存。
2. 因为 t 线程要频繁从主内存中读取 run 的值(程序里的读取是循环，如果每次都要去内存中读取，效率低，因此有了 JIT 后续的工作)，JIT 编译器会将 run 的值缓存至自己工作内存中的高速缓存中，减少对主存中 run 的访问，提高效率。
3. 1 秒之后，main 线程修改了 run 的值，并同步主存，而 t 是从自己工作内存中的高速缓存中读取这次变量的值，结果永远是旧值。
   解决办法：volatile(易变关键字)用来修饰成员变量和静态成员变量(不能修饰局部变量，局部变量是线程私有的)，可以避免线程从自己的工作缓存中查找变量的值，必须到主存中获取它的值，线程操作 volatile 变量都是直接操作主存。

可见性vs原子性
上面的例子体现的是可见性，它保证的是在多个线程之间，一个线程对 volatile 变量的修改对另一个线程可见，不能保证原子性，仅用在一个写线程，多个读线程的情况(只能保证读取的是最新值，不能解决指令交错)后。
synchronized 语句块既可以保证代码块的原子性，也同时保证代码块内变量的可见性。缺点是：属于重量级操作，要创建 monitor，性能相对更低。

CPU缓存结构

有序性

JVM 会在不影响正确性的前提下，调整语句的执行顺序。这种特性称之为指令重排。多线程下指令重排会影响正确性。用下面的原理帮助理解。

指令级并行原理
1.名词
Clock Cycle Time(cpu 的时钟周期时间)，等于主频的倒数，是 cpu 能识别的最小时间单位，比如 4G 主频的 cpu 的 Clock Cycle Time 就是 0.25ns，作为对比，我们墙上挂钟的 Cycle time 是 1s。例如，运行一条加法指令一般需要一个时钟周期时间。
CPI(Cycle Per Instruction)指令平均时钟周期数，因为有的指令需要更多的时钟周期时间而引入。
IPC 即 CPI 的倒数，表示每个时钟周期能够运行的指令数。
CPU 执行时间，即程序的 CPU 执行时间，即前面提到的 user+system，用下面的公式表示：2.指令重排序优化
现代处理器会为一个时钟周期完成一条执行时间最长的 CPU 指令。可以这么做的原因：指令可以划分成一个个更小的阶段，比如每条指令都可以分为：取指令-指令译码-执行指令-内存访问-数据写回这 5 个阶段。在不改变程序结果的前提下，这些指令的各个阶段可以通过重排序和组合实现指令级并行，相当于提高了并发度，提高了 cpu 指令级别的并发度，java 层面是一个道理。指令重排前提是，重排指令不能影响结果，比如下一条指令依赖上一条指令结果就不能重排。

术语参考：IF-instruction fetch、ID-instruction decode、EX-execute、MEM-memory access、WB-register write back

解决指令重排引起结果错误的办法

volatile 修饰的变量，可以禁止指令重排。

volatile 原理

volatile的底层实现原理是内存屏障,Memory Barrier(Memory Fence)。
对volatile变量的写指令后加入写屏障。
对volatile变量的读指令前加入读屏障。

1. 如何保证可见性
   写屏障(sfence)保证在该屏障之前，对共享变量的改动(改动即赋值)，都同步到主存当中。
   读屏障(lfence)保证在该屏障之后，对共享变量的读取，加载的是主存中最新数据。
   
2. 如何保证有序性
   写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后。
   读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前。
   不能解决指令交错：写屏障仅仅是保证之后的读能够读到最新的结果，但不能保证读到它前面去，比如更新在读取以后。而有序性的保证也只是保证了本线程内相关代码(不能保证线程间)不被重排序，比如t2线程提前读了，写还没进行，读的也不是最新的。
3. double-checked locking 问题
   以著名的 double-checked locking 单例模式为例。
   以上的实现特点是：
   1.懒惰实例化。
   2.首次使用 getinstance() 才使用 synchronized 加锁，后续使用时无需加锁。
   3.有隐含的，但很重要的一点：第一个 if 使用了 INSTANCE 变量，在同步块外，意味着加 synchronized 也是无法管理它重排序问题。

针对 3 锁类对象，每次进入同步代码块都要对单例对象进行安全保护，只有第一需要，后面就不需要，3 里每次都要检查单例对象是否为空，其实只有第一次需要检查，这种其实就是有很大性能损耗。能不能把作用范围缩小？使得只有第一次加 synchronized 互斥，以后就不用加了。
第一次才会进入 synchronized 块，第二次发现单例对象不为空，那就不会进入synchronized块，提升性能。实现首次访问会同步，而之后的使用没有 synchronize。实际上是有问题的没有考虑同步代码块外的 if 的 INSTANCE 的变量的原子有序性，也存在指令重排问题。
因此在多线程环境下，上面的代码是有问题的，getinstance 方法对应的字节码为：
其中：17 表示创建对象，将对象引用入栈 //new Singleton。20 表示复制一份对象引用//引用地址。21 表示利用一个对象引用，调用构造方法。24 表示利用一个对象引用，赋值给 static INSTANCE。也许 JVM 会优化为先执行 24 再执行 21，先赋值再调无参数构造。如果两个线程 t1,t2 按时间序列执行：
关键在于 0:get static 这行代码在 monitor 控制之外，它就像之前举例中不守规则的人，可以越过 monitor 读取 INSTANCE 变量的值。这时 t1 还未完全将构造方法执行完毕，如果在构造方法中要执行很多初始化操作，那么 t2 拿到的是将是一个未初始化完毕的单例。对INSTANCE使用 volatile 修饰即可，可以禁用指令重排，但要注意在 JDK 5 以上的版本的 volatile 才会真正有效。
4. double-checked locking 解决
加 volatile字节码上看不出来 volatile 指令效果，只能从底层看，从读写屏障角度分析。

读写 volatile 变量会加入内存屏障，保证可见性和有序性。更底层的是读写变量时使用 lock 指令来多核 CPU 之间的可见性与有序性。
可见性：
写屏障保证该屏障之前的 t1 对共享变量的改动，都同步到主存当中。
读屏障保证该屏障之后的 t2 对共享变量的读取，加载的是主存中最新数据。
有序性：
写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后。
读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前。

happens-before

happens-before 规定了对共享变量的写操作对其他线程的读写操作可见，它是可见性与有序性的一套规则总结。

抛开以下 happens-before 规则，JMM 并不能保证一个线程对共享变量的写，对于其他线程对该共享变量的读可见。
线程解锁 m 之前对变量的写，对于接下来对 m 加锁的其他线程对该变量的读可见。

线程对 volatile 变量的写(写入主存中，读写操作都是以主存中去读)，对接下来其他线程对该变量的读可见。
线程 start 前对变量的写，对该线程开始后(线程还没启动写入的变量，在线程启动以后)对该变量的读可见。
线程结束前对变量的写，符号其他线程得知它结束后的读可见(比如其他线程调用 t1.isAlive() 或 t1.join() 等待它结束)。

线程结束前，就会把共享变量的值同步到主存中，使其他线程看得到。

线程 t1 打断 t2(interrupt) 前对变量的写，对于其他线程得知 t2 被打断后对变量的读可见(通过 t2.interrupted 果 t2.isinterrupted)。
对变量默认值 (0,false,null) 的写，对其他线程对该变量的读可见。
具有传递性，如果 x hb->y 并且 y hb->z 那么有 x hb->z，配合 volatile 的防指令重排，有下面的例子：