JAVA volatile关键字的作用

先看代码

package com.test.day02;

public class T04_volatile {

    /*volatile*/ boolean flag = true;

    synchronized void m() {
        System.out.println("m start");
        while (flag) {

        }
        System.out.println("m end");
    }

    public static void main(String[] args) {
        T04_volatile t04_volatile = new T04_volatile();

        new Thread(t04_volatile::m,"t1").start();

        try {
            Thread.sleep(1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        t04_volatile.flag = false;
    }
}

           

加volatile关键字输出结果：

m start
m end
           

不加volatile关键字输出结果：线程未结束

m start
           

原因分析：

volatile作用：1、变量可见性 2、禁止指令重排序

变量可见性：

用volatile修饰的变量，线程在每次使用变量的时候，都会读取变量修改后的最新的值。

如果要深入了解volatile关键字的作用，就必须先来了解一下JVM在运行时候的内存分配过程。

线程栈保存了线程运行时候变量值信息。当线程访问某一个对象时候值的时候，首先通过对象的引用找到对应在堆内存的变量的值，然后把堆内存变量的具体值load到线程本地内存中，建立一个变量副本，之后线程就不再和对象在堆内存变量值有任何关系，而是直接修改副本变量的值，在修改完之后的某一个时刻（线程退出之前），自动把线程变量副本的值回写到对象在堆中变量。这样在堆中的对象的值就产生变化了。

禁止指令重排序：

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

在虚拟机层面，为了尽可能减少内存操作速度远慢于CPU运行速度所带来的CPU空置的影响，虚拟机会按照自己的一些规则(这规则后面再叙述)将程序编写顺序打乱——即写在后面的代码在时间顺序上可能会先执行，而写在前面的代码会后执行——以尽可能充分地利用CPU。拿上面的例子来说：假如不是a=1的操作，而是a=new byte1024*1024`，那么它会运行地很慢，此时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修饰符。

注：volatile关键字对于基本类型的修改可以在随后对多个线程的读保持一致，但是对于引用类型如数组，实体bean，仅仅保证引用的可见性，但并不保证引用内容的可见性。