Java高并发编程三--volatile使用及其实现原理

经过前面一章咱们了解了synchronized是一个重量级的锁，虽然JVM对它作了不少优化，而下面介绍的volatile则是轻量级的synchronized。若是一个变量使用volatile，则它比使用synchronized的成本更加低，由于它不会引发线程上下文的切换和调度。Java语言规范对volatile的定义以下：

Java编程语言容许线程访问共享变量，为了确保共享变量能被准确和一致地更新，线程应该确保经过排他锁单独得到这个变量。

上面比较绕口，通俗点讲就是说一个变量若是用volatile修饰了，则Java能够确保全部线程看到这个变量的值是一致的，若是某个线程对volatile修饰的共享变量进行更新，那么其余线程能够立马看到这个更新，这就是所谓的线程可见性。volatile虽然看起来比较简单，使用起来无非就是在一个变量前面加上volatile便可，可是要用好并不容易,下面会详细讲到.

一.操做系统语义

计算机在运行程序时，每条指令都是在CPU中执行的，在执行过程当中势必会涉及到数据的读写。咱们知道程序运行的数据是存储在主存中，这时就会有一个问题，读写主存中的数据没有CPU中执行指令的速度快，若是任何的交互都须要与主存打交道则会大大影响效率，因此就有了CPU高速缓存。CPU高速缓存为某个CPU独有，只与在该CPU运行的线程有关。

有了CPU高速缓存虽然解决了效率问题，可是它会带来一个新的问题：数据一致性。在程序运行中，会将运行所须要的数据复制一份到CPU高速缓存中，在进行运算时CPU再也不也主存打交道，而是直接从高速缓存中读写数据，只有当运行结束后才会将数据刷新到主存中。举一个简单的例子：

1

i++i++

当线程运行这段代码时，首先会从主存中读取i( i = 1)，而后复制一份到CPU高速缓存中，而后CPU执行 + 1 （2）的操做，而后将数据（2）写入到告诉缓存中，最后刷新到主存中。其实这样作在单线程中是没有问题的，有问题的是在多线程中。以下：

假若有两个线程A、B都执行这个操做（i++），按照咱们正常的逻辑思惟主存中的i值应该=3，但事实是这样么？分析以下：

两个线程从主存中读取i的值（1）到各自的高速缓存中，而后线程A执行+1操做并将结果写入高速缓存中，最后写入主存中，此时主存i==2,线程B作一样的操做，主存中的i仍然=2。因此最终结果为2并非3。这种现象就是缓存一致性问题。

解决缓存一致性方案有两种：

1. 经过在总线加LOCK#锁的方式
2. 经过缓存一致性协议

可是方案1存在一个问题，它是采用一种独占的方式来实现的，即总线加LOCK#锁的话，只能有一个CPU可以运行，其余CPU都得阻塞，效率较为低下。

第二种方案，缓存一致性协议（MESI协议）它确保每一个缓存中使用的共享变量的副本是一致的。其核心思想以下：当某个CPU在写数据时，若是发现操做的变量是共享变量，则会通知其余CPU告知该变量的缓存行是无效的，所以其余CPU在读取该变量时，发现其无效会从新从主存中加载数据。

二.Java内存模型

上面从操做系统层次阐述了如何保证数据一致性，下面咱们来看一下Java内存模型，稍微研究一下Java内存模型为咱们提供了哪些保证以及在Java中提供了哪些方法和机制来让咱们在进行多线程编程时可以保证程序执行的正确性。

在并发编程中咱们通常都会遇到这三个基本概念：原子性、可见性、有序性。咱们稍微看下volatile

1.原子性：即一个操做或者多个操做 要么所有执行而且执行的过程不会被任何因素打断，要么就都不执行。

原子性就像数据库里面的事务同样，他们是一个团队，同生共死。其实理解原子性很是简单，咱们看下面一个简单的例子便可：

i = 0;        //    ---1
j = i ;       //     ---2
i++;          //  ---3
i = j + 1;   // ---4
/*
上面四个操做，有哪一个几个是原子操做，那几个不是？
若是不是很理解，可能会认为都是原子性操做，其实只有1才是原子操做，其他均不是。

1—在Java中，对基本数据类型的变量和赋值操做都是原子性操做；
2—包含了两个操做：读取i，将i值赋值给j
3—包含了三个操做：读取i值、i + 1 、将+1结果赋值给i；
4—同三同样
*/

在单线程环境下咱们能够认为整个步骤都是原子性操做，可是在多线程环境下则不一样，Java只保证了基本数据类型的变量和赋值操做才是原子性的（注：在32位的JDK环境下，对64位数据的读取不是原子性操做*，如long、double）。要想在多线程环境下保证原子性，则能够经过锁、synchronized来确保。

volatile是没法保证复合操做的原子性

2.可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其余线程可以当即看获得修改的值。

在上面已经分析了，在多线程环境下，一个线程对共享变量的操做对其余线程是不可见的。

Java提供了volatile来保证可见性。

当一个变量被volatile修饰后，表示着线程本地内存无效，当一个线程修改共享变量后他会当即被更新到主内存中，当其余线程读取共享变量时，它会直接从主内存中读取。
固然，synchronize和锁均可以保证可见性。

3.有序性：即程序执行的顺序按照代码的前后顺序执行。

在Java内存模型中，为了效率是容许编译器和处理器对指令进行重排序，固然重排序它不会影响单线程的运行结果，可是对多线程会有影响。

Java提供volatile来保证必定的有序性。最著名的例子就是单例模式里面的DCL（双重检查锁）。这里LZ就再也不阐述了。

三.volatile的使用

要使 volatile 变量提供理想的线程安全，必须同时知足下面两个条件：

• 对变量的写操做不依赖于当前值。
• 该变量没有包含在具备其余变量的不变式中。

实际上，这些条件代表，能够被写入 volatile 变量的这些有效值独立于任何程序的状态，包括变量的当前状态。

第一个条件的限制使 volatile 变量不能用做线程安全计数器。虽然增量操做（x++）看上去相似一个单独操做，实际上它是一个由读取－修改－写入操做序列组成的组合操做，必须以原子方式执行，而 volatile 不能提供必须的原子特性。实现正确的操做须要使 x 的值在操做期间保持不变，而 volatile 变量没法实现这点。（然而，若是将值调整为只从单个线程写入，那么能够忽略第一个条件。）

大多数编程情形都会与这两个条件的其中之一冲突，使得 volatile 变量不能像 synchronized 那样广泛适用于实现线程安全。清单 1 显示了一个非线程安全的数值范围类。它包含了一个不变式 —— 下界老是小于或等于上界。

一、防止重排序

package com.zzl.concurrent;

public class Singleton {
    public static volatile Singleton singleton;

    /**
     * 构造函数私有，禁止外部实例化
     */
    private Singleton() {};

    public static Singleton getInstance() {
        if (singleton == null) {
            synchronized (singleton) {
                if (singleton == null) {
                    singleton = new Singleton();
                }
            }
        }
        return singleton;
    }
}
/*
如今咱们分析一下为何要在变量singleton之间加上volatile关键字。
要理解这个问题，先要了解对象的构造过程，实例化一个对象其实能够分为三个步骤：
　　（1）分配内存空间。
　　（2）初始化对象。
　　（3）将内存空间的地址赋值给对应的引用。
可是因为操做系统能够对指令进行重排序，因此上面的过程也可能会变成以下过程：
　　（1）分配内存空间。
　　（2）将内存空间的地址赋值给对应的引用。
　　（3）初始化对象
若是是这个流程，多线程环境下就可能将一个未初始化的对象引用暴露出来，
从而致使不可预料的结果。所以，为了防止这个过程的重排序，咱们须要将变量设置为volatile类型的变量。*/

二、实现可见性

package com.zzl.test.concurrent;

public class VolatileTest {
    int a = 1;
    int b = 2;

    public void change(){
        a = 3;
        b = a;
    }

    public void print(){
        System.out.println("b="+b+";a="+a);
    }

    public static void main(String[] args) {
        while (true){
            final VolatileTest test = new VolatileTest();
            new Thread(new Runnable() {
                @Override
                public void run() {
                    try {
                        Thread.sleep(10);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    test.change();
                }
            }).start();

            new Thread(new Runnable() {
                @Override
                public void run() {
                    try {
                        Thread.sleep(10);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    test.print();
                }
            }).start();

        }
    }
}
/*　直观上说，这段代码的结果只可能有两种：b=3;a=3 或 b=2;a=1。
不过运行上面的代码（可能时间上要长一点），你会发现除了上两种结果以外，还出现了第三种结果：

...... 
b=2;a=1
b=2;a=1
b=3;a=3
b=3;a=3
b=3;a=1<<-----
b=3;a=3
b=2;a=1
b=3;a=3
b=3;a=3
......
*/

为何会出现b=3;a=1这种结果呢？正常状况下，若是先执行change方法，再执行print方法，输出结果应该为b=3;a=3。相反，若是先执行的print方法，再执行change方法，结果应该是 b=2;a=1。那b=3;a=1的结果是怎么出来的？缘由就是第一个线程将值a=3修改后，可是对第二个线程是不可见的，因此才出现这一结果。若是将a和b都改为volatile类型的变量再执行，则不再会出现b=3;a=1的结果了。

三、保证原子性

关于volatile变量对原子性保证，有一个问题容易被误解。如今咱们就经过下列程序来演示一下这个问题：

package com.zzl.test.concurrent;

public class VolatileTest01 {
    volatile int i;

    public void addI(){
        i++;
    }

    public static void main(String[] args) throws InterruptedException {
        final  VolatileTest01 test01 = new VolatileTest01();
        for (int n = 0; n < 1000; n++) {
            new Thread(new Runnable() {
                @Override
                public void run() {
                    try {
                        Thread.sleep(10);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    test01.addI();
                }
            }).start();
        }

        Thread.sleep(10000);//等待10秒，保证上面程序执行完成

        System.out.println(test01.i);
    }
}
//你们可能会误认为对变量i加上关键字volatile后，这段程序就是线程安全的。
你们能够尝试运行上面的程序。下面是我本地运行的结果：
978

 可能每一个人运行的结果不相同。不过应该能看出，volatile是没法保证原子性的（不然结果应该是1000）。缘由也很简单，i++实际上是一个复合操做，包括三步骤：

　　（1）读取i的值。

　　（2）对i加1。

　　（3）将i的值写回内存。

volatile是没法保证这三个操做是具备原子性的，咱们能够经过AtomicInteger或者Synchronized来保证+1操做的原子性。

注：上面几段代码中多处执行了Thread.sleep()方法，目的是为了增长并发问题的产生概率，无其余做用。

四.volatile原理

　　一、可见性实现：

　　在前文中已经说起过，线程自己并不直接与主内存进行数据的交互，而是经过线程的工做内存来完成相应的操做。这也是致使线程间数据不可见的本质缘由。所以要实现volatile变量的可见性，直接从这方面入手便可。对volatile变量的写操做与普通变量的主要区别有两点：

　　（1）修改volatile变量时会强制将修改后的值刷新的主内存中。

　　（2）修改volatile变量后会致使其余线程工做内存中对应的变量值失效。所以，再读取该变量值的时候就须要从新从读取主内存中的值。

　　经过这两个操做，就能够解决volatile变量的可见性问题。

       2. 禁止指令重排序:

在执行程序时为了提升性能，编译器和处理器一般会对指令作重排序：

1. 编译器重排序。编译器在不改变单线程程序语义的前提下，能够从新安排语句的执行顺序；
2. 处理器重排序。若是不存在数据依赖性，处理器能够改变语句对应机器指令的执行顺序；

指令重排序对单线程没有什么影响，他不会影响程序的运行结果，可是会影响多线程的正确性。既然指令重排序会影响到多线程执行的正确性，那么咱们就须要禁止重排序。那么JVM是如何禁止重排序的呢？这个问题稍后回答，咱们先看另外一个原则happens-before，happen-before原则保证了程序的“有序性”，它规定若是两个操做的执行顺序没法从happens-before原则中推到出来，那么他们就不能保证有序性，能够随意进行重排序。其定义以下：

1. 同一个线程中的，前面的操做 happen-before 后续的操做。（即单线程内按代码顺序执行。可是，在不影响在单线程环境执行结果的前提下，编译器和处理器能够进行重排序，这是合法的。换句话说，这一是规则没法保证编译重排和指令重排）。
2. 监视器上的解锁操做 happen-before 其后续的加锁操做。（Synchronized 规则）
3. 对volatile变量的写操做 happen-before 后续的读操做。（volatile 规则）
4. 线程的start() 方法 happen-before 该线程全部的后续操做。（线程启动规则）
5. 线程全部的操做 happen-before 其余线程在该线程上调用 join 返回成功后的操做。
6. 若是 a happen-before b，b happen-before c，则a happen-before c（传递性）。

咱们着重看第三点volatile规则：对volatile变量的写操做 happen-before 后续的读操做。为了实现volatile内存语义，JMM会重排序，其规则以下：

这里咱们主要看下第三条：volatile变量的保证有序性的规则。《Java并发编程：核心理论》一文中提到太重排序分为编译器重排序和处理器重排序。为了实现volatile内存语义，JMM会对volatile变量限制这两种类型的重排序。下面是JMM针对volatile变量所规定的重排序规则表：

　　三、内存屏障

为了实现volatile可见性和happen-befor的语义。JVM底层是经过一个叫作“内存屏障”的东西来完成。内存屏障，也叫作内存栅栏，是一组处理器指令，用于实现对内存操做的顺序限制。下面是完成上述规则所要求的内存屏障：

Required barriers	2nd operation
1st operation	Normal Load	Normal Store	Volatile Load	Volatile Store
Normal Load				LoadStore
Normal Store				StoreStore
Volatile Load	LoadLoad	LoadStore	LoadLoad	LoadStore
Volatile Store			StoreLoad	StoreStore

（1）LoadLoad 屏障
执行顺序：Load1—>Loadload—>Load2
确保Load2及后续Load指令加载数据以前能访问到Load1加载的数据。

（2）StoreStore 屏障
执行顺序：Store1—>StoreStore—>Store2
确保Store2以及后续Store指令执行前，Store1操做的数据对其它处理器可见。

（3）LoadStore 屏障
执行顺序： Load1—>LoadStore—>Store2
确保Store2和后续Store指令执行前，能够访问到Load1加载的数据。

（4）StoreLoad 屏障
执行顺序: Store1—> StoreLoad—>Load2
确保Load2和后续的Load指令读取以前，Store1的数据对其余处理器是可见的。

最后我能够经过一个实例来讲明一下JVM中是如何插入内存屏障的：

package com.paddx.test.concurrent;

public class MemoryBarrier {
    int a, b;
    volatile int v, u;

    void f() {
        int i, j;

        i = a;
        j = b;
        i = v;
        //LoadLoad
        j = u;
        //LoadStore
        a = i;
        b = j;
        //StoreStore
        v = i;
        //StoreStore
        u = j;
        //StoreLoad
        i = u;
        //LoadLoad
        //LoadStore
        j = b;
        a = i;
    }
}

五:总结

整体上来讲volatile的理解仍是比较困难的，若是不是特别理解，也不用急，彻底理解须要一个过程，在后续的文章中也还会屡次看到volatile的使用场景。这里暂且对volatile的基础知识和原来有一个基本的了解。整体来讲，volatile是并发编程中的一种优化，在某些场景下能够代替Synchronized。可是，volatile的不能彻底取代Synchronized的位置，只有在一些特殊的场景下，才能适用volatile。总的来讲，必须同时知足下面两个条件才能保证在并发环境的线程安全：

　　（1）对变量的写操做不依赖于当前值。

　　（2）该变量没有包含在具备其余变量的不变式中。