在Java相关的岗位面试中,不少面试官都喜欢考察面试者对Java并发的了解程度,而以volatile关键字做为一个小的切入点,每每能够一问到底,把Java内存模型(JMM),Java并发编程的一些特性都牵扯出来,深刻地话还能够考察JVM底层实现以及操做系统的相关知识。java
下面咱们以一次假想的面试过程,来深刻了解下volitile关键字吧!c++
就我理解的而言,被volatile修饰的共享变量,就具备了如下两点特性:面试
1 . 保证了不一样线程对该变量操做的内存可见性;编程
2 . 禁止指令重排序缓存
这个聊起来可就多了,我仍是从Java内存模型提及吧。多线程
Java虚拟机规范试图定义一种Java内存模型(JMM),来屏蔽掉各类硬件和操做系统的内存访问差别,让Java程序在各类平台上都能达到一致的内存访问效果。简单来讲,因为CPU执行指令的速度是很快的,可是内存访问的速度就慢了不少,相差的不是一个数量级,因此搞处理器的那群大佬们又在CPU里加了好几层高速缓存。并发
在Java内存模型里,对上述的优化又进行了一波抽象。JMM规定全部变量都是存在主存中的,相似于上面提到的普通内存,每一个线程又包含本身的工做内存,方便理解就能够当作CPU上的寄存器或者高速缓存。因此线程的操做都是以工做内存为主,它们只能访问本身的工做内存,且工做先后都要把值在同步回主内存。app
这么说得我本身都有些不清楚了,拿张纸画一下:优化
在线程执行时,首先会从主存中read变量值,再load到工做内存中的副本中,而后再传给处理器执行,执行完毕后再给工做内存中的副本赋值,随后工做内存再把值传回给主存,主存中的值才更新。atom
使用工做内存和主存,虽然加快的速度,可是也带来了一些问题。好比看下面一个例子:
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跟可见性和有序性都有关。
1 . 原子性(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
的值刷回到主存的。
2 . 可见性(Visibility):
说到可见性,Java就是利用volatile来提供可见性的。
当一个变量被volatile修饰时,那么对它的修改会马上刷新到主存,当其它线程须要读取该变量时,会去内存中读取新值。而普通变量则不能保证这一点。
其实经过synchronized和Lock也可以保证可见性,线程在释放锁以前,会把共享变量值都刷回主存,可是synchronized和Lock的开销都更大。
3 . 有序性(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原则。<<JSR-133:Java Memory Model and Thread Specification>>
定义了以下happens-before规则:
ThreadB_start()
(启动线程B) , 那么A线程的ThreadB_start()
happens-before 于B中的任意操做ThreadB.join()
而且成功返回,那么线程B中的任意操做happens-before于线程A从ThreadB.join()
操做成功返回。interrupt()
方法的调用先行发生于被中断线程代码检测到中断事件的发生,能够经过Thread.interrupted()
方法检测是否有中断发生finalize()
方法的开始第1条规则程序顺序规则是说在一个线程里,全部的操做都是按顺序的,可是在JMM里其实只要执行结果同样,是容许重排序的,这边的happens-before强调的重点也是单线程执行结果的正确性,可是没法保证多线程也是如此。
第2条规则监视器规则其实也好理解,就是在加锁以前,肯定这个锁以前已经被释放了,才能继续加锁。
第3条规则,就适用到所讨论的volatile,若是一个线程先去写一个变量,另一个线程再去读,那么写入操做必定在读操做以前。
第4条规则,就是happens-before的传递性。
后面几条就再也不一一赘述了。
那就要重提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 } }
这段代码不只仅受到重排序的困扰,即便一、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类规则:
从内存语义上来看
当写一个volatile变量时,JMM会把该线程对应的本地内存中的共享变量刷新到主内存
当读一个volatile变量时,JMM会把该线程对应的本地内存置为无效,线程接下来将从主内存中读取共享变量。
首先我回答是不能保证原子性,要是说能保证,也只是对单个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关键字的代码会多出一个lock前缀指令。
lock前缀指令实际至关于一个内存屏障,内存屏障提供了如下功能:
1 . 重排序时不能把后面的指令重排序到内存屏障以前的位置
2 . 使得本CPU的Cache写入内存
3 . 写入动做也会引发别的CPU或者别的内核无效化其Cache,至关于让新写入的值对别的线程可见。
1. 状态量标记,就如上面对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有必定的效率提高。
2.单例模式的实现,典型的双重检查锁定(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。
好吧,这又是一个话题了,volatile的问题终于问完了。。。看看你掌握了没~