深入volatile关键字（一）并发编程的三个重要特性和指令重排以及Happens-before原则

1 并发编程的三个重要特性

1.1 原子性

原子性是指在一次的操作或者多次操作中，要么所有的操作全部都得到了执行并且不会受到任何因素的干扰而中断，要么所有的操作都不执行。

说起原子性一般都会用银行转账来进行举例说明，比如从Alex的账号往Tina的账号转入1000元，这个动作将包含两个最基本的操作：从Alex的账号上扣除1000元；给Tina的账号增加1000元。这两个操作必须符合原子性的要求，要么都成功要么都失败，总之不能出现Alex的账号扣除了1000元，但是Tina的账号并未增加1000元或者Alex账号未扣除1000元，Tina的账号反倒增加了1000元的情况。

同样在我们编写代码的过程中，比如一个简单的赋值语句：

Object o = new Object();

引用类型o占用四个字节（32位），假设这样的赋值语句不能够保证原子性的话，那么会导致赋值出现错误的数据。

注意：

• volatile关键字不保证数据的原子性，synchronized关键字保证，自JDK1.5版本起，其提供的原子类型变量也可以保证原子性。
• 两个原子性的操作结合在一起未必还是原子性的

1.2 可见性

可见性是指，当一个线程对共享变量进行了修改，那么另外的线程可以立即看到修改后的最新值。

这个问题就是volatile关键字引入中的案例问题。Reader线程会将init_value从主内存缓存到CPU Cache中，也就是从主内存缓存到线程的本地内存中，Writer线程对init_value的修改对Reader线程是不可见的。

1.3 有序性

有序性是指程序代码在执行过程中的先后顺序，由于Java在编译器以及运行期的优化，导致了代码的执行顺序未必就是开发者编写代码时的顺序。

int x = 10;
int y =0;
x++;
y = 20;

这段代码定义了两个int类型的变量x和y，对x进行自增操作，对y进行赋值操作，从编写程序的角度来看上面的代码肯定是顺序执行下来的，但是在JVM真正地运行这段代码的时候未必会是这样的顺序，比如y=20语句有可能会在x++语句的前面得到执行，这种情况就是我们通常所说的指令重排序（Instruction Recorder）。

1.3.1 指令重排

一般来说，处理器为了提高程序的运行效率，可能会对输入的代码指令做一定的优化，它不会百分之百的保证代码的执行顺序严格按照编写代码中的顺序来进行，但是它会保证程序的最终运算结果是编码时所期望的那样，比如上文中的x++与y=20不管它们的执行顺序如何，执行完上面的四行代码之后得到的结果肯定都是x=11，y=20。

当然对指令的重排序要严格遵守指令之间的数据依赖关系，并不是可以任意进行重排序的，比如下面的代码片段：

int x = 10;
int y = 0;
x++;
y=x+1;

对于这段代码有可能它的执行顺序就是代码本身的顺序，有可能发生了重排序导致int y=0优先于int x=10执行，但是绝对不可能出现y=x+1优先于x++执行的执行情况，如果一个指令x在执行的过程中需要用到指令y的执行结果，那么处理器会保证指令y在指令x之前执行，这就好比y=x+1执行之前肯定要先执行x++一样。

在单线程情况下，无论怎样的重排序最终都会保证程序的执行结果和代码顺序执行的结果是完全一致的，但是在多线程的情况下，如果有序性得不到保证，那么很有可能就会出现非常大的问题：

private boolean initialized = false;
private Context context;
public Context load(){
	if(!initialized){
		context=loadContext();
		initialized = true;
	}
	return context;
}

这段代码使用boolean变量initialized来控制context是否已经被加载过了，在单线程下无论怎样的重排序，最终返回给使用者的context都是可用的。

多线程的情况下发生了重排序，比如context=loadContext（）的执行被重排序到了initialized=true的后面，那么这将是灾难性的了。比如第一个线程首先判断到initialized=false，因此准备执行context的加载，但是它在执行loadContext（）方法之前二话不说先将initialized置为true然后再执行loadContext（）方法，那么如果另外一个线程也执行load方法，发现此时initialized已经为true了，则直接返回一个还未被加载成功的context，那么在程序的运行过程中势必会出现错误。

2 JMM（Java的内存模型）如何保证三大特性

Java的内存模型规定了所有的变量都是存在于主内存（RAM）当中的，而每个线程都有自己的工作内存或者本地内存（这一点很像CPU的Cache），线程对变量的所有操作都必须在自己的工作内存中进行，而不能直接对主内存进行操作，并且每一个线程都不能访问其他线程的工作内存或者本地内存。

比如在某个线程中对变量i的赋值操作i=1，该线程必须在本地内存中对i进行修改之后才能将其写入主内存之中。

2.1 JMM与原子性

在Java语言中，对基本数据类型的变量读取赋值操作都是原子性的，对引用类型的变量读取和赋值的操作也是原子性的，因此诸如此类的操作是不可被中断的，要么执行，要么不执行。

下面就举几个例子：

1. x=10；赋值操作

   x=10的操作是原子性的，执行线程首先会将x=10写入工作内存中，然后再将其写入主内存（有可能在往主内存进行数值刷新的过程中其他线程也在对其进行刷新操作，比如另外一个线程将其写为11，但是最终的结果肯定要么是10，要么是11，不可能出现其他情况，单就赋值语句这一点而言其是原子性的）。

2. y=x；赋值操作

   这条操作语句是非原子性的，因为它包含如下两个重要的步骤。

   • 执行线程从主内存中读取x的值，然后将其存入当前线程的工作内存之中（如果x已经存在于执行线程的工作内存中，则直接获取）。
   • 在执行线程的工作内存中修改y的值为x，然后将y的值写入主内存之中。
   • 虽然前两步都是原子类型的操作，但是合在一起就不是原子操作了。

3. y++；自增操作
   这条操作语句是非原子性的，因为它包含三个重要的步骤：

   1. 执行线程从主内存中读取y的值（如果y已经存在于执行线程的工作内存中，则直接获取），然后将其存入当前线程的工作内存之中。
   2. 执行线程工作内存中为y执行加1操作。
   3. 将y的值写入主内存。

4. z=z+1；加一操作（与自增操作等价）

   1. 执行线程从主内存中读取z的值（如果z已经存在于执行线程的工作内存中，则直接获取），然后将其存入当前线程的工作内存之中。
   2. 在执行线程工作内存中为z执行加1操作。
   3. 将z的值写入主内存。

我们可以发现只有第一种操作即赋值操作具备原子性，其余的均不具备原子性，由此我们可以得出以下几个结论：

• 多个原子性的操作在一起就不再是原子性操作了。
• 简单的读取与赋值操作是原子性的，将一个变量赋给另外一个变量的操作不是原子性的。
• Java内存模型（JMM）只保证了基本读取和赋值的原子性操作，其他的均不保证，如果想要使得某些代码片段具备原子性，需要使用关键字synchronized，或者JUC中的lock。如果想要使得int等类型自增操作具备原子性，可以使用JUC包下的原子封装类型java.util.concurrent.atomic.*
• volatile关键字不具备保证原子性的语义。

2.2 JMM与可见性

在多线程的环境下，如果某个线程首次读取共享变量，则首先到主内存中获取该变量，然后存入工作内存中，以后只需要在工作内存中读取该变量即可。同样如果对该变量执行了修改的操作，则先将新值写入工作内存中，然后再刷新至主内存中。

这里就存在一个问题：由于是什么时候最新的值会被刷新至主内存中是不确定的，所以就不无法保证数据的一致性。

java提供了三种方式保证可见性：

1. 使用关键字volatile，当一个变量被volatile关键字修饰时，对于共享资源的读操作会直接在主内存中进行（当然也会缓存到工作内存中，当其他线程对该共享资源进行了修改，则会导致当前线程在工作内存中的共享资源失效，所以必须从主内存中再次获取），对于共享资源的写操作当然是先要修改工作内存，但是修改结束后会立刻将其刷新到主内存中。
2. 通过synchronized关键字能够保证可见性，synchronized关键字能够保证同一时刻只有一个线程获得锁，然后执行同步方法，并且还会确保在锁释放之前，会将对变量的修改刷新到主内存当中。
3. 通过JUC提供的显式锁Lock也能够保证可见性，Lock的lock方法能够保证在同一时刻只有一个线程获得锁然后执行同步方法，并且会确保在锁释放（Lock的unlock方法）之前会将对变量的修改刷新到主内存当中。

2.3 JMM与有序性

在Java的内存模型中，允许编译器和处理器对指令进行重排序，在单线程的情况下，重排序并不会引起什么问题，但是在多线程的情况下，重排序会影响到程序的正确运行，Java提供了三种保证有序性的方式

1. 使用volatile关键字来保证有序性。
2. 使用synchronized关键字来保证有序性。
3. 使用显式锁Lock来保证有序性。

后两者采用了同步的机制，同步代码在执行的时候与在单线程情况下一样自然能够保证顺序性（最终结果的顺序性）。

2.3.1 Happens-before原则

此外，Java的内存模型具备一些天生的有序性规则，不需要任何同步手段就能够保证有序性，这个规则被称为Happens-before原则。如果两个操作的执行次序无法从happens-before原则推导出来，那么它们就无法保证有序性，也就是说虚拟机或者处理器可以随意对它们进行重排序处理。

那么什么是Happens-before原则呢？

1. 程序次序规则：在一个线程内，代码按照编写时的次序执行，编写在后面的操作发生于编写在前面的操作之后。程序按照编写的顺序来执行，但是虚拟机还是可能会对程序代码的指令进行重排序，只要确保在一个线程内最终的结果和代码顺序执行的结果一致即可。
2. 锁定规则：无论是在单线程还是在多线程的环境下，如果同一个锁是锁定状态，那么必须先对其执行释放操作之后才能继续进行lock操作。
3. volatile变量规则：对一个变量的写操作要早于对这个变量之后的读操作。如果一个变量使用volatile关键字修饰，一个线程对它进行读操作，一个线程对它进行写操作，那么写入操作肯定要先行发生于读操作
4. 传递规则：如果操作A先于操作B，而操作B又先于操作C，则可以得出操作A肯定要先于操作C，这一点说明了happens-before原则具备传递性。
5. ·线程启动规则：Thread对象的start（）方法先行发生于对该线程的任何动作，这也是我们在第一部分中讲过的，只有start之后线程才能真正运行，否则Thread也只是一个对象而已。
6. 线程中断规则：对线程执行interrupt（）方法肯定要优先于捕获到中断信号，这句话的意思是指如果线程收到了中断信号，那么在此之前势必要有interrupt（）。
7. 线程的终结规则：线程中所有的操作都要先行发生于线程的终止检测，通俗地讲，线程的任务执行、逻辑单元执行肯定要发生于线程死亡之前。
8. 对象的终结规则：一个对象初始化的完成先行发生于finalize（）方法之前，这个更没什么好说的了，先有生后有死。