多线程（四）volatile

1 ⼏个基本概念

1.1 内存可⻅性

• JMM有⼀个主内存，每个线程有⾃⼰私有的⼯作内存，⼯作内存中保存了⼀些变量在主内存的拷⻉。
• 内存可⻅性，指的是线程之间的可⻅性，当⼀个线程修改了共享变量时，另⼀个线程可以读取到这个修改后的值。

1.2 重排序

为优化程序性能，对原有的指令执⾏顺序进⾏优化重新排序。重排序可能发⽣在多个阶段，⽐如编译重排序、CPU重排序等。

1.3 happens-before规则

是⼀个给程序员使⽤的规则，只要程序员在写代码的时候遵循happens-before规则，JVM就能保证指令在多线程之间的顺序性符合程序员的预期。

1.4 缓存一致性问题

• 计算机在执行程序时，每条指令都是在CPU中执行的，而执行指令过程中，势必涉及到数据的读取和写入。由于程序运行过程中的临时数据是存放在主存（物理内存）当中的，这时就存在一个问题，由于CPU执行速度很快，而从内存读取数据和向内存写入数据的过程跟CPU执行指令的速度比起来要慢的多，因此如果任何时候对数据的操作都要通过和内存的交互来进行，会大大降低指令执行的速度。因此在CPU里面就有了高速缓存。
• -也就是，当程序在运行过程中，会将运算需要的数据从主存复制一份到CPU的高速缓存当中，那么CPU进行计算时就可以直接从它的高速缓存读取数据和向其中写入数据，当运算结束之后，再将高速缓存中的数据刷新到主存当中。举个简单的例子，比如下面的这段代码：

i = i + 1;

• 当线程执行这个语句时，会先从主存当中读取i的值，然后复制一份到高速缓存当中，然后CPU执行指令对i进行加1操作，然后将数据写入高速缓存，最后将高速缓存中i最新的值刷新到主存当中。
• 这个代码在单线程中运行是没有任何问题的，但是在多线程中运行就会有问题了。在多核CPU中，每条线程可能运行于不同的CPU中，因此每个线程运行时有自己的高速缓存（对单核CPU来说，其实也会出现这种问题，只不过是以线程调度的形式来分别执行的）。本文我们以多核CPU为例。
• 比如同时有2个线程执行这段代码，假如初始时i的值为0，那么我们希望两个线程执行完之后i的值变为2。但是事实会是这样吗？
• 可能存在下面一种情况：初始时，两个线程分别读取i的值存入各自所在的CPU的高速缓存当中，然后线程1进行加1操作，然后把i的最新值1写入到内存。此时线程2的高速缓存当中i的值还是0，进行加1操作之后，i的值为1，然后线程2把i的值写入内存。
• 最终结果i的值是1，而不是2。这就是著名的缓存一致性问题。通常称这种被多个线程访问的变量为共享变量。
• 也就是说，如果一个变量在多个CPU中都存在缓存（一般在多线程编程时才会出现），那么就可能存在缓存不一致的问题。

2 volatile的内存语义

在Java中，volatile关键字有特殊的内存语义。volatile主要有以下两个功能：

• 保证变量的内存可⻅性
• 禁⽌volatile变量与普通变量重排序（JSR133提出，Java 5 开始才有这个“增强的volatile内存语义”）

2.1 内存可⻅性

以⼀段示例代码开始：

public class VolatileExample {
	int a = 0;
	volatile boolean flag = false;
	public void writer() {
		a = 1; // step 1
		flag = true; // step 2
	}
	public void reader() {
		if (flag) { // step 3
			System.out.println(a); // step 4
		}
	}
}

• 在这段代码⾥，我们使⽤ volatile 关键字修饰了⼀个 boolean 类型的变量 flag 。
• 所谓内存可⻅性，指的是当⼀个线程对 volatile 修饰的变量进⾏写操作（⽐如step 2）时，JMM会⽴即把该线程对应的本地内存中的共享变量的值刷新到主内存；当⼀个线程对 volatile 修饰的变量进⾏读操作（⽐如step 3）时，JMM会把⽴即该线程对应的本地内存置为⽆效，从主内存中读取共享变量的值。
• 在这⼀点上，volatile与锁具有相同的内存效果，volatile变量的写和锁的释放具有相同的内存语义，volatile变量的读和锁的获取具有相同的内存语义。
• 假设在时间线上，线程A先执行⽅法 writer ⽅法，线程B后执⾏ reader ⽅法。那必然会有下图：
  
  ⽽如果 flag 变量没有⽤ volatile 修饰，在step 2，线程A的本地内存⾥⾯的变量就不会⽴即更新到主内存，那随后线程B也同样不会去主内存拿最新的值，仍然使⽤线程B本地内存缓存的变量的值 a = 0，flag = false 。

2.2 禁⽌重排序

• 在JSR-133之前的旧的Java内存模型中，是允许volatile变量与普通变量重排序的。

• 那上⾯的案例中，可能就会被重排序成下列时序来执⾏：

1. 线程A写volatile变量，step 2，设置flag为true；
2. 线程B读同⼀个volatile，step 3，读取到flag为true；
3. 线程B读普通变量，step 4，读取到 a = 0；
4. 线程A修改普通变量，step 1，设置 a = 1；

• 可⻅，如果volatile变量与普通变量发⽣了重排序，虽然volatile变量能保证内存可⻅性，也可能导致普通变量读取错误。

• 所以在旧的内存模型中，volatile的写-读就不能与锁的释放-获取具有相同的内存语义了。

• 为了提供⼀种⽐锁更轻量级的线程间的通信机制，JSR-133专家组决定增强volatile的内存语义：严格限制编译器和处理器对volatile变量与普通变量的重排序。

• 编译器还好说，JVM是怎么还能限制处理器的重排序的呢？它是通过内存屏障来实
  现的。

• 什么是内存屏障？硬件层⾯，内存屏障分两种：读屏障（Load Barrier）和写屏障（Store Barrier）。内存屏障有两个作⽤：

1. 阻⽌屏障两侧的指令重排序；
2. 强制把写缓冲区/⾼速缓存中的脏数据等写回主内存，或者让缓存中相应的数据失效。(注意:这⾥的缓存主要指的是CPU缓存)

• 再逐个解释⼀下这⼏个屏障。注：下述Load代表读操作，Store代表写操作

• LoadLoad屏障：对于这样的语句Load1; LoadLoad; Load2，在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕。
• StoreStore屏障：对于这样的语句Store1; StoreStore; Store2，在Store2及后续写⼊操作执⾏前，保证Store1的写⼊操作对其它处理器可⻅。
• LoadStore屏障：对于这样的语句Load1; LoadStore; Store2，在Store2及后续写⼊操作被刷出前，保证Load1要读取的数据被读取完毕。
• StoreLoad屏障：对于这样的语句Store1; StoreLoad; Load2，在Load2及后续所有读取操作执⾏前，保证Store1的写⼊对所有处理器可⻅。它的开销是四种屏障中最⼤的（冲刷写缓冲器，清空⽆效化队列）。

• 在⼤多数处理器的实现中，这个屏障是个万能屏障，兼具其它三种内存屏障的功能

3 volatile的⽤途

• 从volatile的内存语义上来看，volatile可以保证内存可⻅性且禁⽌重排序。
• 在保证内存可⻅性这⼀点上，volatile有着与锁相同的内存语义，所以可以作为⼀个“轻量级”的锁来使⽤。
• 但由于volatile仅仅保证对单个volatile变量的读/写具有原⼦性，⽽锁可以保证整个临界区代码的执⾏具有原⼦性。所以在功能上，锁⽐volatile更强⼤；在性能上，volatile更有优势。
• 在禁⽌重排序这⼀点上，volatile也是⾮常有⽤的。⽐如我们熟悉的单例模式，其中有⼀种实现⽅式是“双重锁检查”，⽐如这样的代码：

public class Singleton {
	private static Singleton instance; // 不使⽤volatile关键字
	// 双重锁检验
	public static Singleton getInstance() {
		if (instance == null) { // 第7⾏
			synchronized (Singleton.class) {
				if (instance == null) {
					instance = new Singleton(); // 第10⾏
				}
			}
		}
		return instance;
	}
}

• 如果这⾥的变量声明不使⽤volatile关键字，是可能会发⽣错误的。它可能会被重排序：