本章重点讲解了 JMM 中的

  • 可见性 - 由 JVM 缓存优化引起
  • 有序性 - 由 JVM 指令重排序优化引起
  • happens-before 规则

原理方面

  • CPU 指令并行
  • volatile

模式方面

  • 两阶段终止模式的 volatile 改进
  • 同步模式之 balking

    共享模型之内存

上一章讲解的 Monitor 主要关注的是访问共享变量时，保证临界区代码的原子性。

Java内存模型

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

JMM 体现在以下几个方面

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

可见性

退不出的循环

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

  1. static boolean run = true;
  2. public static void main(String[] args) throws InterruptedException {
  3.     Thread t = new Thread(()->{
  4.         while(run){
  5.             // ....
  6.         }
  7.     });
  8.     t.start();
  9.     sleep(1);
  10.     run = false; // 线程t不会如预想的停下来
  11. }

为什么呢？分析一下：

  1. 初始状态， t 线程刚开始从主内存读取了 run 的值到工作内存。
    共享模型之内存 - 图1
  2. 因为 t 线程要频繁从主内存中读取 run 的值，JIT 编译器会将 run 的值缓存至自己工作内存中的高速缓存中，减少对主存中 run 的访问，提高效率。
    共享模型之内存 - 图2
  3. 1 秒之后，main 线程修改了 run 的值，并同步至主存，而 t 是从自己工作内存中的高速缓存中读取这个变量的值，结果永远是旧值。

共享模型之内存 - 图3

volatile解决可见性

volatile（易变关键字）

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

可见性 vs 原子性

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

上例从字节码理解是这样的：

  1. getstatic run // 线程 t 获取 run true 
  2. getstatic run // 线程 t 获取 run true 
  3. getstatic run // 线程 t 获取 run true 
  4. getstatic run // 线程 t 获取 run true 
  5. putstatic run // 线程 main 修改 run 为 false， 仅此一次
  6. getstatic run // 线程 t 获取 run false

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

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

注意 synchronized 语句块既可以保证代码块的原子性，也同时保证代码块内变量的可见性。但缺点是synchronized 是属于重量级操作，性能相对更低

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

printfln方法上加了 synchronized 锁。

原理之 CPU 缓存结构

模式之两阶段终止

模式之Balking

有序性

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

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

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

  1. i = ...; 
  2. j = ...;

也可以是

  1. j = ...;
  2. i = ...;

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

原理之指令级并行

volatile解决有序性

  1. int num = 0;
  2. boolean ready = false;
  3. // 线程1 执行此方法
  4. public void actor1 (I_Result r){
  5.     if (ready) {
  6.         r.r1 = num + num;
  7.     } else {
  8.         r.r1 = 1;
  9.     }
  10. }
  11. // 线程2 执行此方法
  12. public void actor2 (I_Result r){
  13.     num = 2;
  14.     ready = true;
  15. }

结果可能为 0，2，4，指令集并行中提到了指令重排，会影响代码的执行顺序。

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

volatile原理

内存屏障

Memory Barrier（Memory Fence）

可见性

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

有序性

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

共享模型之内存 - 图4

细节

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

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

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

如何保证可见性

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

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

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

  1. public void actor1(I_Result r) {
  2.      // 读屏障
  3.      // ready 是 volatile 读取值带读屏障
  4.      if(ready) {
  5.          r.r1 = num + num;
  6.      } else {
  7.          r.r1 = 1;
  8.      }
  9. }

共享模型之内存 - 图5

如何保证有序性

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

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

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

  1. public void actor1(I_Result r) {
  2.      // 读屏障
  3.      // ready 是 volatile 读取值带读屏障
  4.      if(ready) {
  5.          r.r1 = num + num;
  6.      } else {
  7.          r.r1 = 1;
  8.      }
  9. }

共享模型之内存 - 图6

注意：

不能解决指令交错：

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

以下指令交错volalite就无法解决

共享模型之内存 - 图7

double-checked locking有序性问题

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

  1. public final class Singleton {
  2.     private Singleton() { }
  3.     private static Singleton INSTANCE = null;
  4.     public static Singleton getInstance() {
  5.         if(INSTANCE == null) { // t2
  6.             // 首次访问会同步，而之后的使用没有 synchronized
  7.             synchronized(Singleton.class) {
  8.                 if (INSTANCE == null) { // t1，也就是第一个线程还没有执行new一个对象，第二个线程运行到synchronized中等待，线程一运行完后，线程二此时进入synchronized代码块中运行，此时线程二的INSTANCE为空，此时需要判断是否为空在进行执行
  9.                     INSTANCE = new Singleton();
  10.                 }
  11.             }
  12.         }
  13.         return INSTANCE;
  14.     }
  15. }

以上的实现特点是：

  • 懒惰实例化
  • 首次使用 getInstance() 才使用 synchronized 加锁，后续使用时无需加锁
  • 有隐含的，但很关键的一点：第一个 if 使用了 INSTANCE 变量，是在同步块之外

对应的字节码：

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

其中

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

也许 jvm 会优化为：先执行 24，再执行 21。如果两个线程 t1，t2 按如下时间序列执行：

共享模型之内存 - 图8

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

此时synchonized锁住的代码块中也会有重排序的问题，如果这时 t1 还未完全将构造方法执行完毕，第二个线程在if判断时synchonized没有初始化完毕，获取如果在构造方法中要执行很多初始化操作，那么 t2 拿到的是将是一个未初始化完毕的单例。

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

double-checked locking解决

  1. public final class Singleton {
  2.     private Singleton() { }
  3.     private static volatile Singleton INSTANCE = null;
  4.     public static Singleton getInstance() {
  5.         // 实例没创建，才会进入内部的 synchronized代码块
  6.         if (INSTANCE == null) {
  7.             synchronized (Singleton.class) { // t2
  8.                 // 也许有其它线程已经创建实例，所以再判断一次
  9.                 if (INSTANCE == null) { // t1
  10.                     INSTANCE = new Singleton();
  11.                 }
  12.             }
  13.         }
  14.         return INSTANCE;
  15.     }
  16. }

如上面的注释内容所示，读写 volatile 变量时会加入内存屏障（Memory Barrier（Memory Fence）），保证下面两点：

可见性

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

有序性

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

更底层是读写变量时使用 lock 指令来多核 CPU 之间的可见性与有序性。

共享模型之内存 - 图9

如果变量加了volatile关键字，那么在读取INSTANCE时会有读屏障，后面的指令都得在读的后面，所以保证了getstatic 这行指令不会越过monitor读取后面的值。保证了两个线程的有序性，同时第二个线程读取的时候也是读取的最新值。

同时也提示了synchonized保证有序性需要所有代码都在synchonized保护中才可以满足。()

synchonized是可以满足原子性，有序性，可见性，但前提都需要在synchonized隔离区中包含。

该例子表示保证了在 synchonized 代码块外的有序性。

happens-before

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

  • 线程解锁 m 之前对变量的写，对于接下来对 m 加锁的其它线程对该变量的读可见 
    1. static int x;
    2. static Object m = new Object();
    3. new Thread(()->{
    4.  synchronized(m) {
    5.      x = 10;
    6.  },"t1").start();
    7.  new Thread(()->{
    8.      synchronized(m) {
    9.          System.out.println(x);
    10.      }
    11.  },"t2").start();
  • 线程对 volatile 变量的写，对接下来其它线程对该变量的读可见 
    1. volatile static int x;
    2. new Thread(()->{
    3.   x = 10;
    4. },"t1").start();
    5. new Thread(()->{
    6.   System.out.println(x);
    7. },"t2").start();

  • 线程 start 前对变量的写，对该线程开始后对该变量的读可见 ```java static int x; x = 10; new Thread(()->{

    System.out.println(x);

},”t2”).start()

  3. -  线程结束前对变量的写，对其它线程得知它结束后的读可见（比如其它线程调用 t1.isAlive() 或 t1.join()等待它结束） 
  4. ```java
  5. static int x;
  6. Thread t1 = new Thread(()->{
  7.     x = 10;
  8. },"t1");
  9. t1.start();
  10. t1.join();
  11. System.out.println(x);
  • 线程 t1 打断 t2（interrupt）前对变量的写，对于其他线程得知 t2 被打断后对变量的读可见（通过t2.interrupted 或 t2.isInterrupted） 
    1. static int x;
    2. public static void main(String[] args) {
    3.  Thread t2 = new Thread(()->{
    4.      while(true) {
    5.          if(Thread.currentThread().isInterrupted()) {
    6.              System.out.println(x);
    7.              break;
    8.          }
    9.      }
    10.  },"t2");
    11.  t2.start();
    12.  new Thread(()->{
    13.      sleep(1);
    14.      x = 10;
    15.      t2.interrupt();
    16.  },"t1").start();
    17.  while(!t2.isInterrupted()) {
    18.      Thread.yield();
    19.  }
    20.  System.out.println(x);
    21. }
  • 对变量默认值（0，false，null）的写，对其它线程对该变量的读可见具有传递性，如果 x hb-> y 并且 y hb-> z 那么有 x hb-> z ，配合 volatile 的防指令重排，有下面的例子：（也就是读写屏障） 
    1. volatile static int x;
    2. static int y;
    3. new Thread(()->{
    4.  y = 10;
    5.  x = 20;
    6. },"t1").start();
    7. new Thread(()->{
    8.  // x=20 对 t2 可见, 同时 y=10 也对 t2 可见
    9.  System.out.println(x);
    10. },"t2").start();

变量都是指成员变量或静态成员变量。