volatile关键字小总结

本文内容：
1.volatile语义
2.由volatile语义引出JMM
3.volatile不能保证原子性的解读
4.happens-before规则

一、volatile语义：

1.保证线程间变量的可见性

• 线程对volatile变量进行修改之后，要立刻回写到主内存。
• 线程对volatile变量读取的时候，要从主内存中读，而不是从工作内存。（关于主内存和工作内存的概念是在Java内存模型[JMM, Java Memory Model]中定义的）

我们知道CPU的处理速度和主存的读写速度不是一个量级的，为了平衡这种巨大的差距，每个CPU都会有缓存。因此，共享变量会先放在主存中，每个线程都有属于自己的工作内存，并且会把位于主存中的共享变量拷贝到自己的工作内存，之后的读写操作均使用位于工作内存的变量副本，并在某个时刻将工作内存的变量副本写回到主存中去。JMM就从抽象层次定义了这种方式，并且JMM决定了一个线程对共享变量的写入何时对其他线程是可见的。

JMM示意图如下：

image.png

线程A和线程B之间要完成通信的话，要经历如下两步：

1. 线程A从主内存中将共享变量读入线程A的工作内存后并进行操作，之后将数据重新写回到主内存中；
2. 线程B从主存中读取最新的共享变量

从横向去看看，线程A和线程B就好像通过共享变量在进行隐式通信。这其中有很有意思的问题，如果线程A更新后数据并没有及时写回到主存，而此时线程B读到的是过期的数据，这就出现了“脏读”现象。可以通过同步机制（控制不同线程间操作发生的相对顺序）来解决或者通过volatile关键字使得每次volatile变量都能够强制刷新到主存，从而对每个线程都是可见的。

2.禁止指令重排序

首先说一下指令重排序，看下以下线程A和线程B的部分代码：

线程A
content = initContent();    (1)
isInit = true;              (2)

线程B
while (isInit) {             (3)
    content.operation();     (4)
}

从常规的理解来看，上面的代码是不会出问题的，但是JVM可以对它们在不改变数据依赖关系的情况下进行任意排序以提高程序性能（遵循as-if-serial语义，即不管怎么重排序，单线程程序的执行结果不能被改变），而这里所说的数据依赖性仅针对单个处理器中执行的指令序列和单个线程中执行的操作，不同处理器之间和不同线程之间的数据依赖性不会被编译器和处理器考虑，也即是说对于线程A，代码(1)和代码(2)是不存在数据依赖性的，尽管代码(3)依赖于代码(2)的结果，但是由于代码(2)和代码(3)处于不同的线程之间，所以JVM可以不考虑线程B而对线程A中的代码(1)和代码(2)进行重排序，那么假设线程A中被重排序为如下顺序：

线程A：
isInit = true;              (2)
content = initContent();    (1)

对于线程B，则可能在执行代码(4)时，content并没有被初始化，而造成程序错误。那么该如何解决这种问题呢？可以使用关键字volatile。

volatile关键字除了之前提到的保证变量的内存可见性之外，另外一个重要的作用便是局部阻止重排序的发生，即保证被volatile关键字修饰的变量编译后的顺序与 也即是说如果对isInit使用了volatile关键字修饰，那么在线程A中，就能保证绝对的代码(1) happens-before 代码(2)，也便不会出现因为重排序而可能造成的异常。

具体实现禁止重排序的方式是插入内存屏障指令，比如Load-Load指令，Load-Store指令等等。。。

摘了一段：

内存屏障（Memory Barrier，或有时叫做内存栅栏，Memory Fence）是一种CPU指令，用于控制特定条件下的重排序和内存可见性问题。Java编译器会根据内存屏障的规则禁止重排序。

LoadLoad屏障：对于这样的语句Load1; LoadLoad; Load2，在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕。
StoreStore屏障：对于这样的语句Store1; StoreStore; Store2，在Store2及后续写入操作执行前，保证Store1的写入操作对其它处理器可见。
LoadStore屏障：对于这样的语句Load1; LoadStore; Store2，在Store2及后续写入操作被刷出前，保证Load1要读取的数据被读取完毕。
StoreLoad屏障：对于这样的语句Store1; StoreLoad; Load2，在Load2及后续所有读取操作执行前，保证Store1的写入对所有处理器可见。它的开销是四种屏障中最大的。在大多数处理器的实现中，这个屏障是个万能屏障，兼具其它三种内存屏障的功能。

二、volatile不能保证原子性

以i++操作为例。其包括读取、操作、赋值三个操作，下面是两个线程的操作顺序：

image.png

假如说线程A在做了i+1，但未赋值的时候，线程B就开始读取i，那么当线程A赋值i=1，并回写到主内存，而此时线程B已经不再需要i的值了（读取过程已经结束，不会再去主内存中取值了），而是直接交给处理器去做+1的操作，于是当线程B执行完并回写到主内存，i的值仍然是1，而不是预期的2。也就是说，volatile不能保证原子性。

三、happens-before原则

首先要知道，我们编写的程序都要经过优化后（编译器和处理器会对我们的程序进行优化以提高运行效率）才会被运行，优化分为很多种，其中有一种优化叫做重排序，重排序需要遵守happens-before规则，不能说你想怎么排就怎么排，如果那样岂不是乱了套。

其次要明确：两个操作间具有happens-before关系，并不意味着前一个操作必须要在后一个操作之前执行。happens-before仅仅要求前一个操作对后一个操作可见。也就是说，happens-before原则和一般意义上的时间先后是不同的。

happens-before部分规则如下：

• 程序顺序规则：一个线程中的每个操作，happens-before 于该线程中的任意后续操作。
• 监视器锁规则：对一个监视器锁的解锁，happens-before 于随后对这个监视器锁的加锁。
• volatile变量规则：对一个volatile域的写，happens-before 于任意后续对这个volatile域的读。
• 传递性：如果A happens-before B，且B happens-before C，那么A happens-before C。
• start()规则：如果线程A执行操作ThreadB.start()（启动线程B），那么A线程的ThreadB.start()操作happens-before于线程B中的任意操作。
• join()规则：如果线程A执行操作ThreadB.join()并成功返回，那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回。
• 程序中断规则：对线程interrupted()方法的调用先行于被中断线程的代码检测到中断时间的发生。
• 对象finalize规则：一个对象的初始化完成（构造函数执行结束）先行于发生它的finalize()方法的开始。