Java-volatile-面试官最喜欢问的关键字之一
引言
volatile关键字可以说是面试官最喜欢问的关键字之一了。
概述
在Java相关的岗位面试中，很多面试官都喜欢考察面试者对Java并发的了解程度，而以 volatile关键字作为一个小的切入点，往往可以一问到底，把Java内存模型（JMM），Java并发编程的一些特性都牵扯出来，深入地话还可以考察 JVM底层实现以及操作系统的相关知识。下面我们以一次假想的面试过程，来深入了解下 volitile关键字吧！
模拟面试官问题
1.面试官：Java并发这块了解得怎么样？说说你对volatile关键字的理解
就我理解的而言，被 volatile修饰的共享变量，就具有了以下两点特性：
- 保证了不同线程对该变量操作的内存可见性;
- 禁止指令重排序;
2.面试官：能否详细说下什么是内存可见性，什么又是重排序呢？
这个聊起来可就多了，我还是从Java内存模型说起吧。
Java虚拟机规范试图定义一种Java内存模型（ JMM）,来屏蔽掉各种硬件和操作系统的内存访问差异，让Java程序在各种平台上都能达到一致的内存访问效果。简单来说，由于CPU执行指令的速度是很快的，但是内存访问的速度就慢了很多，相差的不是一个数量级，所以搞处理器的那群大佬们又在CPU里加了好几层高速缓存。
在Java内存模型里，对上述的优化又进行了一波抽象。JMM规定所有变量都是存在主存中的，类似于上面提到的普通内存，每个线程又包含自己的工作内存，方便理解就可以看成CPU上的寄存器或者高速缓存。所以线程的操作都是以工作内存为主，它们只能访问自己的工作内存，且工作前后都要把值在同步回主内存。
这么说得我自己都有些不清楚了，拿张纸画一下：
在线程执行时，首先会从主存中 read变量值，再 load到工作内存中的副本中，然后再传给处理器执行，执行完毕后再给工作内存中的副本赋值，随后工作内存再把值传回给主存，主存中的值才更新。
使用工作内存和主存，虽然加快的速度，但是也带来了一些问题。比如看下面一个例子：
i = i +1;假设 i初值为 0，当只有一个线程执行它时，结果肯定得到 1，当两个线程执行时，会得到结果 2吗？这倒不一定了。可能存在这种情况： i的自加1的简单程序至少在JMM中需要如下过程（单个线程）： 从主存读取变量i于工作内存中（Load）–>变量i写到CPU中进行加1操作–>变量i写入到主存中（Save） 可见Java内存模型告诉我们，单变量简单的加1操作并非是原子操作。
线程1： load i from 主存 //此时 i =0;
i + 1 //i=1
线程2： load i from 主存 //因为线程1还没有写回主存，所以i还是0
i+1 //i=1
线程1： save i to 主存
线程2: save i to 主存如果两个线程按照上面的执行流程，那么 i最后的值居然是 1了。如果最后的写回生效的慢，你再读取 i的值，都可能是 0，这就是缓存不一致问题。
下面就要提到你刚才问到的问题了， JMM主要就是围绕着如何在并发过程中如何处理原子性、可见性和有序性这3个特征来建立的，通过解决这三个问题，可以解除缓存不一致的问题。而 volatile跟可见性和有序性都有关。
3.面试官：那你具体说说这三个特性呢？
- 原子性(Atomicity) Java中，对基本数据类型的读取和赋值操作是原子性操作，所谓原子性操作就是指这些操作是不可中断的，要做一定做完，要么就没有执行。比如：
i =2;
j =i;
i++;
i =i +1; 在上述四个操作中只有i=2是原子性操作，因为只有赋值操作。j=i则是非原子性操作，因为首先进行变量i的读取操作，其次再进行变量j的赋值操作。其余语句类似地不满足于操作的原子性。
这么说来，只有简单的读取，赋值是原子操作，还只能是用数字赋值，用变量的话还多了一步读取变量值的操作。有个例外是，虚拟机规范中允许对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;
double r =1;
double s = pi * r *r;上面的语句，可以按照 A->B->C执行，结果为 3.14,但是也可以按照 B->A->C的顺序执行，因为 A、B是两句独立的语句，而 C则依赖于 A、 B，所以 A、 B可以重排序，但是 C却不能排到 A、 B的前面。JMM保证了重排序不会影响到单线程的执行，但是在多线程中却容易出问题。
比如这样的代码:
int a =0;
bolean flag =false;
public void write(){
a=2; //1
flag =true; //2
}
public void multiple(){
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原则。<<JSR-133：JavaMemoryModelandThreadSpecification>>定义了如下 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执行操作ThreadBstart()(启动线程B) , 那么A线程的ThreadBstart()happens-before 于B中的任意操作
- join()原则：如果A执行ThreadB.join()并且成功返回，那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回。
- interrupt()原则：对线程interrupt()方法的调用先行发生于被中断线程代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测是否有中断发生
- finalize()原则：一个对象的初始化完成先行发生于它的finalize()方法的开始
第 1条规则程序顺序规则是说在一个线程里，所有的操作都是按顺序的，但是在 JMM里其实只要执行结果一样，是允许重排序的，这边的 happens-before强调的重点也是单线程执行结果的正确性，但是无法保证多线程也是如此。
第 2条规则监视器规则其实也好理解，就是在加锁之前，确定这个锁之前已经被释放了，才能继续加锁。
第 3条规则，就适用到所讨论的 volatile，如果一个线程先去写一个变量，另外一个线程再去读，那么写入操作一定在读操作之前。
第 4条规则，就是happens-before的传递性。happen-before指的是可以确保一个线程一定运行在另一个线程之前。
后面几条拼接字面意思就能理解十有八九，但是要注意的一点是：任意操作都是指的是方法调用前的操作，比如5点中指的是线程A中的“启动线程B操作”之前的操作happen-before线程B，6点中也指的是join方法之前的操作。如果之后的操作可能就会呈现出多线程运行的特点，操作执行没有规定的先后顺序。
4.面试官：volatile关键字如何满足并发编程的三大特性的？
那就要重提 volatile变量规则：对一个 volatile域的写， happens-before于后续对这个 volatile域的读。这条再拎出来说，其实就是如果一个变量声明成是 volatile的，那么当我读变量时，总是能读到它的最新值，这里最新值是指不管其它哪个线程对该变量做了写操作，都会立刻被更新到主存里，我也能从主存里读到这个刚写入的值。也就是说 volatile关键字可以保证可见性以及有序性。 继续拿上面的一段代码举例：
int a =0;
bolean flag =false;
public void write(){
a=2; //1
flag =true; //2
}
public void multiple(){
if(flag){ //3
int ret = a * a; //4
}
}这段代码不仅仅受到重排序的困扰，即使1、2没有重排序。3也不会那么顺利的执行的。假设还是线程1先执行write操作，线程2再执行multiply操作，由于线程1是在工作内存里把flag赋值为true，不一定立刻写回主存，所以线程2执行时，multiply再从主存读flag值，仍然可能为false，那么括号里的语句将不会执行。 如果改成下面这样：
int a =0;
volatile bolean flag =false;
public void write(){
a=2; //1
flag =true; //2
}
public void multiple(){
if(flag){ //3
int ret = a * a; //4
}
} 那么线程1先执行 write,线程 2再执行 multiply。根据 happens-before原则，这个过程会满足以下3类规则：
程序顺序规则： 1happens-before 2( volatile限制了指令重排序，所以1 在2 之前执行,这是之前提到的volatile修饰的作用2); 3happens-before 4;
volatile规则： 2happens-before 3
传递性规则： 1happens-before 4(volatile限制了变量的写操作必须立即写入主存中，这是之前提到的volatile修饰的作用1)
从内存语义上来看
当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存
当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效，线程接下来将从主内存中读取共享变量。
5.面试官：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++)//每个线程执行1000次自加，那么会输出10*1000=1W吗？
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操作）、以及加法操作（加一个数），减法操作（减一个数）进行了封装，保证这些操作是原子性操作。
6.面试官：说的还可以，那你知道volatile底层的实现机制吗？
如果把加入 volatile关键字的代码和未加入 volatile关键字的代码都生成汇编代码，会发现加入 volatile关键字的代码会多出一个 lock前缀指令。 lock前缀指令实际相当于一个内存屏障，内存屏障提供了以下功能：
1 . 重排序时不能把后面的指令重排序到内存屏障之前的位置 2 . 使得本CPU的Cache写入内存 3 . 写入动作也会引起别的CPU或者别的内核无效化其Cache，相当于让新写入的值对别的线程可见。
7.面试官：你在哪里会使用到volatile，举两个例子呢？
- 状态量标记，就如上面对 flag的标记，我重新提一下(设计状态变量的一般只有读，写两个原子操作)：
int a =0;
volatile bolean flag =false;
public void write(){
a=2; //1
flag =true; //2
}
public void multiple(){
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。\
8. 面试官：来给我们说说几种单例模式的写法吧，还有上面这种用法，你再详细说说呢？
好吧，这又是一个话题了， volatile的问题终于问完了。。。看看你掌握了没
总结：
volatile修饰符要点总结：
- 内存可以分为主存和缓存；
- volatile关键字的作用是： 1)写操作会立即通知其余线程此值已经被更新，且不是写入工作内存，而是直接写入主存。 2)读取变量的值之前先行判断是否已经有过写操作，如果存在写操作，那么直接从主存中取数据，然后再次判断是否有写操作（这有点像递归了），如果发现不存在写操作，才从工作内存中读取变量的值。 3)禁止单线程中JMM实行的“如果没有影响，则可以调换内部语句执行顺序”的内部逻辑
以上就是volatile修饰符的作用。虽然其可以保证有一个线程对变量完成写操作，其余线程一定能够知道此操作发生，但还是保证不了线程安全性，究其原因我们不妨对比一下synchronized上锁的原理：
synchronized修饰符保证了一个对象只能由一个线程所持有，这保证了一个线程在进行写操作的时候，没有其他线程能够访问此对象及其域。但是volatile却不能保证这一点，因为从写操作开始直至真正地写入主存中的过程中，写操作没有执行完，所有线程都可以访问volatile类型变量，而多个线程在此过程中都是认为主存中的变量并未被改变，认为其是最新值，每个线程接着又都执行了写操作，这样一来，线程就是不安全的了。所以如果想达到要使用volatile变量、线程安全的同时又不额外使用上锁机制，我们最好的办法就是一下两个办法：这也是为何volatile修饰符修饰一个布尔值变量的原因，因为其是原子操作，且不依赖现在是true还是false;
- 运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值。
- 变量不需要与其他状态变量共同参与不变约束。
转载说明：
来自于公众号：CodeSheep