Java的多线程机制系列：(四)不得不提的volatile及指令重排序(happen-before)

转自：http://www.cnblogs.com/mengheng/p/3495379.html

一、不得不提的volatile

volatile是个很老的关键字，几乎伴随着JDK的诞生而诞生，我们都知道这个关键字，但又不太清楚什么时候会使用它；我们在JDK及开源框架中随处可见这个关键字，但并发专家又往往建议我们远离它。比如Thread这个很基础的类，其中很重要的线程状态字段，就是用volatile来修饰，见代码

 /* Java thread status for tools,

     * initialized to indicate thread 'not yet started'

     */

    private volatile int threadStatus = 0;

如上面所说，并发专家建议我们远离它，尤其是在JDK6的synchronized关键字的性能被大幅优化之后，更是几乎没有使用它的场景，但这仍然是个值得研究的关键字，研究它的意义不在于去使用它，而在于理解它对理解Java的整个多线程的机制是很有帮助的。

1. 例子

先来体会一下volatile的作用，从下面代码开始

   1:  public class VolatileExample extends Thread{

   2:      //设置类静态变量,各线程访问这同一共享变量

   3:      private static boolean flag = false;

   4:      

   5:      //无限循环,等待flag变为true时才跳出循环

   6:      public void run() {while (!flag){};}

   7:      

   8:      public static void main(String[] args) throws Exception {

   9:          new VolatileExample().start();

  10:          //sleep的目的是等待线程启动完毕,也就是说进入run的无限循环体了

  11:          Thread.sleep(100);

  12:          flag = true;

  13:      }

  14:  }

这个例子很好理解，main函数里启动一个线程，其run方法是一个以flag为标志位的无限循环。如果flag为true则跳出循环。当main执行到12行的时候，flag被置为true，按逻辑分析此时线程该结束，即整个程序执行完毕。

执行一下看看是什么结果？结果是令人惊讶的，程序始终也不会结束。main是肯定结束了的，其原因就是线程的run方法未结束，即run方法中的flag仍然为false。

把第3行加上volatile修饰符，即

private static volatile boolean flag = false;

再执行一遍看看？结果是程序正常退出，volatile生效了。

我们再修改一下。去掉volatile关键字，恢复到起始的例子，然后把while(!flag){}改为while(!flag){System.out.println(1);}，再执行一下看看。按分析，没有volatile关键字的时候，程序不会执行结束，虽然加上了打印语句，但没有做任何的关键字/逻辑的修改，应该程序也不会结束才对，但执行结果却是：程序正常结束。

有了这些感性认识，我们再来分析volatile的语义以及它的作用。

2.volatile语义

volatile的第一条语义是保证线程间变量的可见性，简单地说就是当线程A对变量X进行了修改后，在线程A后面执行的其他线程能看到变量X的变动，更详细地说是要符合以下两个规则：

• 线程对变量进行修改之后，要立刻回写到主内存。
• 线程对变量读取的时候，要从主内存中读，而不是缓存。

要详细地解释这个问题，就不得不提一下Java的内存模型(Java Memory Model,简称JMM)。Java的内存模型是一个比较复杂的话题，属于Java语言规范的范畴，个人水平有限，不能在有限篇幅里完整地讲述清楚这个事，如果要清晰地认识，请学习《深入理解Java虚拟机-JVM高级特性与最佳实践》和《The Java Language Specification, Java SE 7 Edition》，这里简单地引用一些资料略加解释。

Java为了保证其平台性，使Java应用程序与操作系统内存模型隔离开，需要定义自己的内存模型。在Java内存模型中，内存分为主内存和工作内存两个部分，其中主内存是所有线程所共享的，而工作内存则是每个线程分配一份，各线程的工作内存间彼此独立、互不可见，在线程启动的时候，虚拟机为每个内存分配一块工作内存，不仅包含了线程内部定义的局部变量，也包含了线程所需要使用的共享变量(非线程内构造的对象)的副本，即为了提高执行效率，读取副本比直接读取主内存更快(这里可以简单地将主内存理解为虚拟机中的堆，而工作内存理解为栈(或称为虚拟机栈)，栈是连续的小空间、顺序入栈出栈，而堆是不连续的大空间，所以在栈中寻址的速度比堆要快很多)。工作内存与主内存之间的数据交换通过主内存来进行，如下图：

同时，Java内存模型还定义了一系列工作内存和主内存之间交互的操作及操作之间的顺序的规则(这规则比较多也比较复杂，参见《深入理解Java虚拟机-JVM高级特性与最佳实践》第12章12.3.2部分)，这里只谈和volatile有关的部分。对于共享普通变量来说，约定了变量在工作内存中发生变化了之后，必须要回写到工作内存(迟早要回写但并非马上回写)，但对于volatile变量则要求工作内存中发生变化之后，必须马上回写到工作内存，而线程读取volatile变量的时候，必须马上到工作内存中去取最新值而不是读取本地工作内存的副本，此规则保证了前面所说的“当线程A对变量X进行了修改后，在线程A后面执行的其他线程能看到变量X的变动”。

大部分网上的文章对于volatile的解释都是到此为止，但我觉得还是有遗漏的，提出来探讨。工作内存可以说是主内存的一份缓存，为了避免缓存的不一致性，所以volatile需要废弃此缓存。但除了内存缓存之外，在CPU硬件级别也是有缓存的，即寄存器。假如线程A将变量X由0修改为1的时候，CPU是在其缓存内操作，没有及时回写到内存，那么JVM是无法X=1是能及时被之后执行的线程B看到的，所以我觉得JVM在处理volatile变量的时候，也同样用了硬件级别的缓存一致性原则(CPU的缓存一致性原则参见《Java的多线程机制系列：(二）缓存一致性和CAS》。

volatile的第二条语义：禁止指令重排序。关于指令重排序请参见后面的“指令重排序”章节。这是volatile目前主要的一个使用场景。

3. volatile不能保证原子性

介绍volatile不能保证原子性的文章比较多，这里就不举详细例子了，大家可以去网上查阅相关资料。在多线程并发执行i++的操作结果来说，i加与不加volatile都是一样的，只要线程数足够，一定会出现不一致。这里就其为什么不能保证原子性的原理说一下。

上面提到volatile的两条语义保证了线程间共享变量的及时可见性，但整个过程并没有保证同步(参见《Java的多线程机制系列：(一)总述及基础概念》中对“锁”的两种特性的描述)，这是与volatile的使命有关的，创造它的背景就是在某些情况下可以代替synchronized实现可见性的目的，规避synchronized带来的线程挂起、调度的开销。如果volatile也能保证同步，那么它就是个锁，可以完全取代synchronized了。从这点看，volatile不可能保证同步，也正基于上面的原因，随着synchronized性能逐渐提高，volatile逐渐退出历史舞台。

为什么volatile不能保证原子性？以i++为例，其包括读取、操作、赋值三个操作，下面是两个线程的操作顺序

假如说线程A在做了i+1，但未赋值的时候，线程B就开始读取i，那么当线程A赋值i=1，并回写到主内存，而此时线程B已经不再需要i的值了，而是直接交给处理器去做+1的操作，于是当线程B执行完并回写到主内存，i的值仍然是1，而不是预期的2。也就是说，volatile缩短了普通变量在不同线程之间执行的时间差，但仍然存有漏洞，依然不能保证原子性。

这里必须要提的是，在本章开头所说的“各线程的工作内存间彼此独立、互不可见，在线程启动的时候，虚拟机为每个内存分配一块工作内存，不仅包含了线程内部定义的局部变量，也包含了线程所需要使用的共享变量(非线程内构造的对象)的副本，即为了提高执行效率”并不准确。如今的volatile的例子已经是很难重现，如本文开头时只有在while死循环时才体现出volatile的作用，哪怕只是加了System.out.println(1)这么一小段，普通变量也能达到volatile的效果，这是什么原因呢？原来只有在对变量读取频率很高的情况下，虚拟机才不会及时回写主内存，而当频率没有达到虚拟机认为的高频率时，普通变量和volatile是同样的处理逻辑。如在每个循环中执行System.out.println(1)加大了读取变量的时间间隔，使虚拟机认为读取频率并不那么高，所以实现了和volatile的效果(本文开头的例子只在HotSpot24上测试过，没有在JRockit之类其余版本JDK上测过)。volatile的效果在jdk1.2及之前很容易重现，但随着虚拟机的不断优化，如今的普通变量的可见性已经不是那么严重的问题了，这也是volatile如今确实不太有使用场景的原因吧。

4. volatile的适用场景

并发专家建议我们远离volatile是有道理的，这里再总结一下：

• volatile是在synchronized性能低下的时候提出的。如今synchronized的效率已经大幅提升，所以volatile存在的意义不大。
• 如今非volatile的共享变量，在访问不是超级频繁的情况下，已经和volatile修饰的变量有同样的效果了。
• volatile不能保证原子性，这点是大家没太搞清楚的，所以很容易出错。
• volatile可以禁止重排序。

所以如果我们确定能正确使用volatile，那么在禁止重排序时是一个较好的使用场景，否则我们不需要再使用它。这里只列举出一种volatile的使用场景，即作为标识位的时候(比如本文例子中boolean类型的flag)。用专业点更广泛的说法就是“对变量的写操作不依赖于当前值且该变量没有包含在其他具体变量的不变式中”，具体参见《Java 理论与实践: 正确使用 Volatile 变量》。

 

二、指令重排序(happen-before)

指令重排序是个比较复杂、觉得有些不可思议的问题，同样是先以例子开头(建议大家跑下例子，这是实实在在可以重现的，重排序的概率还是挺高的)，有个感性的认识

/**

 * 一个简单的展示Happen-Before的例子.

 * 这里有两个共享变量:a和flag,初始值分别为0和false.在ThreadA中先给a=1,然后flag=true.

 * 如果按照有序的话,那么在ThreadB中如果if(flag)成功的话,则应该a=1,而a=a*1之后a仍然为1,下方的if(a==0)应该永远不会为真,永远不会打印.

 * 但实际情况是:在试验100次的情况下会出现0次或几次的打印结果,而试验1000次结果更明显,有十几次打印.

 */

public class SimpleHappenBefore {

    /** 这是一个验证结果的变量 */

    private static int a=0;

    /** 这是一个标志位 */

    private static boolean flag=false;

    public static void main(String[] args) throws InterruptedException {

        //由于多线程情况下未必会试出重排序的结论,所以多试一些次

        for(int i=0;i<1000;i++){

            ThreadA threadA=new ThreadA();

            ThreadB threadB=new ThreadB();

            threadA.start();

            threadB.start();

            //这里等待线程结束后,重置共享变量,以使验证结果的工作变得简单些.

            threadA.join();

            threadB.join();

            a=0;

            flag=false;

        }

    }

    static class ThreadA extends Thread{

        public void run(){

            a=1;

            flag=true;

        }

    }

    static class ThreadB extends Thread{

        public void run(){

            if(flag){

                a=a*1;

            }

            if(a==0){

                System.out.println("ha,a==0");

            }

        }

    }

}

例子比较简单，也添加了注释，不再详细叙述。

什么是指令重排序？有两个层面：

• 在虚拟机层面，为了尽可能减少内存操作速度远慢于CPU运行速度所带来的CPU空置的影响，虚拟机会按照自己的一些规则(这规则后面再叙述)将程序编写顺序打乱——即写在后面的代码在时间顺序上可能会先执行，而写在前面的代码会后执行——以尽可能充分地利用CPU。拿上面的例子来说：假如不是a=1的操作，而是a=new byte[1024*1024](分配1M空间)，那么它会运行地很慢，此时CPU是等待其执行结束呢，还是先执行下面那句flag=true呢？显然，先执行flag=true可以提前使用CPU，加快整体效率，当然这样的前提是不会产生错误(什么样的错误后面再说)。虽然这里有两种情况：后面的代码先于前面的代码开始执行；前面的代码先开始执行，但当效率较慢的时候，后面的代码开始执行并先于前面的代码执行结束。不管谁先开始，总之后面的代码在一些情况下存在先结束的可能。
• 在硬件层面，CPU会将接收到的一批指令按照其规则重排序，同样是基于CPU速度比缓存速度快的原因，和上一点的目的类似，只是硬件处理的话，每次只能在接收到的有限指令范围内重排序，而虚拟机可以在更大层面、更多指令范围内重排序。硬件的重排序机制参见《从JVM并发看CPU内存指令重排序(Memory Reordering)》

重排序很不好理解，上面只是简单地提了下其场景，要想较好地理解这个概念，需要构造一些例子和图表，在这里介绍两篇介绍比较详细、生动的文章《happens-before俗解》和《深入理解Java内存模型（二）——重排序》。其中的“as-if-serial”是应该掌握的，即：不管怎么重排序，单线程程序的执行结果不能被改变。编译器、运行时和处理器都必须遵守“as-if-serial”语义。拿个简单例子来说，

public void execute(){

    int a=0;

    int b=1;

    int c=a+b;

}

这里a=0,b=1两句可以随便排序，不影响程序逻辑结果，但c=a+b这句必须在前两句的后面执行。

 

从前面那个例子可以看到，重排序在多线程环境下出现的概率还是挺高的，在关键字上有volatile和synchronized可以禁用重排序，除此之外还有一些规则，也正是这些规则，使得我们在平时的编程工作中没有感受到重排序的坏处。

• 程序次序规则(Program Order Rule)：在一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作。准确地说应该是控制流顺序而不是代码顺序，因为要考虑分支、循环等结构。
• 监视器锁定规则(Monitor Lock Rule)：一个unlock操作先行发生于后面对同一个对象锁的lock操作。这里强调的是同一个锁，而“后面”指的是时间上的先后顺序，如发生在其他线程中的lock操作。
• volatile变量规则(Volatile Variable Rule):对一个volatile变量的写操作发生于后面对这个变量的读操作，这里的“后面”也指的是时间上的先后顺序。
• 线程启动规则(Thread Start Rule)：Thread独享的start()方法先行于此线程的每一个动作。
• 线程终止规则(Thread Termination Rule)：线程中的每个操作都先行发生于对此线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值检测到线程已经终止执行。
• 线程中断规则(Thread Interruption Rule)：对线程interrupte()方法的调用优先于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测线程是否已中断。
• 对象终结原则(Finalizer Rule)：一个对象的初始化完成(构造函数执行结束)先行发生于它的finalize()方法的开始。
• 传递性(Transitivity)：如果操作A先行发生于操作B，操作B先行发生于操作C，那就可以得出操作A先行发生于操作C的结论。

正是以上这些规则保障了happen-before的顺序，如果不符合以上规则，那么在多线程环境下就不能保证执行顺序等同于代码顺序，也就是“如果在本线程中观察，所有的操作都是有序的；如果在一个线程中观察另外一个线程，则不符合以上规则的都是无序的”，因此，如果我们的多线程程序依赖于代码书写顺序，那么就要考虑是否符合以上规则，如果不符合就要通过一些机制使其符合，最常用的就是synchronized、Lock以及volatile修饰符。