《JUC并发编程 - 高级篇》04 -共享模型之内存 （Java内存模型 | 可见性 | 有序性 ）

四、共享模型之内存

上一章讲解的 Monitor 主要关注的是访问共享变量时，保证临界区代码的原子性
这一章我们进一步深入学习共享变量在多线程间的【可见性】问题与多条指令执行时的【有序性】问题

5.1 Java 内存模型

JMM 即 Java Memory Model，它定义了主存、工作内存抽象概念，底层对应着 CPU 寄存器、缓存、硬件内存、CPU 指令优化等。（主要是为了程序员不直接面对底层）

JMM 体现在以下几个方面：

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

主存：所有线程都共享的数据，包括静态成员变量、成员变量等

工作内存：每个线程私有的内存，比如局部变量

5.2 可见性

5.2.1 退不出的循环

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

@Slf4j(topic = "c.Test01")
public class Test01 {

    static boolean run = true;

    public static void main(String[] args) {
        Thread t = new Thread(() -> {
            while (run) {
                //...
            }
        });

        t.start();

        Sleeper.sleep(0.5);
        run = false;

    }
}

为什么呢？分析一下：

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

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

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

回顾JVM的知识：由于JVM采用JIT和解释器混合执行所以会循环超过1w次以后生成热点代码。此后就不重新编译，直接使用热点代码，所以修改flag的值没用

==提出问题：==一个线程对主存中的数据进行了修改，但是另外一个线程使用的仍然是缓存中的数据，从而出现问题。所以如何解决这个问题呢？

5.2.2 解决方法

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

注意：不能修饰局部变量，因为局部变量是线程私有的

volatile static boolean run = true;

方法二：synchronized

@Slf4j(topic = "c.Test01")
public class Test01 {

    //锁对象
    final static Object lock = new Object();

    static boolean run = true;

    public static void main(String[] args) {
        Thread t = new Thread(() -> {
            while (true) {
                synchronized (lock){
                    if(!run){
                        break;
                    }
                }
                //...
            }
        });

        t.start();

        Sleeper.sleep(1);
        log.debug("停止 t");
        synchronized (lock){
            run = false;
        }
        run = false;

    }
}

分析：在Java内存模型中，synchronized规定，线程在加锁时， 先清空工作内存→在主内存中拷贝最新变量的副本到工作内存 →执行完代码→将更改后的共享变量的值刷新到主内存中→释放互斥锁

5.2.3 可见性 vs 原子性

前面例子体现的实际就是可见性，它保证的是在多个线程之间，一个线程对 volatile 变量的修改对另一个线程可见， 不能保证原子性。volatile仅用在一个写线程，多个读线程的情况： 上例从字节码理解是这样的：

getstatic run // 线程 t 获取 run true
getstatic run // 线程 t 获取 run true
getstatic run // 线程 t 获取 run true
getstatic run // 线程 t 获取 run true
putstatic run // 线程 main 修改 run 为 false， 仅此一次
getstatic run // 线程 t 获取 run false

比较一下之前我们将线程安全时举的例子：两个线程一个 i++ 一个 i-- ，只能保证看到最新值，不能解决指令交错

// 假设i的初始值为0
getstatic i // 线程2-获取静态变量i的值 线程内i=0
    
getstatic i // 线程1-获取静态变量i的值 线程内i=0
iconst_1 // 线程1-准备常量1
iadd // 线程1-自增 线程内i=1
putstatic i // 线程1-将修改后的值存入静态变量i 静态变量i=1
    
iconst_1 // 线程2-准备常量1
isub // 线程2-自减 线程内i=-1
putstatic i // 线程2-将修改后的值存入静态变量i 静态变量i=-1

注意

• synchronized 语句块既可以保证代码块的原子性，也同时保证代码块内变量的可见性。但缺点是synchronized 是属于重量级操作，性能相对更低
• 对于一个写线程，多个读线程的情况，可以使用volatile。并且该操作是轻量级的

思考

如果在前面示例的死循环中加入 System.out.println() 会发现即使不加 volatile 修饰符，线程 t 也能正确看到对 run 变量的修改了，想一想为什么？

5.3 有序性

JVM 会在不影响正确性的前提下，可以调整语句的执行顺序，思考下面一段代码

static int i;
static int j;

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

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

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

也可以是

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

这种特性称之为『指令重排』，多线程下『指令重排』会影响正确性。为什么要有重排指令这项优化呢？从 CPU执行指令的原理来理解一下吧

原理之指令级并行*

5.3.1 诡异的结果

int num = 0;
boolean ready = false;

public void actor1(I_Result r) {
    if(ready) {
        r.r1 = num + num;
    } else {
        r.r1 = 1;
    }
}

public void actor2(I_Result r) {
    num = 2;
    ready = true;
}

I_Result 是一个对象，有一个属性 r1 用来保存结果，问，可能的结果有几种？

有同学这么分析：

• 情况1：线程1 先执行，这时 ready = false，所以进入 else 分支结果为 1
• 情况2：线程2 先执行 num = 2，但没来得及执行 ready = true，线程1 执行，还是进入 else 分支，结果为1
• 情况3：线程2 执行到 ready = true，线程1 执行，这回进入 if 分支，结果为 4（因为 num 已经执行过了）

但我告诉你，结果还有可能是 0 😁😁😁，信不信吧！

这种情况下是：线程2 执行 ready = true，切换到线程1，进入 if 分支，相加为 0，再切回线程2 执行 num = 2

相信很多人已经晕了 😵😵😵

这种现象叫做指令重排，是 JIT 编译器在运行时的一些优化，这个现象需要通过大量测试才能复现：

借助 java 并发压测工具 jcstress https://wiki.openjdk.java.net/display/CodeTools/jcstress

使用下面的命令创建一个maven项目 ，并提供测试类

mvn archetype:generate -DinteractiveMode=false -DarchetypeGroupId=org.openjdk.jcstress -DarchetypeArtifactId=jcstress-java-test-archetype -DarchetypeVersion=0.5 -DgroupId=cn.itcast -DartifactId=ordering -Dversion=1.0

测试类：

@JCStressTest
@Outcome(id = {"1", "4"}, expect = Expect.ACCEPTABLE, desc = "ok")//预料之中的
@Outcome(id = "0", expect = Expect.ACCEPTABLE_INTERESTING, desc = "!!!!")//感兴趣的
@State
public class ConcurrencyTest {
    int num = 0;
    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;
    }
}

执行

mvn clean install
java -jar target/jcstress.jar

会输出我们感兴趣的结果，摘录其中一次结果：

*** INTERESTING tests
  Some interesting behaviors observed. This is for the plain curiosity.

  4 matching test results.
      [OK] cn.itcast.ConcurrencyTest
    (JVM args: [-XX:+UnlockDiagnosticVMOptions, -XX:+StressLCM, -XX:+StressGCM])
  Observed state   Occurrences              Expectation  Interpretation
               0        32,811   ACCEPTABLE_INTERESTING  !!!!
               1   108,504,290               ACCEPTABLE  ok
               4    74,160,270               ACCEPTABLE  ok

      [OK] cn.itcast.ConcurrencyTest
    (JVM args: [-XX:-TieredCompilation, -XX:+UnlockDiagnosticVMOptions, -XX:+StressLCM, -XX:+StressGCM])
  Observed state   Occurrences              Expectation  Interpretation
               0        28,770   ACCEPTABLE_INTERESTING  !!!!
               1    87,596,769               ACCEPTABLE  ok
               4    91,251,172               ACCEPTABLE  ok

      [OK] cn.itcast.ConcurrencyTest
    (JVM args: [-XX:-TieredCompilation])
  Observed state   Occurrences              Expectation  Interpretation
               0        25,764   ACCEPTABLE_INTERESTING  !!!!
               1   118,604,894               ACCEPTABLE  ok
               4    59,673,373               ACCEPTABLE  ok
      
	  [OK] cn.itcast.ConcurrencyTest
    (JVM args: [])
  Observed state   Occurrences              Expectation  Interpretation
               0        19,905   ACCEPTABLE_INTERESTING  !!!!
               1   116,382,562               ACCEPTABLE  ok
               4    58,300,934               ACCEPTABLE  ok

可以看到，出现结果为 0 的情况有 上万 次，虽然次数相对很少，但毕竟是出现了。

5.3.2 解决方法

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

volatile boolean ready = false;

测试结果：

*** INTERESTING tests
  Some interesting behaviors observed. This is for the plain curiosity.

  0 matching test results.

* 原理之 volatile

5.3.3 happens-before

happens-before 规定了对共享变量的写操作对其它线程的读操作可见，它是可见性与有序性的一套规则总结，抛开以下 happens-before 规则，JMM 并不能保证一个线程对共享变量的写，对于其它线程对该共享变量的读可见

1. 线程解锁 m 之前对变量的写，对于接下来对 m 加锁的其它线程对该变量的读可见

static int x;
static Object m = new Object();
public void method1() {
	//假设t1比t2先运行
    new Thread(()->{
        synchronized(m) {
            x = 10;
        }
    },"t1").start();
    
    new Thread(()->{
        synchronized(m) {
            System.out.println(x);
        }
    },"t2").start();
}

分析：synchronized可以保证原子性和可见性。加锁前要从主存中获取最新值，解锁时要把工作内存的值及时刷回主存

2. 线程对 volatile 变量的写，对接下来其它线程对该变量的读可见

//volatile可以保证变量的可见性以及防止指令重排。
volatile static int x;

public void method2(){
	//假设t1比t2先执行
    new Thread(()->{
        x = 10;
    },"t1").start();
    
    new Thread(()->{
        System.out.println(x);
    },"t2").start();
}

3. 线程 start 前对变量的写，对该线程开始后对该变量的读可见

static int x;
public void method3(){

    x = 10;
    new Thread(()->{
        System.out.println(x);
    },"t2").start();
}

4. 线程结束前对变量的写，对其它线程得知它结束后的读可见（比如其它线程调用 t1.isAlive() 或 t1.join()等待它结束）

static int x;
public void method4(){

    Thread t1 = new Thread(()->{
        x = 10;
    },"t1");
    
    t1.start();
    t1.join();
    System.out.println(x);
}

5. 线程 t1 打断 t2（interrupt）前对变量的写，对于其他线程得知 t2 被打断后对变量的读可见（通过
t2.interrupted 或 t2.isInterrupted）

static int x;
public static void main(String[] args) {
    Thread t2 = new Thread(()->{
        while(true) {//如果不被打断一直空执行
            if(Thread.currentThread().isInterrupted()) {
                System.out.println(x);
                break;
            }
        }
    },"t2");
    
    t2.start();
    
    new Thread(()->{
        sleep(1);
        x = 10;//为x赋值
        t2.interrupt();//打断t2
    },"t1").start();
    
    while(!t2.isInterrupted()) {//如果t2没有被打断一直空转
        Thread.yield();
    }
    System.out.println(x);//t2被打断后主程序继续往下执行
}

6. 对变量默认值（0，false，null）的写，对其它线程对该变量的读可见

• 默认值是指：类加载过程中，准备阶段，赋的默认值

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

//写屏障会把前面的指令对共享变量的改动都同步到主存中
volatile static int x;
static int y;
public void method7(){

    //假设t1比t2先执行
    new Thread(()->{
        y = 10;
        x = 20;
    },"t1").start();
    
    new Thread(()->{
        // x=20 对 t2 可见, 同时 y=10 也对 t2 可见
        System.out.println(x);
    },"t2").start();
}

5.4 习题

5.4.1 balking 模式习题

希望 doInit() 方法仅被调用一次，下面的实现是否有问题，为什么？

public class TestVolatile {
    boolean initialized = false;
    public void init() {
        synchronized(this){
            if (initialized) {//t2
            	return;
        	 }
            doInit();//t1
            initialized = true;
        }   
    }
    private void doInit() {
    }
}

有问题，对initialized的读和写 多处出现。当t1在执行doInit()方法时，此时t2在第四行判断通过后也会执行doInit()方法，最终会导致doInit()被执行两次。

**解决办法：**参考同步模式之Balking

volitile适用于一个线程写多个线程读的情况，也可用于double-checked中synchronized外指令重排序问题

5.4.2 线程安全单例习题

单例模式有很多实现方法，饿汉、懒汉、静态内部类、枚举类，试分析每种实现下获取单例对象（即调用getInstance）时的线程安全，并思考注释中的问题

• 饿汉式：类加载就会导致该单实例对象被创建
• 懒汉式：类加载不会导致该单实例对象被创建，而是首次使用该对象时才会创建

实现1：饿汉式

/**
 * 问题1：为什么加 final?
 *       为了防止子类中的一些方法覆盖父类的提供单例的方法,从而破坏父类的单例
 * 问题2：如果实现了序列化接口, 还要做什么来防止反序列化破坏单例
 *       实现了序列化，就可以采用网络流的形式传输Java对象，最终可以通过反序列化创建对象。这个对象和单例模式创建的对象是不同的对象
 *       ，也就是破坏了单例。
 *       解决办法：加一个public Object readResolve(){...}
 *       原因：在通过反序列化创建对象的过程中，如果发现readResolve()有返回值，则直接使用该方法，不再用反序列化的字节码来创建对象。
 *
 * 问题3：为什么设置为私有? 是否能防止反射创建新的实例?
 *       如果为共有的话，也就可以直接new()无限的创建对象，也就不是单例了。
 *       不能，暴力反射依旧可以创建实例对象
 *
 * 问题4：这样初始化是否能保证单例对象创建时的线程安全?
 *       静态成员变量的赋值操作是在类加载阶段完成的，所以可以保证
 *
 *
 *  问题5：为什么提供静态方法而不是直接将 INSTANCE 设置为 public, 说出你知道的理由
 *        ① 使用方法，可以有更好的封装性，也可以改进成懒惰初始化。
 *        ② 创建单例对象时可以有更多的控制
 *        ③ 可以对泛型进行支持
 *
 */
public final class Singleton implements Serializable {
    // 问题3：为什么设置为私有? 是否能防止反射创建新的实例?
    private Singleton() {}
    // 问题4：这样初始化是否能保证单例对象创建时的线程安全?
    private static final Singleton INSTANCE = new Singleton();
    // 问题5：为什么提供静态方法而不是直接将 INSTANCE 设置为 public, 说出你知道的理由
    public static Singleton getInstance() {
        return INSTANCE;
    }
    //解决反序列化破坏单例
    public Object readResolve(){
        return INSTANCE;
    }
}

实现2：枚举类实现单例

/**
 * 问题1：枚举单例是如何限制实例个数的
 *      通过观察源码，可以发现枚举本质是一个静态成员变量，然后通过static{}
 *      进行初始化工作
 * 问题2：枚举单例在创建时是否有并发问题
 *       静态成员变量的赋值操作是在类加载阶段完成的，所以可以保证
 * 问题3：枚举单例能否被反射破坏单例
 *        不能，枚举类型不能通过newInstance反射。
 * 问题4：枚举单例能否被反序列化破坏单例
 *        不能，因为ENUM父类中的反序列化是通过valueOf实现的 不是通过反射
 * 问题5：枚举单例属于懒汉式还是饿汉式
 *        饿汉式
 * 问题6：枚举单例如果希望加入一些单例创建时的初始化逻辑该如何做
 *        可参考：https://blog.csdn.net/qq_39714944/article/details/91973832
 * 注意：关于为啥强烈建议使用枚举类来实现单例模式的原因可参考：
 *  https://mp.weixin.qq.com/s?__biz=MzI3NzE0NjcwMg==
 *  &mid=2650121482&idx=1&sn=e5b86797244d8879bbe9a69fb72641b5
 *  &chksm=f36bb82bc41c313d739f485383d3a868a79020c995ee86daef
 *  026a589f4782916c42a8d3f6c7&mpshare=1&scene=1&srcid=0614J9
 *  OX5zkoAnHiPYX2sHiH#rd
 */


//无参构造的枚举类
enum Singleton {
    INSTANCE;
}

//有参构造的枚举类
enum Singleton {
    INSTANCE(0,"INSTANCE");
    int key;
    String value;
    //构造成员方法默认都是private，不能通过new的方式创建对象
    Singleton(int key, String value) {
        this.key = key;
        this.value = value;
    }

    public int getKey() {
        return key;
    }

    public void setKey(int key) {
        this.key = key;
    }

    public String getValue() {
        return value;
    }

    public void setValue(String value) {
        this.value = value;
    }
}

实现3：懒汉式

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;
    }
}

实现4：DCL ，本质就是对懒汉式的改进

• 缩小了synchronized的范围
• 但也带来了其他问题，比如指令可能重排序，可能重复创建对象。可通过双层判断 + volatile 解决

public final class Singleton {
    private Singleton() { }
    // 问题1：解释为什么要加 volatile ?
    // 为了防止指令的重排序。INSTANCE = new Singleton(); 对t1当发生重排序时候可能先进行
    // 赋值操作，此时还没有进行实例化，这时候t2进来后 外部if (INSTANCE != null) 不为空，直接返回了INSTANCE，但是这个是还未初始化的实例
    // 存在一定的问题。
    //加上volatile后，就不会出现指令重排序了。要么当t2进行 外部if (INSTANCE != null) 时，已经初始化赋值完毕。要么t2进行if (INSTANCE != null)
    //时，此时INSTANCE为null，直接继续向下运行... 就不会出现问题了。
    private static volatile Singleton INSTANCE = null;
    // 问题2：对比实现3, 说出这样做的意义
    //缩小了锁的范围，第一次需要进入synchronized代码块，之后就不需要进入synchronized同步了。
    public static Singleton getInstance() {
        if (INSTANCE != null) {
            return INSTANCE;
        }
        synchronized (Singleton.class) {
            // 问题3：为什么还要在这里加为空判断, 之前不是判断过了吗
            //为了防止，第一次并发访问时，对象不要重复创建。比如t1正在 new 创建对象，此时t2在synchronized外等待，当t1
            //t1创建完成并走出synchronized时，t2也会进入synchronized块，所以需要再次进行判断一下，防止重复创建。
            if (INSTANCE != null) { // t2
                return INSTANCE;
            }
            INSTANCE = new Singleton();
            return INSTANCE;
        }
    }
}

实现5：内部类的方式

public final class Singleton {
    private Singleton() { }
    // 问题1：属于懒汉式还是饿汉式
    // 类加载本身就是懒惰的，第一次使用时才进行加载。
    // 如果仅仅创建是使用外部的Singleton，没有使用getInstance（）,
    // 就不会触发LazyHolder的类加载，也就不会进行静态变量的初始化操作。

    private static class LazyHolder {
        static final Singleton INSTANCE = new Singleton();
    }
    // 问题2：在创建时是否有并发问题
    // 无 静态成员变量在类加载时进行初始化操作
    public static Singleton getInstance() {
        return LazyHolder.INSTANCE;
    }
}

本章小结

本章重点讲解了 JMM 中的

• 可见性 - 由 JVM 缓存优化引起
• 有序性 - 由 JVM 指令重排序优化引起
• happens-before 规则
• 原理方面
  • CPU 指令并行
  • volatile
• 模式方面
  • 两阶段终止模式的 volatile 改进
  • 同步模式之 balking