Java volatile详解
一 简介
volatile 是 Java 提供的一种轻量级的同步机制。Java 语言包含两种内在的同步机制：同步块（或方法）和 volatile 变量，相比于 synchronized（synchronized 通常称为重量级锁），volatile 更轻量级，因为它不会引起线程上下文的切换和调度。但是 volatile 变量的同步性较差（有时它更简单并且开销更低），而且其使用也更容易出错。
二 并发编程的3个基本概念
１．原子性
定义： 即一个操作或者多个操作要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。
原子性是拒绝多线程操作的，不论是多核还是单核，具有原子性的量，同一时刻只能有一个线程来对它进行操作。简而言之，在整个操作过程中不会被线程调度器中断的操作，都可认为是原子性。例如 a=1是原子性操作，但是 a++ 和 a +=1 就不是原子性操作。Java 中的原子性操作包括：
- 基本类型的读取和赋值操作，且赋值必须是值赋给变量，变量之间的相互赋值不是原子性操作。
- 所有引用 reference 的赋值操作
- java.concurrent.Atomic.* 包中所有类的一切操作
２．可见性
定义：指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。
在多线程环境下，一个线程对共享变量的操作对其他线程是不可见的。Java 提供了 volatile 来保证可见性，当一个变量被 volatile 修饰后，表示着线程本地内存无效，当一个线程修改共享变量后他会立即被更新到主内存中，其他线程读取共享变量时，会直接从主内存中读取。当然，synchronize 和 Lock 都可以保证可见性。synchronized 和 Lock 能保证同一时刻只有一个线程获取锁然后执行同步代码，并且在释放锁之前会将对变量的修改刷新到主存当中。因此可以保证可见性。
３．有序性
定义：即程序执行的顺序按照代码的先后顺序执行。
Java 内存模型中的有序性可以总结为：如果在本线程内观察，所有操作都是有序的；如果在一个线程中观察另一个线程，所有操作都是无序的。前半句是指“线程内表现为串行语义”，后半句是指“指令重排序”现象和“工作内存主主内存同步延迟”现象。
在 Java 内存模型中，为了效率是允许编译器和处理器对指令进行重排序，当然重排序不会影响单线程的运行结果，但是对多线程会有影响。Java 提供 volatile 来保证一定的有序性。最著名的例子就是单例模式里面的 DCL（双重检查锁）。另外，可以通过 synchronized 和 Lock 来保证有序性，synchronized 和 Lock 保证每个时刻是有一个线程执行同步代码，相当于是让线程顺序执行同步代码，自然就保证了有序性。
三 锁的互斥和可见性
锁提供了两种主要特性：互斥（mutual exclusion） 和可见性（visibility）。
１．互斥即一次只允许一个线程持有某个特定的锁，一次就只有一个线程能够使用该共享数据
２．可见性要更加复杂一些，它必须确保释放锁之前对共享数据做出的更改对于随后获得该锁的另一个线程是可见的。也即当一条线程修改了共享变量的值，新值对于其他线程来说是可以立即得知的。如果没有同步机制提供的这种可见性保证，线程看到的共享变量可能是修改前的值或不一致的值，这将引发许多严重问题。要使 volatile 变量提供理想的线程安全，必须同时满足下面两个条件：
- 对变量的写操作不依赖于当前值。
- 该变量没有包含在具有其他变量的不变式中。
实际上，这些条件表明，可以被写入 volatile 变量的这些有效值独立于任何程序的状态，包括变量的当前状态。事实上就是保证操作是原子性操作，才能保证使用 volatile 关键字的程序在并发时能够正确执行。
四 Java的内存模型JMM以及共享变量的可见性
JMM 决定一个线程对共享变量的写入何时对另一个线程可见，JMM 定义了线程和主内存之间的抽象关系：共享变量存储在主内存(Main Memory)中，每个线程都有一个私有的本地内存（Local Memory），本地内存保存了被该线程使用到的主内存的副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存中的变量。
对于普通的共享变量来讲，线程 A 将其修改为某个值发生在线程 A 的本地内存中，此时还未同步到主内存中去；而线程 B 已经缓存了该变量的旧值，所以就导致了共享变量值的不一致。解决这种共享变量在多线程模型中的不可见性问题，较粗暴的方式自然就是加锁，但是此处使用 synchronized 或者 Lock 这些方式太重量级了，比较合理的方式其实就是 volatile。
需要注意的是，JMM 是个抽象的内存模型，所以所谓的本地内存，主内存都是抽象概念，并不一定就真实的对应 cpu 缓存和物理内存。
五 volatile变量的特性
１．保证可见性，不保证原子性
- 当写一个volatile变量时，JMM会把该线程本地内存中的变量强制刷新到主内存中去
- 这个写会操作会导致其他线程中的volatile变量缓存无效
２．禁止指令重排
重排序是指编译器和处理器为了优化程序性能而对指令序列进行排序的一种手段。重排序需要遵守一定规则：
- 重排序操作不会对存在数据依赖关系的操作进行重排序
比如：a=1;b=a; 这个指令序列，由于第二个操作依赖于第一个操作，所以在编译时和处理器运行时这两个操作不会被重排序。 - 重排序是为了优化性能，但是不管怎么重排序，单线程下程序的执行结果不能被改变
比如：a=1;b=2;c=a+b这三个操作，第一步（a=1)和第二步(b=2)由于不存在数据依赖关系， 所以可能会发生重排序，但是c=a+b这个操作是不会被重排序的，因为需要保证最终的结果一定是c=a+b=3。
重排序在单线程下一定能保证结果的正确性，但是在多线程环境下，可能发生重排序，影响结果，下例中的1和2由于不存在数据依赖关系，则有可能会被重排序，先执行status=true再执行a=2。而此时线程B会顺利到达4处，而线程A中a=2这个操作还未被执行，所以b=a+1的结果也有可能依然等于2。
public class TestVolatile{
int a = 1;
boolean status = false;
//状态切换为true
public void changeStatus{
a = 2; //1
status = true; //2
}
//若状态为true，则为running
public void run(){
if(status){ //3
int b = a + 1; //4
System.out.println(b);
}
}
}
使用volatile关键字修饰共享变量便可以禁止这种重排序。若用volatile修饰共享变量，在编译时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序,volatile禁止指令重排序也有一些规则：
- 当程序执行到volatile变量的读操作或者写操作时，在其前面的操作的更改肯定全部已经进行，且结果已经对后面的操作可见；在其后面的操作肯定还没有进行
- 在进行指令优化时，不能将对volatile变量访问的语句放在其后面执行，也不能把volatile变量后面的语句放到其前面执行。
即执行到volatile变量时，其前面的所有语句都执行完，后面所有语句都未执行。且前面语句的结果对volatile变量及其后面语句可见。
六 volatile不适用的场景
１．volatile不适合复合操作
例如，inc++不是一个原子性操作，可以由读取、加、赋值3步组成，所以结果并不能达到30000。.
２．解决方法
-
采用synchronized
-
采用Lock
-
采用java并发包中的原子操作类，原子操作类是通过CAS循环的方式来保证其原子性的
七 volatile原理
volatile可以保证线程可见性且提供了一定的有序性，但是无法保证原子性。在JVM底层volatile是采用“内存屏障”来实现的。观察加入volatile关键字和没有加入volatile关键字时所生成的汇编代码发现，加入volatile关键字时，会多出一个lock前缀指令，lock前缀指令实际上相当于一个内存屏障（也成内存栅栏），内存屏障会提供3个功能：
- 它确保指令重排序时不会把其后面的指令排到内存屏障之前的位置，也不会把前面的指令排到内存屏障的后面；即在执行到内存屏障这句指令时，在它前面的操作已经全部完成
- 它会强制将对缓存的修改操作立即写入主存
- 如果是写操作，它会导致其他CPU中对应的缓存行无效
八 单例模式的双重锁为什么要加volatile
public class TestInstance{
private volatile static TestInstance instance;
public static TestInstance getInstance(){ //1
if(instance == null){ //2
synchronized(TestInstance.class){ //3
if(instance == null){ //4
instance = new TestInstance(); //5
}
}
}
return instance; //6
}
}
需要 volatile 关键字的原因是，在并发情况下，如果没有 volatile 关键字，在第5行会出现问题。instance = new TestInstance();可以分解为3行伪代码
a. memory = allocate() //分配内存
b. ctorInstanc(memory) //初始化对象
c. instance = memory //设置instance指向刚分配的地址
上面的代码在编译运行时，可能会出现重排序从a-b-c排序为a-c-b。在多线程的情况下会出现以下问题。当线程A在执行第5行代码时，B线程进来执行到第2行代码。假设此时A执行的过程中发生了指令重排序，即先执行了a和c，没有执行b。那么由于A线程执行了c导致instance指向了一段地址，所以B线程判断instance不为null，会直接跳到第6行并返回一个未初始化的对象。
九 常见问题汇总
１．说说你对volatile关键字的理解
就我理解的而言，被volatile修饰的共享变量，就具有了以下两点特性：
- 保证了不同线程对该变量操作的内存可见性;
- 禁止指令重排序
２．详细说下什么是内存可见性，什么又是重排序
这个聊起来可就多了，我还是从Java内存模型说起吧。 Java虚拟机规范试图定义一种Java内存模型（JMM）,来屏蔽掉各种硬件和操作系统的内存访问差异，让Java程序在各种平台上都能达到一致的内存访问效果。简单来说，由于CPU执行指令的速度是很快的，但是内存访问的速度就慢了很多，相差的不是一个数量级，所以搞处理器的那群大佬们又在CPU里加了好几层高速缓存。 在Java内存模型里，对上述的优化又进行了一波抽象。JMM规定所有变量都是存在主存中的，类似于上面提到的普通内存，每个线程又包含自己的工作内存，方便理解就可以看成CPU上的寄存器或者高速缓存。所以线程的操作都是以工作内存为主，它们只能访问自己的工作内存，且工作前后都要把值在同步回主内存。 这么说得我自己都有些不清楚了，拿张纸画一下：
在线程执行时，首先会从主存中read变量值，再load到工作内存中的副本中，然后再传给处理器执行，执行完毕后再给工作内存中的副本赋值，随后工作内存再把值传回给主存，主存中的值才更新。 使用工作内存和主存，虽然加快的速度，但是也带来了一些问题。比如看下面一个例子：
i = i + 1;
假设i初值为0，当只有一个线程执行它时，结果肯定得到1，当两个线程执行时，会得到结果2吗？这倒不一定了。可能存在这种情况：
线程1： load i from 主存 // i = 0
i + 1 // i = 1
线程2： load i from主存 // 因为线程1还没将i的值写回主存，所以i还是0
i + 1 //i = 1
线程1: save i to 主存
线程2： save i to 主存
如果两个线程按照上面的执行流程，那么i最后的值居然是1了。如果最后的写回生效的慢，你再读取i的值，都可能是0，这就是缓存不一致问题。 下面就要提到你刚才问到的问题了，JMM主要就是围绕着如何在并发过程中如何处理原子性、可见性和有序性这3个特征来建立的，通过解决这三个问题，可以解除缓存不一致的问题。而volatile跟可见性和有序性都有关。
３．具体说说这三个特性
１．原子性(Atomicity)： Java中，对基本数据类型的读取和赋值操作是原子性操作，所谓原子性操作就是指这些操作是不可中断的，要做一定做完，要么就没有执行。 比如：
i = 2;
j = i;
i++;
i = i + 1;
上面4个操作中，i=2是读取操作，必定是原子性操作，j=i你以为是原子性操作，其实吧，分为两步，一是读取i的值，然后再赋值给j,这就是2步操作了，称不上原子操作，i++和i = i + 1其实是等效的，读取i的值，加1，再写回主存，那就是3步操作了。所以上面的举例中，最后的值可能出现多种情况，就是因为满足不了原子性。 这么说来，只有简单的读取，赋值是原子操作，还只能是用数字赋值，用变量的话还多了一步读取变量值的操作。有个例外是，虚拟机规范中允许对64位数据类型(long和double)，分为2次32为的操作来处理，但是最新JDK实现还是实现了原子操作的。 JMM只实现了基本的原子性，像上面i++那样的操作，必须借助于synchronized和Lock来保证整块代码的原子性了。线程在释放锁之前，必然会把i的值刷回到主存的。
２．可见性(Visibility)： 说到可见性，Java就是利用volatile来提供可见性的。 当一个变量被volatile修饰时，那么对它的修改会立刻刷新到主存，当其它线程需要读取该变量时，会去内存中读取新值。而普通变量则不能保证这一点。 其实通过synchronized和Lock也能够保证可见性，线程在释放锁之前，会把共享变量值都刷回主存，但是synchronized和Lock的开销都更大。
３．有序性（Ordering） JMM是允许编译器和处理器对指令重排序的，但是规定了as-if-serial语义，即不管怎么重排序，程序的执行结果不能改变。比如下面的程序段：
double pi = 3.14; //A
double r = 1; //B
double s= pi * r * r;//C
上面的语句，可以按照A->B->C执行，结果为3.14,但是也可以按照B->A->C的顺序执行，因为A、B是两句独立的语句，而C则依赖于A、B，所以A、B可以重排序，但是C却不能排到A、B的前面。JMM保证了重排序不会影响到单线程的执行，但是在多线程中却容易出问题。 比如这样的代码:
int a = 0;
bool flag = false;
public void write() {
a = 2; //1
flag = true; //2
}
public void multiply() {
if (flag) { //3
int ret = a * a;//4
}
}
假如有两个线程执行上述代码段，线程1先执行write，随后线程2再执行multiply，最后ret的值一定是4吗？结果不一定：
如图所示，write方法里的1和2做了重排序，线程1先对flag赋值为true，随后执行到线程2，ret直接计算出结果，再到线程1，这时候a才赋值为2,很明显迟了一步。 这时候可以为flag加上volatile关键字，禁止重排序，可以确保程序的有序性，也可以上重量级的synchronized和Lock来保证有序性,它们能保证那一块区域里的代码都是一次性执行完毕的。 另外，JMM具备一些先天的有序性,即不需要通过任何手段就可以保证的有序性，通常称为happens-before原则。<
1.程序顺序规则： 一个线程中的每个操作，happens-before于该线程中的任意后续操作
2.监视器锁规则：对一个线程的解锁，happens-before于随后对这个线程的加锁
3.volatile变量规则： 对一个volatile域的写，happens-before于后续对这个volatile域的读
4.传递性：如果A happens-before B ,且 B happens-before C, 那么 A happens-before C
5.start()规则： 如果线程A执行操作ThreadB_start()(启动线程B) , 那么A线程的ThreadB_start()happens-before 于B中的任意操作
6.join()原则： 如果A执行ThreadB.join()并且成功返回，那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回。 7.interrupt()原则： 对线程interrupt()方法的调用先行发生于被中断线程代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测是否有中断发生
8.finalize()原则：一个对象的初始化完成先行发生于它的finalize()方法的开始
第1条规则程序顺序规则是说在一个线程里，所有的操作都是按顺序的，但是在JMM里其实只要执行结果一样，是允许重排序的，这边的happens-before强调的重点也是单线程执行结果的正确性，但是无法保证多线程也是如此。 第2条规则监视器规则其实也好理解，就是在加锁之前，确定这个锁之前已经被释放了，才能继续加锁。 第3条规则，就适用到所讨论的volatile，如果一个线程先去写一个变量，另外一个线程再去读，那么写入操作一定在读操作之前。 第4条规则，就是happens-before的传递性。 后面几条就不再一一赘述了。
４．volatile关键字如何满足并发编程的三大特性的
那就要重提 volatile 变量规则： 对一个 volatile 域的写，happens-before 于后续对这个 volatile 域的读。 这条再拎出来说，其实就是如果一个变量声明成是 volatile 的，那么当我读变量时，总是能读到它的最新值，这里最新值是指不管其它哪个线程对该变量做了写操作，都会立刻被更新到主存里，我也能从主存里读到这个刚写入的值。也就是说 volatile 关键字可以保证可见性以及有序性。 继续拿上面的一段代码举例：
int a = 0;
bool flag = false;
public void write() {
a = 2; //1
flag = true; //2
}
public void multiply() {
if (flag) { //3
int ret = a * a;//4
}
}
这段代码不仅仅受到重排序的困扰，即使1、2没有重排序。3也不会那么顺利的执行的。假设还是线程1先执行 write 操作，线程2再执行 multiply 操作，由于线程1是在工作内存里把 flag 赋值为1，不一定立刻写回主存，所以线程2执行时，multiply 再从主存读 flag 值，仍然可能为 false，那么括号里的语句将不会执行。 如果改成下面这样：
int a = 0;
volatile bool flag = false;
public void write() {
a = 2; //1
flag = true; //2
}
public void multiply() {
if (flag) { //3
int ret = a * a;//4
}
}
那么线程1先执行write,线程2再执行multiply。根据happens-before原则，这个过程会满足以下3类规则： 程序顺序规则：1 happens-before 2; 3 happens-before 4; (volatile限制了指令重排序，所以1 在2 之前执行) volatile规则：2 happens-before 3 传递性规则：1 happens-before 4 当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存 当读一个volatile变量时，JMM 会把该线程对应的本地内存置为无效，线程接下来将从主内存中读取共享变量。
５．volatile的两点内存语义能保证可见性和有序性，但是能保证原子性吗？
首先我回答是不能保证原子性，要是说能保证，也只是对单个 volatile 变量的读/写具有原子性，但是对于类似 volatile++ 这样的复合操作就无能为力了，比如下面的例子：
public class Test {
public volatile int inc = 0;
public void increase() {
inc++;
}
public static void main(String[] args) {
final Test test = new Test();
for(int i=0;i<10;i++){
new Thread(){
public void run() {
for(int j=0;j<1000;j++)
test.increase();
};
}.start();
}
while(Thread.activeCount()>1) //保证前面的线程都执行完
Thread.yield();
System.out.println(test.inc);
}
按道理来说结果是10000，但是运行下很可能是个小于10000的值。有人可能会说 volatile 不是保证了可见性啊，一个线程对 inc 的修改，另外一个线程应该立刻看到啊！可是这里的操作 inc++是个复合操作啊，包括读取 inc 的值，对其自增，然后再写回主存。 假设线程 A，读取了 inc 的值为10，这时候被阻塞了，因为没有对变量进行修改，触发不了 volatile 规则。 线程B此时也读读 inc 的值，主存里 inc 的值依旧为10，做自增，然后立刻就被写回主存了，为11。 此时又轮到线程A执行，由于工作内存里保存的是10，所以继续做自增，再写回主存，11又被写了一遍。所以虽然两个线程执行了两次 increase()，结果却只加了一次。 有人说，volatile 不是会使缓存行无效的吗？但是这里线程A读取到线程B也进行操作之前，并没有修改 inc 值，所以线程B读取的时候，还是读的10。 又有人说，线程B将11写回主存，不会把线程A的缓存行设为无效吗？但是线程A的读取操作已经做过了啊，只有在做读取操作时，发现自己缓存行无效，才会去读主存的值，所以这里线程A只能继续做自增了。 综上所述，在这种复合操作的情景下，原子性的功能是维持不了了。但是 volatile 在上面那种设置 flag 值的例子里，由于对 flag 的读/写操作都是单步的，所以还是能保证原子性的。 要想保证原子性，只能借助于 synchronized,Lock 以及并发包下的 atomic 的原子操作类了，即对基本数据类型的 自增（加1操作），自减（减1操作）、以及加法操作（加一个数），减法操作（减一个数）进行了封装，保证这些操作是原子性操作。
６．volatile底层的实现机制
如果把加入 volatile 关键字的代码和未加入 volatile 关键字的代码都生成汇编代码，会发现加入 volatile 关键字的代码会多出一个 lock 前缀指令。 lock 前缀指令实际相当于一个内存屏障，内存屏障提供了以下功能：
- 重排序时不能把后面的指令重排序到内存屏障之前的位置
- 使得本CPU的Cache写入内存 ** **
- 写入动作也会引起别的CPU或者别的内核无效化其Cache，相当于让新写入的值对别的线程可见
７． 你在哪里会使用到volatile，举两个例子
- 状态量标记，就如上面对 flag 的标记，我重新提一下：
int a = 0;
volatile bool flag = false;
public void write() {
a = 2; //1
flag = true; //2
}
public void multiply() {
if (flag) { //3
int ret = a * a;//4
}
}
这种对变量的读写操作，标记为 volatile 可以保证修改对线程立刻可见。比 synchronized,Lock 有一定的效率提升。
- 单例模式的实现，典型的双重检查锁定（DCL）
class Singleton{
private volatile static Singleton instance = null;
private Singleton() {
}
public static Singleton getInstance() {
if(instance==null) {
synchronized (Singleton.class) {
if(instance==null)
instance = new Singleton();
}
}
return instance;
}
}
这是一种懒汉的单例模式，使用时才创建对象，而且为了避免初始化操作的指令重排序，给 instance 加上了 volatile。