Java内存模型
Java 内存模型（JMM）是一种抽象的概念，并不真实存在，它描述了一组规则或规范，通过这组规范定义了程序中各个变量（包括实例字段、静态字段和构成数组对象的元素）的访问方式。试图屏蔽各种硬件和操作系统的内存访问差异，以实现让 Java 程序在各种平台下都能达到一致的内存访问效果。
注意JMM与JVM内存区域划分的区别：
JMM描述的是一组规则，围绕原子性、有序性和可见性展开；
相似点：存在共享区域和私有区域
主内存与工作内存
处理器上的寄存器的读写的速度比内存快几个数量级，为了解决这种速度矛盾，在它们之间加入了高速缓存。
加入高速缓存带来了一个新的问题：缓存一致性。如果多个缓存共享同一块主内存区域，那么多个缓存的数据可能会不一致，需要一些协议来解决这个问题。
所有的变量都存储在主内存中，每个线程还有自己的工作内存，工作内存存储在高速缓存或者寄存器中，保存了该线程使用的变量的主内存副本拷贝。
线程只能直接操作工作内存中的变量，不同线程之间的变量值传递需要通过主内存来完成。
数据存储类型以及操作方式
方法中的基本类型本地变量将直接存储在工作内存的栈帧结构中；
引用类型的本地变量：引用存储在工作内存，实际存储在主内存；
成员变量、静态变量、类信息均会被存储在主内存中；
主内存共享的方式是线程各拷贝一份数据到工作内存中，操作完成后就刷新到主内存中。
内存间交互操作
Java 内存模型定义了 8 个操作来完成主内存和工作内存的交互操作。
-
read：把一个变量的值从主内存传输到工作内存（CPU级别的缓存）中
-
load：在 read 之后执行，把 read 得到的值放入工作内存的变量副本中
-
use：把工作内存中一个变量的值传递给执行引擎
-
assign：把一个从执行引擎接收到的值赋给工作内存的变量
-
store：把工作内存的一个变量的值传送到主内存中
-
write：在 store 之后执行，把 store 得到的值放入主内存的变量中
-
lock：作用于主内存的变量
-
unlock
内存模型三大特性
原子性
// 先看一下代码：
public class Main {
private static int cnt = 0;
public static void main(String[] args) {
Runnable runnable = () -> {
for (int j = 0; j < 100; j++) {
cnt++;
try {
Thread.sleep(30);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
System.out.println(cnt);
};
new Thread(runnable).start();
new Thread(runnable).start();
}
}
// 发现上面代码输出并没有等于200；
Java 内存模型保证了 read、load、use、assign、store、write、lock 和 unlock 操作具有原子性，例如对一个 int 类型的变量执行 assign 赋值操作，这个操作就是原子性的。但是 Java 内存模型允许虚拟机将没有被 volatile 修饰的 64 位数据（long，double）的读写操作划分为两次 32 位的操作来进行，即 load、store、read 和 write 操作可以不具备原子性。
有一个错误认识就是，int 等原子性的类型在多线程环境中不会出现线程安全问题。前面的线程不安全示例代码中，cnt 属于 int 类型变量，2 个线程对它进行自增操作之后，得到的值为 1 而不是 2。
为了方便讨论，将内存间的交互操作简化为 3 个：load、assign、store。
下图演示了两个线程同时对 cnt 进行操作，load、assign、store 这一系列操作整体上看不具备原子性，那么在 T1 修改 cnt 并且还没有将修改后的值写入主内存，T2 依然可以读入旧值。可以看出，这两个线程虽然执行了两次自增运算，但是主内存中 cnt 的值最后为 1 而不是 2。因此对 int 类型读写操作满足原子性只是说明 load、assign、store 这些单个操作具备原子性。
AtomicInteger 能保证多个线程修改的原子性。
使用 AtomicInteger 重写之前线程不安全的代码之后得到以下线程安全实现：
import java.util.concurrent.atomic.AtomicInteger;
public class Main {
private static AtomicInteger cnt = new AtomicInteger();
public static void main(String[] args) {
Runnable runnable = () -> {
for (int j = 0; j < 100; j++) {
cnt.getAndIncrement();
try {
Thread.sleep(30);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
System.out.println(cnt.get());
};
new Thread(runnable).start();
new Thread(runnable).start();
}
}
除了使用原子类之外还可以使用 synchronized 互斥锁来保证操作的原子性。它对应的内存间交互操作为：lock 和 unlock，在虚拟机实现上对应的字节码指令为 monitorenter 和 monitorexit。
public class Main1 {
private static int cnt = 0;
public synchronized void add() {
cnt++;
}
public static void main(String[] args) {
Main1 main1 =new Main1();
Runnable runnable = () -> {
for (int j = 0; j < 100; j++) {
main1.add();
try {
Thread.sleep(30);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
System.out.println(cnt);
};
new Thread(runnable).start();
new Thread(runnable).start();
}
}
可见性
可见性指当一个线程修改了共享变量的值，其它线程能够立即得知这个修改。Java 内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值来实现可见性的。
主要有有三种实现可见性的方式：
volatile，会强制将该变量自己和当时其他变量的状态都刷出缓存。
synchronized，对一个变量执行 unlock 操作之前，必须把变量值同步回主内存。
final，被 final 关键字修饰的字段在构造器中一旦初始化完成，并且没有发生 this 逃逸（其它线程通过 this 引用访问到初始化了一半的对象），那么其它线程就能看见 final 字段的值。
对前面的线程不安全示例中的 cnt 变量使用 volatile 修饰，不能解决线程不安全问题，因为 volatile 并不能保证操作的原子性。
有序性
有序性是指：在本线程内观察，所有操作都是有序的。在一个线程观察另一个线程，所有操作都是无序的，无序是因为发生了指令重排序。在 Java 内存模型中，允许编译器和处理器对指令进行重排序，重排序过程不会影响到单线程程序的执行，却会影响到多线程并发执行的正确性。
简单来说：对于代码有个问题就是指令重排序，编译器和指令器有时候为了提高代码执行效率会将指令重新排序。
flag = false;
//线程1：
//准备资源
prepare()
flag = true;
//线程2：
while(!flag){
Thread.sleep(1000)
}
//基于准备好的资源执行操作
execute()
指令重排序后，让flag=true 先执行了，会导致线程2 直接跳过while等待，执行某段代码，结果prepare()方法还没有执行，资源没有准备好，此时就会导致代码逻辑出现异常！
JMM 内部的实现通常是依赖于所谓的内存屏障，通过禁止某些重排序的方式，提供内存可见性保证，也就是实现了各种 happen-before 规则。与此同时，更多复杂度在于，需要尽量确保各种编译器、各种体系结构的处理器，都能够提供一致的行为。
先行发生原则(Happen-Before)
JSR-133内存模型使用先行发生原则在Java内存模型中保证多线程操作可见性的机制，也是对早期语言规范中含糊的可见性概念的一个精确定义。上面提到了可以用 volatile 和 synchronized 来保证有序性。除此之外，JVM 还规定了先行发生原则，让一个操作无需控制就能先于另一个操作完成。
由于指令重排序的存在，两个操作之间有happen-before关系，并不意味着前一个操作必须要在后一个操作之前执行。 仅仅要求前一个操作的执行结果对于后一个操作是可见的，并且前一个操作 按顺序 排在第二个操作之前。
- 单一线程原则（程序员顺序规则）Single Thread rule
在一个线程内，按照代码顺序，书写在程序前面的操作先行发生于书写后面的操作。
- 管程锁定规则（监视器锁规则）Monitor Lock Rule
一个 unlock（解锁） 操作先行发生于后面对同一个锁的 lock（加锁）操作。比如代码里面先对一个lock.lock()然后lock.unlock(),然后lock.lock()
- volatile 变量规则 Volatile Variable Rule
对一个 volatile 变量的写操作先行发生于后面对这个变量的读操作。
- 线程启动规则Thread Start Rule
Thread 对象的 start() 方法调用先行发生于此线程的每一个动作。比如Thread.start() interrupt()
- 线程加入规则 Thread Join Rule
Thread 对象的结束先行发生于 join() 方法返回。
- 线程中断规则 Thread Interruption Rule
对线程 interrupt() 方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过 interrupted() 方法检测到是否有中断发生。
- 对象终结规则 Finalizer Rule
一个对象的初始化完成（构造函数执行结束）先行发生于它的 finalize() 方法的开始。
- 传递性 Transitivity
如果操作 A 先行发生于操作 B，操作 B 先行发生于操作 C，那么操作 A 先行发生于操作 C。
总结：这些规则制定了在一些特殊情况下，不允许编译机，指令器对你写的代码进行指令重排，必须保证你的代码的有序性
指令重排序的条件
-
在单线程环境下不能改变程序的运行结果；
-
存在数据依赖关系的不允许重排序；
-
无法通过Happens-before原则推到出来的，才能进行指令的重排序。
volatile
可见性
public class Main {
private volatile static int i = 0;
public static void main(String[] args) {
new Thread(()->{
i++ ;
}).start();
new Thread(()->{
// volatile 修饰后 当线程1 操作i++ 刷新到主内存中后，会让线程2工作内存的缓存失效
// 此时会读取到 i=1
while (i ==0){ Thread.sleep(1000); }
i++ ;
}).start();
}
}
常用场景：一个系统 中间连接各种中间件系统，不能直接结束主进程，在结束主进程的时候要把里面的各个中间件系统关闭后，在结束主进程，不然可能会消息丢失，或者数据不一致等现象.
public class Kafka{
private volatile boolean running =true ;
// 这是一个接口
public void shutdown(){
//关闭这个系统了，shutdown.sh脚本，来调用这个shutdown接口
// 最后运行状态置为false
running =false ;
}
public static void main(){
//启动kafka , rocketmq ,会运行一大堆代码，中间件系统不能直接停掉
Kafka kafka= new Kafka();
// 监控kafka 是否关闭 ，未关闭则需要等待！
while(kafka.running){
Thread.sleep(1000);
}
}
}
如果不加volatile修饰 ，则有可能一直不会关闭，拿到的running状态 一直是true
有序性
前面的案例使用volatile 优化后
volatile boolean flag = false;
//线程1：
//准备资源
prepare()
flag = true;
//线程2：
while(!flag){
Thread.sleep(1000)
}
//基于准备好的资源执行操作
execute()
比如这个例子，如果使用 volatile来修饰flag变量，一定可以让prepare() 在flag = true;之前先执行，这就禁止指令重排，因为volatile变量规则要求的是，volatile前面的代码一定不能指令重排到volatile变量操作后面，volatile后面的代码也不能指令重排到volatile前面
也可以通过 synchronized 来保证有序性，它保证每个时刻只有一个线程执行同步代码，相当于是让线程顺序执行同步代码。
原子性
volatile 不能保证原子性，在有些情况下，可以有限的保证原子性，它主要不是用来保证原子性的！ 比如oracle 64位的long 数字进行操作的时候
保证原子性还是需要synchronized，lock 进行加锁
原理
volatile 关键字通过添加内存屏障的方式来禁止指令重排，即重排序时不能把后面的指令放到内存屏障之前。
- lock指令（保证可见性）
对 volatile修饰的变量,执行写操作的话,JVM会发送一条lock前缀指令给CPU,CPU在计算完之后会立即将这个值写回主内存,同时因为有MESI缓存一致性协议,所以各个CPU都会对总线进行嗅探,自己本地缓存中的数据是否被别人修改如果发现别人修改了某个缓存的数据,那么CPU就会将自己本地缓存的数据过期掉,然后这个CPU上执行的线程在读取那个变量的时候,就会从主内存重新加载最新的数据了
- 内存屏障：禁止重排序（保证有序性）
Load1:
int localVar = this.variable;
Load2:
int localVar = this.variable2;
Loadload屏障:Load1; LoadLoad;Load2,确保Load1数据的装载先于Load2后所有装载指令,他的意思,Load1对应的代码和Load2对应的代码,是不能指令重排的
Store1:
this.variable=1;
StoreStore屏障
Store2:
this.variable2=2;
StoreStore屏障: Store1; StoreStore; Store2,确保 Store1的数据一定刷回主存,对其他cpu 可见,先于 Store2以及后续指令
LoadStore屏障:Load1; LoadStore; Store2,确保Load1指令的数据装载,先于 Store2以及 后续指令
Storeload屏障: Store1; Storeload;Load2,确保 Store1指令的数据一定刷回主存,对其他 cpu可见,先于Load2以及后续指令的数据装载
作用
volatile variable =1
this variable=2=> store操作
int localvariable= this variable=>load操作
对于 volatile修改变量的读写操作,都会加入内存屏障,每个 volatile写操作前面,加 Store Store屏障,禁止上面的普通写和他重排;每个 volatile写操作后面,加 Storeload屏障,禁止跟下面的 volatile读/写重排←
本文由 小马哥 创作，采用 知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名
最后编辑时间为:
2021/09/03 10:56
