一 volatile

  • 主内存：所有的变量都存储在主内存。线程间变量值的传递均需要通过主内存来完成。
  • 线程的工作内存：保存了被该线程使用的变量的主内存副本。线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的数据。不同的线程之间也无法直接访问对方工作内存中的变量。线程间变量值的传递均需要通过主内存来完成。

这里所讲的主内存、工作内存与第2章所讲的Java内存区域中的Java堆、栈、方法区等并不是同一 个层次的对内存的划分，这两者基本上是没有任何关系的。

如果两者一定要勉强对应起来，那么从变 量、主内存、工作内存的定义来看，主内存主要对应于Java堆中的对象实例数据部分，而工作内存则对应于虚拟机栈中的部分区域。从更基础的层次上说，主内存直接对应于物理硬件的内存，而为了获取更好的运行速度，虚拟机（或者是硬件、操作系统本身的优化措施）可能会让工作内存优先存储于寄存器和高速缓存中，因为程序运行时主要访问的是工作内存。

可见性

先来看一个现象，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不会如预想的停下来
}

为什么呢？分析一下：

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

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

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

解决方法 volatile（易变关键字）

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

  • 在工作内存中，每次使用V前都必须先从主内存刷新最新的值（可见性）
  • 在工作内存中，每次修改V后都必须立刻同步回主内存中（可见性）

可见性 vs 原子性

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

不能保证原子性，仅用在一个写线程，多个读线程的情况（sychronized既能保证原子性也能保证可见性）。 

不能解决 多个线程对同一个变量读写 时的指令交错问题。

有序性

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

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 编译器在运行时的一些优化。（好像目的是为了提高指令的吞吐量？？）

在 ready 前加 volatile 可以禁止指令重排，有人问为啥不加在 num 前面呢？

  • 因为加 volatile 可以禁止对它前面所有命令的指令重排，所以加一个就好了。

 

二 volatile原理

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

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

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

 

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.从单例双重锁检查来看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;
 　　}
}

字节码

// -------------------------------------> 加入对 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

其中

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

也许 jvm 会优化为：先执行 24 赋值，再执行 21 再调用构造方法 （INSTANCE = new Singleton();）。如果两个线程 t1，t2 按如下时间序列执行：

上图：

  • t1 线程执行 INSTANCE = new Singleton(); 这一句时21行和24行重排序了，也就是先赋值再调用构造方法。
  • t2 线程在t1赋值完还没调用初始化之前，在这个间隙正在执行外层的 if (INSTANCE == null) ，因为t1已经赋值了，不为 null ，所以直接返回了没有初始化的 instance，若 t2 再紧接着使用这个没有初始化的 instance ，就会出现问题

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

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

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

解决

给 instance 加上 volatile 修饰。构造方法一定不能排到 写屏障下面去

 

三 happens-before 规则

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

  • 线程解锁 m 之前对变量的写，对于接下来对 m 加锁（sychronized）的其它线程对该变量的读可见
  • 线程对 volatile 变量的写，对接下来其它线程对该变量的读可见
  • 线程 start 前对变量的写，对该线程开始后对该变量的读可见
  • 线程结束前对变量的写，对其它线程得知它结束后的读可见（比如其它线程调用 t1.isAlive() 或 t1.join()等待 它结束）
  • 线程 t1 打断 t2（interrupt）前对变量的写，对于其他线程得知 t2 被打断后对变量的读可见（通过 t2.interrupted 或 t2.isInterrupted）
  • 对变量默认值（0，false，null）的写，对其它线程对该变量的读可见