笨蛋学JUC并发编程-共享模型之内存

3.1Java内存模型

JMM 即 Java Memory Model，它定义了主存(所有线程都共享的数据，可以认为对应着物理内存)、工作内存(每个线程私有的数据，可以认为对应着缓存)抽象概念，底层对应着 CPU 寄存器、缓存、硬件内存、CPU 指令优化等。

JMM 体现在以下几个方面

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

3.2可见性

3.2.1退不出的循环

main 线程对 run 变量的修改对于 t 线程不可见，导致了 t 线程无法停止：

static boolean run = true;

public static void main(String[] args) throws InterruptedException {
    
    Thread t = new Thread(()->{
        while(run){
            // ....
        }
    });
    t.start();
    
    sleep(1);
    run = false; // 线程t不会如预想的停下来
}

3.2.2分析

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

   

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

   

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

   

3.2.3解决方法

• volatile（易变关键字）

  • 可以用来修饰成员变量和静态成员变量

  • 可以避免线程从自己的工作缓存中查找变量的值，必须到主存中获取它的值，线程操作 volatile 变量都是直接操作主存

  volatile static boolean run = true;
  

• synchronized

  • 通过加锁同一对象来解决变量变动的问题
  • synchronized 语句块既可以保证代码块的原子性，也同时保证代码块内变量的可见性。
  • 但缺点是synchronized 是属于重量级操作，性能相对更低

      static boolean run = true;
      static Object lock=new Object();
      public static void main(String[] args) throws InterruptedException {
  
          Thread t = new Thread(()->{
              while(true){
                  synchronized (lock){
                      if(!run) break;
                  }
              }
          });
          t.start();
  
          sleep(1);
          //因为加锁的是同一对象
          synchronized (lock) {
              // 线程t如预想的停下来
              run = false;
          }
           
      }
  

3.2.4原子性和可见性

volatile关键字体现的实际就是可见性

• 它保证的是在多个线程之间，一个线程对 volatile 变量的修改对另一个线程可见，不能保证原子性，仅用在一个写线程，多个读线程的情况

3.2.5两阶段终止模式

private Thread thread;
    private volatile boolean stop = false;

    public void start(){
        thread = new Thread(() -> {
            while(true) {
                if(stop) {
                    log.debug("料理后事");
                    break;
                }
                try {
                    Thread.sleep(1000);
                    log.debug("将结果保存");
                } catch (InterruptedException e) {

                }
                // 执行监控操作
            }
        },"监控线程");
        thread.start();
    }

    public void stop() {
        stop = true;
        //当if判断完，就不再执行sleep方法
        thread.interrupt();
    }

3.2.6同步模式之Balking

//判断是否执行过start方法
    private volatile boolean starting;

    public void start() {
        log.info("尝试启动监控线程...");
        synchronized (this) {
            if (starting) {
                return;
            }
            starting = true;
        }

        // 真正启动监控线程...
    }

3.3有序性

• Clock Cycle Time 时钟周期时间

主频的概念大家接触的比较多，而 CPU 的 Clock Cycle Time（时钟周期时间），等于主频的倒数，意思是 CPU 能够识别的最小时间单位，比如说 4G 主频的 CPU 的 Clock Cycle Time 就是 0.25 ns，作为对比，我们墙上挂钟的Cycle Time 是 1s

例如，运行一条加法指令一般需要一个时钟周期时间

• CPI 平均时钟周期数

有的指令需要更多的时钟周期时间，所以引出了 CPI （Cycles Per Instruction）指令平均时钟周期数

• IPC 即 CPI 的倒数

IPC（Instruction Per Clock Cycle）即 CPI 的倒数，表示每个时钟周期能够运行的指令数

• CPU 执行时间

程序的 CPU 执行时间，即我们前面提到的 user + system 时间，可以用下面的公式来表示

程序 CPU 执行时间 = 指令数 * CPI * Clock Cycle Time

3.3.1指令重排特性

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

static int i;
static int j;

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

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

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

也可以是

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

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

3.3.2加工鱼的故事

• 加工一条鱼需要 50 分钟，只能一条鱼、一条鱼顺序加工…

  

• 但是可以将每个鱼罐头的加工流程细分为 5 个步骤：

  • 去鳞清洗 10分钟
  • 蒸煮沥水 10分钟
  • 加注汤料 10分钟
  • 杀菌出锅 10分钟
  • 真空封罐 10分钟

  

• 即使只有一个工人，最理想的情况是：他能够在 10 分钟内同时做好这 5 件事，因为对第一条鱼的真空装罐，不会
  影响对第二条鱼的杀菌出锅…

3.3.3指令重排序优化

事实上，现代处理器会设计为一个时钟周期完成一条执行时间最长的 CPU 指令。为什么这么做呢？
可以想到指令还可以再划分成一个个更小的阶段，
例如，每条指令都可以分为： 取指令 - 指令译码 - 执行指令 - 内存访问 - 数据写回 这 5 个阶段

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

在不改变程序结果的前提下，这些指令的各个阶段可以通过重排序和组合来实现指令级并行，这一技术在 80’s 中叶到 90’s 中叶占据了计算架构的重要地位。

3.3.4支持流水线的处理器

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

3.3.5诡异的结果

int num = 0;
boolean ready = false;

// 线程1 执行此方法
public void actor1(I_Result r) {
    if(ready) {
        r.r1 = num + num;
    } else {
        r.r1 = 1;
    }
}

// 线程2 执行此方法
public void actor2(I_Result r) { 
    //这里可能发生指令重排序
    num = 2;
    ready = true; 
}

主要情况：

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

解决办法

• volatile 修饰的变量，可以禁用指令重排
• volatile boolean ready = false;只需要加一个，因为加了之后会加入写屏障，保证在ready=true之前的对共享变量的改动，都同步到主存当中

3.3.6volatile原理

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

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

3.3.6.1如何保证可见性

• 写屏障（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;
    }
}

3.3.6.2如何保证有序性

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

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

---

3.3.6.3不能解决指令交错

• 写屏障仅仅是保证之后的读能够读到最新的结果，但不能保证读跑到它前面去
• 而有序性的保证也只是保证了本线程内相关代码不被重排序

3.3.6.4总结

• synchronized：能保障原子性、有序性、可见性
• volatile：只能保障有序性、可见性

3.3.7double-checked locking双重检查锁

• 双重检查锁的单例模式

public final 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 变量，是在同步块之外

---

但是如果 t1 还未完全将构造方法执行完毕，如果在构造方法中要执行很多初始化操作，那么 t2 拿到的是将是一个未初始化完毕的单例，对 INSTANCE 使用 volatile 修饰即可，可以禁用指令重排

public final class Singleton {
    private Singleton() { }
    private static volatile Singleton INSTANCE = null;
    
    public static Singleton getInstance() {
        // 实例没创建，才会进入内部的 synchronized代码块
        if (INSTANCE == null) { 
            synchronized (Singleton.class) { // t2
                // 也许有其它线程已经创建实例，所以再判断一次
                if (INSTANCE == null) { // t1
                    INSTANCE = new Singleton();
                }
            }
        }
        return INSTANCE;
    }
}

---

3.3.7happens-before的规则

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

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

• 第一个线程的写对第二个线程的读是可见的

static int x;
static Object m = new Object();

new Thread(()->{
    synchronized(m) {
        x = 10;
    }
},"t1").start();

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

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

• 将最新的结果写到主存中，读取结果自然是可见的

volatile static int x;

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

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

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

• 在线程读之前，就已经把变量写好了，所以自然是读是可见的

static int x; 
x = 10;

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

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

• 在线程写之前就将结果同步到主存中，供其他线程看见

static int x;

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;
        t2.interrupt();
    },"t1").start();
    
    while(!t2.isInterrupted()) {
        Thread.yield();
    }
    System.out.println(x);
}

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

情况7: 具有传递性，如果 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();

3.3.8线程安全单例

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

• 饿汉式

  // 问题1：为什么加 final
  // 问题2：如果实现了序列化接口, 还要做什么来防止反序列化破坏单例
  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;
      }
  }
  

  • 问题1：避免子类覆盖父类中的方法

  • 问题2：采用该方法返回的对象作为反序列化的对象

    public Object readResolve() {
            return INSTANCE;
    }
    

  • 问题3：

    • 设置私有，避免创建更多的对象
    • 不能防止反射创建新的实例

  • 问题4：能保证单例对象创建时的线程安全

  • 问题5：

    • 在创建单例对象时有更多的控制
    • 支持泛型处理

• 懒汉式

  public final class Singleton {
      private Singleton() { }
      // 问题1：属于懒汉式还是饿汉式  懒汉式
      private static class LazyHolder {
          static final Singleton INSTANCE = new Singleton();
      }
      // 问题2：在创建时是否有并发问题   JVM保证其安全性
      public static Singleton getInstance() {
          return LazyHolder.INSTANCE;
      }
  }
  

  • 问题1：懒汉式
  • 问题2：可以保证线程安全

  ---

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

  • 问题1：属于懒汉式，可以保证线程安全，锁的范围太大了，每次调用都会加锁，导致性能较低

• 枚举类

  // 问题1：枚举单例是如何限制实例个数的
  // 问题2：枚举单例在创建时是否有并发问题
  // 问题3：枚举单例能否被反射破坏单例
  // 问题4：枚举单例能否被反序列化破坏单例
  // 问题5：枚举单例属于懒汉式还是饿汉式
  // 问题6：枚举单例如果希望加入一些单例创建时的初始化逻辑该如何做
  enum Singleton { 
      INSTANCE; 
  }
  

  • 问题1：就是枚举类的一个单实例对象
  • 问题2：没有，在创建时是线程安全的
  • 问题3：不能用反射创建单例
  • 问题4：可以被序列化，也可以被反序列化，无需额外操作
  • 问题5：属于饿汉式
  • 问题6：写一个构造方法，在构造方法中加入相关初始化的逻辑

• 双重检查锁

  public final class Singleton {
      private Singleton() { }
      
      // 问题1：解释为什么要加 volatile ?
      private static volatile Singleton INSTANCE = null;
      
      // 问题2：对比懒汉式, 说出这样做的意义 
      public static Singleton getInstance() {
          if (INSTANCE != null) { 
              return INSTANCE;
          }
          synchronized (Singleton.class) { 
              // 问题3：为什么还要在这里加为空判断, 之前不是判断过了吗
              if (INSTANCE != null) { // t2 
                  return INSTANCE;
              }
              INSTANCE = new Singleton(); 
              return INSTANCE;
          } 
      }
  }
  

  • 问题1：为了解决方法中的指令重排序

  • 问题2：当第一次调用时，是正常的，当第二次…调用时，这里的INSTANCE一直不为空

  • 问题3：第二次判断是为了防止第一次并发时的单例对象不会被重复创建