volatile关键字(转)

volatile关键字

被volatile修饰的共享变量，就具备了如下两点特性：

1 . 保证了不一样线程对相同变量操做的内存可见性;

2 . 禁止指令重排序

内存可见性与重排序

Java虚拟机规范试图定义一种Java内存模型（JMM）,来屏蔽掉各类硬件和操做系统的内存访问差别，让Java程序在各类平台上都能达到一致的内存访问效果。因为CPU执行指令的速度是很快的，可是内存访问的速度就慢了不少，相差的不是一个数量级，因此在CPU里加了好几层高速缓存。在Java内存模型里，对上述的优化又进行了抽象。JMM规定全部变量都是存在主存中的，可是每一个线程又包含本身的工做内存，能够当作CPU上的寄存器或者高速缓存。因此线程的操做都是以工做内存为主，它们只能访问本身的工做内存，而后再同步回主存。

使用工做内存和主存，虽然加快的速度，可是也带来了一些问题。好比看下面一个例子：

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)：

当一个变量被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原则。

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关键字能够保证可见性以及有序性。

当写一个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<10;j++)

                        test.increase();

                };

            }.start();

        }

 

        while(Thread.activeCount()>1)  //保证前面的线程都执行完

            Thread.yield();

        System.out.println(test.inc);

    }

按道理来讲结果是100，可是运行下极可能是个小于100的值。有人可能会说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前缀指令实际至关于一个内存屏障，内存屏障提供了如下功能：

1 . 重排序时不能把后面的指令重排序到内存屏障以前的位置
2 . 使得本CPU的Cache写入内存
3 . 写入动做也会引发别的CPU或者别的内核无效化其Cache，至关于让新写入的值对别的线程可见。

使用到volatile的例子：

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