Java 内存模型 与 volatile原理

4 Java 内存模型 与 volatile原理

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

JMM 体现在以下几个方面

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

可见性

JMM 中每个线程有自己的本地内存，对于那些共享的变量会先从主内存中读取再存入本地内存中，以减少对主内存的访问次数，提高效率。但是如果其中一个内存的值发生了改变，就无法及时更新到其他内存中，导致线程直接对共享变量存储的值不一致，也就是线程之间对其他线程是不可见的。

解决方案之一是 volatile（易变关键字）

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

原子性

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

volatile 适用于仅用在一个写线程，多个读线程的情况

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

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

有序性

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

volatile 修饰的变量也会禁止重排序

volatile 原理

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

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

有序性的保证

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

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

不能解决指令交错：

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

即使 i 使用 volatile 保证每次读取是最新主存中的值，但是如果 t2 线程提前读了 i 的值，读到的数据也是不对的

double-checked locking 问题

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

以上的实现特点是：

• 懒惰实例化
• 首次使用 getInstance() 才使用 synchronized 加锁，后续使用时无需加锁，后续直接 return 了
• 有隐含的，但很关键的一点：第一个 if 使用了 INSTANCE 变量，是在同步块之外
• **需要判断两次 INSTANCE是否为 null ** ：因为可能有多个线程同时都判断为 null 进入 if 里面，但是只有一个线程会进入同步代码块，在前面的线程进入之后会创建一个 INSTANCE，那么后面进入的那个线程就需要不判断 INSTANCE 是否为空，就会创建两个对象。

但在多线程环境下，上面的代码是有问题的，synchronized 无法保证有序性

getInstance 方法对应的字节码为：

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 拿到的是将是一个未初始化完毕的单例

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

happens-before

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

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

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

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

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

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

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

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

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

• happens before 具有传递性，如果 x happens before -> y 并且 y happens before-> z 那么有 x happens before-> 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();