硬件内存模型
Java 内存模型
- 主内存
- 工作内存
- 内存交互的八个原子操作
- JMM作用
可见性
- 退不出的循环
- volatile解决
- 同步模式之 Balking
有序性
- 指令重排
- 解决指令重排
volatile 原理
- volatile如何保证可见性
- volatile如何保证有序性
- volatile 不能解决指令交错
- double-checked locking 问题
- double-checked locking 解决
happens-before原则

硬件内存模型

计算机系统处理任务主要是靠处理器(CPU)来进行运算的，而运算中又会涉及到数据，数据在哪呢，数据自然是存储在计算机内存中，所以处理器在运算过程中不可避免的会涉及到与内存的读写交互，比如读取运算所需的数据，存储运算得到的数据结果等。

为什么要有内存模型？

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UrNQZHli-1688559397203)(./imgs/4-6.png)]

开始CPU是直接和主存进行交互的，但这样会有一个很大的问题，CPU的计算速度非常快，而主存是硬盘操作，比起CPU会慢很多，有时候CPU需要等待主存，导致效率很低。所以在CPU和主存之间加一个高速缓存作为缓冲，虽然高速缓存和CPU之间还存在速度差别，但比直接访问主存的效率高的多。

但是也带来了问题：因为两个线程都从自己的就是两个线程的缓存一致性问题。这就是JMM要解决的问题。

Java 内存模型

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

在这里插入图片描述

主内存

Java内存模型中规定所有变量都存储在主内存(虚拟机内存的一部分)中，主要对应Java的堆内存。这里提到的变量实际上是指共享变量，存在线程间竞争的变量，如：实例变量、静态变量和构成数组对象的元素，而局部变量和方法参数因为是线程私有的，不存在线程间共享和竞争关系，所以也就不在前面提到的变量范围内。

工作内存

每个线程有着自己独有的工作内存，工作内存中保存了被该线程使用到的变量，这些变量来自主内存变量的副本拷贝。线程对变量的所有读写操作都必须在工作内存中进行，不能直接读写主内存中的变量。而不同线程间的工作内存也是独立的，一个线程无法访问其他线程的工作内存中的变量。

线程工作时，把需要的变量从主内存中拷贝到自己的工作内存，线程运行结束之后再将自己工作内存中的变量写回到主内存中，而多个线程间对变量的交互只能通过主内存作为媒介来实现。

内存交互的八个原子操作

线程从主内存中读取一个变量到自己的工作内存，线程结束时再把这个变量写回主内存中，是需要经过以下8个操作。（按顺序）

lock（锁定）：将一个变量标识成线程独有状态。
read（读取）：将变量的值读取到线程的工作内存中。
load（加载）：将读取到的值指向工作内存中变量副本。
use（使用）：把工作内存中的一个变量值传递给执行引擎。
assign（赋值）：将执行引擎收到的值赋值给变量副本。
store（存储）：将变量副本的值传递到主内存。
write（写入）：将值赋值给主内存的变量。
unlock（解锁）：将锁定的变量解锁。

这些操作需要按顺序执行，可以不连续执行，比如read和load之间可以夹杂其他操作。lock可选。

在这里插入图片描述

指令规则

read 和 load、store和write必须成对出现
assign操作，工作内存变量改变后必须刷回主内存
同一时间只能运行一个线程对变量进行lock，当前线程lock可重入，unlock次数必须等于lock的次数，* 该变量才能解锁。
对一个变量lock后，会清空该线程工作内存变量的值，重新执行load或者assign操作初始化工作内存中* 变量的值。
unlock前，必须将变量同步到主内存（store/write操作）

JMM作用

规范了Java虚拟机与计算机内存是如何协同工作的：一个线程如何与何时可以看到由其他线程修改过后的共享变量的值，以及在必须时如何同步的访问共享变量。目的是为了屏蔽掉不同硬件和操作系统的内存访问差异，实现各种平台具有一致的并发效果。

主要体现在以下几个方面：

原子性 - 保证指令不会受到线程上下文切换的影响
可见性 - 保证指令不会受 cpu 缓存的影响
有序性 - 保证指令不会受 cpu 指令并行优化的影响

原子性在前面已经在介绍synchronized讲过，下面了解下可见性和有序性。

可见性

退不出的循环

先来看一个现象，main 线程对 run 变量的修改对于 t 线程不可见，导致了 t 线程无法停止：

import lombok.extern.slf4j.Slf4j;


@Slf4j
public class VolatileTest01 {
    static boolean run = true;
    public static void main(String[] args) throws InterruptedException {
        Thread t = new Thread(()->{
            while(run){
                // ....
            }
        });
        t.start();
        Thread.sleep(1000);
        log.info("开始停止线程t");
        run = false;
    }
}

上面的程序，虽然在主线程中试图改变run来停止线程t，但是线程t不会如预想的停下来。

这是为什么呢？过程如下：

初始状态， t 线程刚开始从主内存读取了 run 的值到工作内存。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GYMwU2wG-1688559397204)(./imgs/4-1.png)]

因为 t 线程要频繁从主内存中读取 run 的值，JIT 编译器会将 run 的值缓存至自己工作内存中的高速缓存中，减少对主存中 run 的访问，提高效率

在这里插入图片描述

1 秒之后，main 线程修改了 run 的值，并同步至主存，而 t 是从自己工作内存中的高速缓存中读取这个变量的值，结果永远是旧值。

在这里插入图片描述

volatile解决

volatile它可以用来修饰成员变量和静态成员变量，他可以避免线程从自己的工作缓存中查找变量的值，必须到主存中获取它的值，线程操作 volatile 变量都是直接操作主存。

如下：

import lombok.extern.slf4j.Slf4j;

@Slf4j
public class VolatileTest01 {
    volatile static boolean run = true;
    public static void main(String[] args) throws InterruptedException {
        Thread t = new Thread(()->{
            while(run){
                // ....
            }
        });
        t.start();
        Thread.sleep(1000);
        log.info("开始停止线程t");
        run = false;
    }
}

这样线程t可以正常的停下来了。

其实synchronized也可以解决这个问题。但是synchronized是使用monitor，比较重量级，但是volatile是比较轻量级的。

注意：

前面例子体现的实际就是可见性，它保证的是在多个线程之间，一个线程对 volatile 变量的修改对另一个线程可见，不能保证原子性，仅用在一个写线程，多个读线程的情况
synchronized 语句块既可以保证代码块的原子性，也同时保证代码块内变量的可见性。但缺点是synchronized 是属于重量级操作，性能相对更低

同步模式之 Balking

Balking （犹豫）模式用在一个线程发现另一个线程或本线程已经做了某一件相同的事，那么本线程就无需再做了，直接结束返回。

public class MonitorService {
 // 用来表示是否已经有线程已经在执行启动了
 private volatile boolean starting;
 public void start() {
 log.info("尝试启动监控线程...");
 synchronized (this) {
 if (starting) {
 return;
 }
 starting = true;
 }
 
 // 真正启动监控线程...
 }
}

它还经常用来实现线程安全的单例

public final class Singleton {
 private Singleton() {
 }
 private static Singleton INSTANCE = null;
 public static synchronized Singleton getInstance() {
 if (INSTANCE != null) {
 return INSTANCE;
 }
 
 INSTANCE = new Singleton();
 return INSTANCE;
 }
}

对比一下保护性暂停模式：保护性暂停模式用在一个线程等待另一个线程的执行结果，当条件不满足时线程等待。

有序性

指令重排

JVM 会在不影响正确性的前提下，可以调整语句的执行顺序。

思考下面一段代码

static int i;
static int j;
// 在某个线程内执行如下赋值操作
i = ...; 
j = ...;

可以看到，至于是先执行 i 还是先执行 j ，对最终的结果不会产生影响。所以，上面代码真正执行时，既可以是

i = ...; 
j = ...;

也可以是

j = ...;
i = ...;

这种特性称之为指令重排，多线程下指令重排会影响正确性。

为什么要有重排指令这项优化呢？

CPU执行指令时，又可以再划分成一个个更小的阶段，例如，每条指令都可以分为：取指令 - 指令译码 - 执行指令 - 内存访问 - 数据写回这 5 个阶段。在不改变程序结果的前提下，这些指令的各个阶段可以通过重排序和组合来实现指令级并行。

指令重排的前提是，重排指令不能影响结果。

现代 CPU 支持多级指令流水线，例如支持同时执行取指令 - 指令译码 - 执行指令 - 内存访问 - 数据写回的处理
器，就可以称之为五级指令流水线。这时 CPU 可以在一个时钟周期内，同时运行五条指令的不同阶段（相当于一
条执行时间最长的复杂指令），IPC = 1，本质上，流水线技术并不能缩短单条指令的执行时间，但它变相地提高了
指令地吞吐率。

解决指令重排

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

public class ConcurrencyTest {
   int num = 0;
   volatile boolean ready = false;
  
   @Actor
   public void actor1(I_Result r) {
       if(ready) {
       		r.r1 = num + num;
       } else {
       		r.r1 = 1;
       }
   }
  
   @Actor
   public void actor2(I_Result r) {
       num = 2;
       ready = true;
   }
}

volatile 原理

volatile 的底层实现原理是内存屏障，Memory Barrier（Memory Fence）

对 volatile 变量的写指令后会加入写屏障
对 volatile 变量的读指令前会加入读屏障

volatile如何保证可见性

写屏障（sfence）保证在该屏障之前的，对共享变量的改动，都同步到主存当中

public void actor2(I_Result r) {
   num = 2;
   ready = true; // ready 是 volatile 赋值带写屏障
   // 写屏障
}

而读屏障（lfence）保证在该屏障之后，对共享变量的读取，加载的是主存中最新数据

public void actor1(I_Result r) {
   // 读屏障
   // ready 是 volatile 读取值带读屏障
   if(ready) {
   		r.r1 = num + num;
   } else {
   		r.r1 = 1;
   }
}

volatile如何保证有序性

写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后

public void actor2(I_Result r) {
   num = 2;
   ready = true; // ready 是 volatile 赋值带写屏障
   // 写屏障
}

读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前

public void actor1(I_Result r) {
		// 读屏障
 		// ready 是 volatile 读取值带读屏障
    if(ready) {
       r.r1 = num + num;
    } else {
       r.r1 = 1;
    }
}

volatile 不能解决指令交错

写屏障仅仅是保证之后的读能够读到最新的结果，但不能保证读跑到它前面去。

而有序性的保证也只是保证了本线程内相关代码不被重排序。

double-checked locking 问题

以著名的 double-checked locking 单例模式为例。

一般的单例模式如下：

public class Singleton {
    private Singleton() { }
    private static Singleton INSTANCE = null;

    public static Singleton getInstance() {
        synchronized(Singleton.class) {
            if (INSTANCE == null) { // t1
                INSTANCE = new Singleton();
            }
        }
        return INSTANCE;
    }
}

上面的代码通过synchronized有效的防止了多线程情况下还是会创建多个实例的情况。但是当我们第一次创建出实例后，后面每次判断实例是否为null时还是会通过synchronized上锁，降低了效率。

于是有了 double-checked 。就是在synchronized锁外再判断一次实例是否为null，那么第一次创建出实例后，下次判断不会再上锁。代码如下：

public class Singleton {
    private Singleton() { }
    private static Singleton INSTANCE = null;

    public static Singleton getInstance() {
        if(INSTANCE == null) { // t2
            // 首次访问会同步，而之后的使用没有 synchronized
            synchronized(Singleton.class) {
                if (INSTANCE == null) { // t1
                    INSTANCE = new Singleton();
                }
            }
        }
        return INSTANCE;
    }
}

上面的代码采用的惰性模式，即只有当真正实例化的时候才会创建实例。首次使用 getInstance() 才使用 synchronized 加锁，后续使用时无需加锁。

上面的代码，有隐含的，但很关键的一点：第一个 if 使用了 INSTANCE 变量，是在同步块之外。在多线程环境下，上面的代码是有问题的。

大致看下上面代码的字节码如下：

0: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
3: ifnonnull 37
6: ldc #3 // class cn/itcast/n5/Singleton
8: dup
9: astore_0
10: monitorenter
11: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
14: ifnonnull 27
17: new #3 // class cn/itcast/n5/Singleton
20: dup
21: invokespecial #4 // Method "<init>":()V
24: putstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
27: aload_0
28: monitorexit
29: goto 37
32: astore_1
33: aload_0
34: monitorexit
35: aload_1
36: athrow
37: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
40: areturn

其中

17 表示创建对象，将对象引用入栈 // new Singleton
20 表示复制一份对象引用 // 引用地址
21 表示利用一个对象引用，调用构造方法
24 表示利用一个对象引用，赋值给 static INSTANCE

也许 jvm 会优化为：先执行 24，再执行 21，即有可能先把对象赋值，再调用构造方法。如果两个线程 t1，t2 按如下时间序列执行：

在这里插入图片描述

关键在于 0: getstatic 这行代码在 monitor 控制之外，它就像之前举例中不守规则的人，可以越过 monitor 读取INSTANCE 变量的值。

这时 t1 还未完全将构造方法执行完毕，如果在构造方法中要执行很多初始化操作，那么 t2 拿到的是将是一个未初始化完毕的单例。

注意：为什么原来说synchronized可以保证共享变量的原子性、可见性和有序性，现在又不能保证原子性了？

事实上synchronized并不能阻止重排序，只有volatile可以。主要共享变量并没有完全被synchronized保护。上面的代码在synchronized外判断实例时，又读取了实例的值。

double-checked locking 解决

对 INSTANCE 使用 volatile 修饰即可，可以禁用指令重排，但要注意在 JDK 5 以上的版本的 volatile 才会真正有效。

public class Singleton {
    private Singleton() { }
    private static volatile Singleton INSTANCE = null;
    public static Singleton getInstance() {
        if(INSTANCE == null) { // t2
            // 首次访问会同步，而之后的使用没有 synchronized
            synchronized(Singleton.class) {
                if (INSTANCE == null) { // t1
                    INSTANCE = new Singleton();
                }
            }
        }
        return INSTANCE;
    }
}

对上面的字节码做一个注释：

// -------------------------------------> 加入对 INSTANCE 变量的读屏障
0: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
3: ifnonnull 37
6: ldc #3 // class cn/itcast/n5/Singleton
8: dup
9: astore_0
10: monitorenter -----------------------> 保证原子性、可见性
11: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
14: ifnonnull 27
17: new #3 // class cn/itcast/n5/Singleton
20: dup
21: invokespecial #4 // Method "<init>":()V
24: putstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
// -------------------------------------> 加入对 INSTANCE 变量的写屏障
27: aload_0
28: monitorexit ------------------------> 保证原子性、可见性
29: goto 37
32: astore_1
33: aload_0
34: monitorexit
35: aload_1
36: athrow
37: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
40: areturn

读写 volatile 变量时会加入内存屏障，保证下面两点:

可见性:

写屏障（sfence）保证在该屏障之前的 t1 对共享变量的改动，都同步到主存当中
而读屏障（lfence）保证在该屏障之后 t2 对共享变量的读取，加载的是主存中最新数据

有序性:

写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后
读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前

所以，volatile保证了在对象变了instance执行赋值操作（写操作）时，加了一个屏障，保证前面的执行构造方法的步骤不会在写屏障之后。从而保证了t2线程读取instance时一定不为空。

happens-before原则

https://bbs.huaweicloud.com/blogs/308992?utm_source=zhihu&utm_medium=bbs-ex&utm_campaign=other&utm_content=content

JDK1.5版本中的Java内存模型中引入了Happens-Before原则。happens-before 规定了对共享变量的写操作对其它线程的读操作可见，它是可见性与有序性的一套规则总结。只要遵守以下 happens-before 规则，JMM 就能保证一个线程对共享变量的写，对于其它线程对该共享变量的读可见。

有如下示例：

// 示例1
class VolatileExample {
  int x = 0;
  volatile boolean v = false;
  public void writer() {
    x = 42;
    v = true;
  }

  public void reader() {
    if (v == true) {
      //x的值是多少呢？
    }
  }
}

【原则一】程序次序规则

在一个线程中，按照代码的顺序，前面的操作Happens-Before于后面的任意操作。

例如示例1 中的程序，x=42会在v=true之前执行。这个规则比较符合单线程的思维：在同一个线程中，程序在前面对某个变量的修改一定是对后续操作可见的。

【原则二】volatile变量规则

对一个volatile变量的写操作，Happens-Before于后续对这个变量的读操作。

也就是说，对一个使用了volatile变量的写操作，先行发生于后面对这个变量的读操作。

【原则三】传递规则

如果 x hb-> y 并且 y hb-> z 那么有 x hb-> z ，配合 volatile 的防指令重排，有下面的例子

volatile static int x;
static int y;
new Thread(()->{ 
 y = 10;
 x = 20;
},"t1").start();
new Thread(()->{
 // x=20 对 t2 可见, 同时 y=10 也对 t2 可见
 System.out.println(x); 
},"t2").start();

【原则四】锁定规则

对一个锁的解锁操作 Happens-Before于后续对这个锁的加锁操作。

例如，下面的代码，在进入synchronized代码块之前，会自动加锁，在代码块执行完毕后，会自动释放锁。

// 示例2
public class Test{
    private int x = 0;
    public void initX{
        synchronized(this){ //自动加锁
            if(this.x < 10){
                this.x = 10;
            }
        } //自动释放锁
    }
}

设变量x的值为10，线程A执行完synchronized代码块之后将x变量的值修改为10，并释放synchronized锁。当线程B进入synchronized代码块时，能够获取到线程A对x变量的写操作，也就是说，线程B访问到的x变量的值为10。

【原则五】线程启动规则

如果线程A调用线程B的start()方法来启动线程B，则start()操作Happens-Before于线程B中的任意操作。

我们也可以这样理解线程启动规则：线程A启动线程B之后，线程B能够看到线程A在启动线程B之前的操作。

// 示例3
//在线程A中初始化线程B
Thread threadB = new Thread(()->{
    //此处的变量x的值是多少呢？答案是100
});
//线程A在启动线程B之前将共享变量x的值修改为100
x = 100;
//启动线程B
threadB.start();

上述代码是在线程A中执行的一个代码片段，根据【原则五】线程的启动规则，线程A启动线程B之后，线程B能够看到线程A在启动线程B之前的操作，在线程B中访问到的x变量的值为100。

【原则六】线程终结规则

线程A等待线程B完成（在线程A中调用线程B的join()方法实现），当线程B完成后（线程A调用线程B的join()方法返回），则线程A能够访问到线程B对共享变量的操作。

例如，在线程A中进行的如下操作。

Thread threadB = new Thread(()-{
    //在线程B中，将共享变量x的值修改为100
    x = 100;
});
//在线程A中启动线程B
threadB.start();
//在线程A中等待线程B执行完成
threadB.join();
//此处访问共享变量x的值为100

【原则七】线程中断规则

对线程interrupt()方法的调用Happens-Before于被中断线程的代码检测到中断事件的发生。

下面的程序代码。在线程A中中断线程B之前，将共享变量x的值修改为100，则当线程B检测到中断事件时，访问到的x变量的值为100。

//在线程A中将x变量的值初始化为0
    private int x = 0;

    public void execute(){
        //在线程A中初始化线程B
        Thread threadB = new Thread(()->{
            //线程B检测自己是否被中断
            if (Thread.currentThread().isInterrupted()){
                //如果线程B被中断，则此时X的值为100
                System.out.println(x);
            }
        });
        //在线程A中启动线程B
        threadB.start();
        //在线程A中将共享变量X的值修改为100
        x = 100;
        //在线程A中中断线程B
        threadB.interrupt();
    }

【原则八】对象终结原则

一个对象的初始化完成Happens-Before于它的finalize()方法的开始。

public class TestThread {

   public TestThread(){
       System.out.println("构造方法");
   }

    @Override
    protected void finalize() throws Throwable {
        System.out.println("对象销毁");
    }

    public static void main(String[] args){
        new TestThread();
        System.gc();
    }
}

运行结果如下所示:

构造方法
对象销毁

参考：
https://blog.csdn.net/qq_42878176/article/details/128262620
https://bbs.huaweicloud.com/blogs/308992?utm_source=zhihu&utm_medium=bbs-ex&utm_campaign=other&utm_content=content