Java volatile关键字详解

最新推荐文章于 2022-05-26 15:55:19 发布

nju.拈花

最新推荐文章于 2022-05-26 15:55:19 发布

阅读量315

点赞数 1

分类专栏： java.concurrent 文章标签： java concurrent

本文链接：https://blog.csdn.net/nlznlz/article/details/88268578

版权

java.concurrent 专栏收录该内容

12 篇文章 0 订阅

订阅专栏

1.关于volatile

volatile是Java语言中的关键字，用来修饰会被多线程访问的共享变量，是JVM提供的轻量级的同步机制，相比同步代码块或者重入锁有更好的性能。它主要有两重语义，一是保证多个线程对共享变量访问的可见性，二防止指令重排序。

2.语义一:内存可见性

2.1 一个例子

public class TestVolatile {

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

        ThreadDemo threadDemo = new ThreadDemo();
        new Thread(threadDemo).start();
        threadDemo.flag = false;
        System.out.println("已将flag置为" + threadDemo.flag);

    }

    static class ThreadDemo implements Runnable {

        boolean flag = true;

        @Override
        public void run() {
            System.out.println("Flag=" + flag);
        }

    }
}

当你多次执行代码时,有一定几率会出现这种结果：

已将flag置为false
Flag=true

Process finished with exit code 0

在主线程将子线程实例的flag置为false后，子线程中的flag竟然还是true。这是怎么回事？这就是多线程的内存可见性问题。对于一个没有volatile修饰的的共享变量，当一个线程对其进行了修改，另一线程并不一定能马上看见这个被修改后的值。为什么会出现这种情况呢？这就要从java的内存模型谈起。

2.2 Java的内存模型(JMM)

详细可参见这篇文章：https://blog.csdn.net/nlznlz/article/details/79998985。

Java内存模型规定了所有的变量都存储在主内存中，每条线程还有自己的工作内存，线程的工作内存中保存了该线程中是用到的变量的主内存副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存。不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量的传递均需要自己的工作内存和主存之间进行数据同步进行。

看看JMM模型会给我们在多线程环境下的读写带来什么样的问题。

当一个线程(线程1)对共享变量进行修改时，修改的并不是主内存中的变量，而是该线程对应的工作内存中该变量的一个副本。
当主内存中的变量值已经被修改，另一个线程(线程2)读取的却还是自己工作内存中的旧值。

这时就出现了共享变量在多线程环境下的可见性问题。如果把线程的工作内存当作主内存的缓存，这个问题的本质就在于如何解决缓存失效问题。那么JMM中是如何解决可见性问题的？这就不得不提到happens-before规则。

2.3 happens-before规则

happens-before规则又叫先行发生规则。它定义了Java内存模型中两项操作的偏序关系，更确切的说，它定义了操作可见性之间的偏序关系。比如A操作 happens-before B操作，并不意味这A操作一定在B操作之前，而是A操作的影响能被操作B观察到，这个影响包括改变了内存中共享变量的值，发送消息等。那么JMM定义了哪些happens-before规则？

程序顺序规则:一个线程中的每个操作，happens-before于该线程中的任意后续操作。
监视器锁规则：对于一个锁的解锁，happens-before于随后对这个锁的加锁。
volatile变量规则：对于一个volatile 变量的写，happens-before于任意后续对这个volatile变量的读。

这里对于我们而言重要的是第三点。即对于一个volatile变量，写操作happens-before于读操作，也就是说，一个线程对volatile变量做了修改，另一个线程能马上读到这个被修改后的值。
这样就能解决共享变量在多线程环境下的可见性问题了。结合JMM模型，我们可以继续探讨下volatile是如何做到这点的。

2.4 volatile解决内存可见性问题的原理

当一个变量被修饰为volatile后，对其的读写就会显得比较特别。

写一个volatile变量时，JMM首先修改工作内存中的变量值，并刷新到主内存中。
读一个变量时，JMM会把该线程对应的本地内存置为无效，并从主内存中读取共享变量。

对volatile变量的读写，可以说都是直接对主内存进行的操作，这样虽然会牺牲一些性能，但是解决了“缓存一致性问题”，使得变量在多线程间的可见性得到了很好的保证。

3. 语义二：禁止指令重排

3.1 为什么会有指令重排

为了优化程序性能，编译器和处理器会对Java编译后的字节码和机器指令进行重排序，通俗的说代码的执行顺序和我们在程序中定义的顺序会有些不同，只要不改变单线程环境下的执行结果就行。zejian的这篇文章分析了指令重排给CPU指令流水所带来的性能提升：https://blog.csdn.net/javazejian/article/details/72772461#%E5%A4%84%E7%90%86%E5%99%A8%E6%8C%87%E4%BB%A4%E9%87%8D%E6%8E%92。

但是在多线程环境下，指令重排却可能出现并发问题。比如经典的双重检查锁实现单例模式的例子：

3.2 线程不安全的双重检查单例模式

public class Singleton {

    private static Singleton instance;

    private Singleton(){

    }

    public static Singleton getInstance(){
        if(null == instance){
            synchronized (Singleton.class){
                if(null == instance){
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

运行这段代码我们可能会得到一个匪夷所思的结果：我们获得的单例对象是未初始化的。为什么会出现这种情况？因为指令重排。首先要明确一点，同步代码块中的代码也是能够被指令重排的。然后来看问题的关键：

 instance = new Singleton();

虽然在代码中只有一行，编译出的字节码指令可以用如下三行表示：

为对象分配内存空间；
初始化对象；
将instance变量指向刚分配的内存地址。

由于步骤2、3交换不会改变单线程环境下的执行结果，故而这种重排序是被允许的。也就是我们在初始化对象之前就把instance变量指向了该对象。而如果这时另一个线程刚好执行到代码所示的2处：

if (instance == null)

那么这时候有意思的事情就发生了：虽然instance指向了一个未被初始化的对象，但是它确实不为null了，所以这个判断会返回false，之后它将return一个未被初始化的单例对象！

由于重排序是编译器和CPU自动进行的，那么有什么办法能禁止这种重排序操作吗？很简单，给instance变量加个volatile关键字就行，这样编译器就会根据一定的规则禁止对volatile变量的读写操作重排序了。而编译出的字节码，也会在合适的地方插入内存屏障，比如volatile写操作之前和之后会分别插入一个StoreStore屏障和StoreLoad屏障，禁止CPU对指令的重排序越过这些屏障。