Java内存模型-volatile的应用（实例讲解）

前言

1、并发编程三要素

在并发编程的世界里，下面三要素你必须清楚：

可见性：可见性指多个线程操作一个共享变量时，其中一个线程对变量进行修改后，其他的线程可以立即看到修改的结果。
原子性：原子性指的是一个或多个操作，要么全部执行，并且执行过程中不被其它操作打断，要么就全部不执行。
有序性：程序的执行顺序按照代码的先后顺序来执行。

2、并发编程的三大问题

我们知道CPU、内存、IO三者的速度存在很大的差异，为了平衡三者之间的速度差异，做了如下改变：

CPU 增加了缓存，以均衡与内存的速度差异；
操作系统增加了进程、线程，以分时复用 CPU，进而均衡 CPU 与 I/O 设备的速度差异；
编译程序优化指令执行次序，使得缓存能够得到更加合理地利用。
为了使处理器内部运算单元尽可能被充分利用，处理器还会对输入的代码进行乱序执行(Out-Of-Order Execution)优化，处理器会在乱序执行之后的结果进行重组，保证结果的正确性，也就是保证结果与顺序执行的结果一致。但是在真正的执行过程中，代码执行的顺序并不一定按照代码的书写顺序来执行，可能和代码的书写顺序不同。

但这些改变可能导致诡异性的bug：

缓存导致可见性问题；
编译优化带来的有序性问题；

那如何解决上面的2个问题呢？那就是java内存模型。

ps：还有一个问题是：线程切换带来的原子性问题（后面会讲到）

3、内存模型概念

Java 内存模型规范了JVM 如何提供按需禁用缓存和编译优化的方法。具体来说，这些方法包括 volatile、synchronized 和 final 三个关键字，以及六项 Happens-Before 规则。本文只讲volatile。

关于Java内存模型网上讲的概念太多了，感觉文绉绉的，反正我是看的比较烦，看完也记不住。

ps：网上很多内容都来自于《深入理解Java虚拟机》，这本书也建议你看看。

我这里就简单提取下几个重要的概念，然后整整实例。

Java内存模型的主要目标是定义程序中变量的访问规则：即在虚拟机中将变量存储到主内存或者将变量从主内存取出这样的底层细节。

主内存：java虚拟机规定所有的变量(不是程序中的变量)都必须在主内存中产生，为了方便理解，可以认为是堆区。
工作内存：java虚拟机中每个线程都有自己的工作内存，该内存是线程私有的为了方便理解，可以认为是虚拟机栈。线程的工作内存保存了线程需要的变量在主内存中的副本。虚拟机规定：线程对主内存变量的修改必须在线程的工作内存中进行，不能直接读写主内存中的变量。不同的线程之间也不能相互访问对方的工作内存。如果线程之间需要传递变量的值，必须通过主内存来作为中介进行传递。

4、volatile解决缓存带来的可见性问题

先看一段程序：

public class TestAddCount {
    private long count = 0;

    public static void main(String[] args) throws InterruptedException {
        TestAddCount testAddCount = new TestAddCount();
        // 创建2个子线程，并执行add操作
        Thread t1 = new Thread(() -> {
            testAddCount.add(10);
        });
        Thread t2 = new Thread(() -> {
            testAddCount.add(10);
        });
        // 启动2个子线程
        t1.start();
        t2.start();
        // main线程等待2个子线程执行完
        t1.join();
        System.out.println("线程t1结束时:" + testAddCount.count);
        t2.join();
        // 打印执行后的结果count
        System.out.println("线程t2结束时:" + testAddCount.count);
    }

    private void add(int n) {
        for (int i = 0; i < n; i++) {
            try {
                // 【注意：2个子线程并不是同时启动的，是有先后顺序的，为了尽可能保证2个线程启动时count=0，所以在add方法中让它睡眠0.1秒】
                // 当然，为了让参数n小的情况下效果更加明显，add方法中让它睡眠了0.1秒
                Thread.sleep(100);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            this.count++;
        }
    }
}

我们想要的运行后count的最终结果是不是20？但是实际结果总是小于等于20的。为什么呢？

在单核时代，上面的程序运行结果总是20。（不要告诉我你的电脑是单核的哦）

在多核时代就不一样了。count变量是属于对象TestAddCount的实例变量，存储于堆区，是线程共享的。

CPU为了平衡和内存之间的速度差异，增加了缓存技术。
如下图：线程在读取变量count的时候，会先将count的值读入线程私有的缓存中，待处理结束后，再将缓存中的值写入内存中。比如线程t1和t2刚开始读取到的count值都是0，然后分别进行加1操作。假设t1先将结果1回写到内存，然后t2再将结果1回写到内存，进行2次加1操作后，结果还是1。所以上面的例子得到的最终结果是小于等于20的。这就是缓存导致的可见性问题。

可见性问题.png

如何解决呢？
那就是按需禁用缓存，使用关键字volatile来修饰变量count即可。volatile修饰的变量，能保证新值能立即同步到主内存，以及每次使用前立即从主内存刷新。

private volatile long count = 0;

认真的朋友可能发现，加了volatile还是不行哦。因为还有一个问题，就是原子性问题。

这也便涉及到一道经典的面试题：i++是原子性的嘛？
i++并不是一个原子性的操作。i++做了三次指令操作：

第一次，从内存中读取i变量的值到CPU的寄存器；
第二次，在寄存器中的i自增1
第三次，将寄存器中的值写入内存。

操作系统的任务切换是在CPU指令级别的，而不是高级语言里面的一条语句。如下图：对于++i，在多核机器上，线程t1、t2在读取内存时也可能同时读到同一个值，然后可能发生线程切换，这样就会同一个值自增两次，而实际上只自增了一次，所以++i也不是原子操作。这也就是线程切换带来的原子性问题。

原子性问题.png

如何解决原子性的问题，你可能想到了用synchronized来加锁，保证其是原子性操作，synchronized的内容比较多，回头单独整理一篇吧！！！

5、volatile解决编译优化带来的有序性问题

上面说了volatile还能解决编译优化带来的有序性问题，那么我们再来看下一个经典的双重校验来创建单例模式的例子：

public class Singleton {
    static Singleton instance;

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

看下程序运行流程：

假设两个线程 t1、t2 同时调用 getInstance()，同时发现 instance == null ;
于是同时对 Singleton.class 加锁，此时 JVM 保证只有一个线程能够加锁成功（假设是线程 t1），另外一个线程则会处于等待状态（假设是线程 t2）；
线程 t1 会创建一个 Singleton 实例，之后释放锁，锁释放后，线程 t2 被唤醒，线程t2 再次尝试加锁，此时是可以加锁成功的;
t2 加锁成功后，线程 t2 再次检查 instance == null 是否成立，发现 instance!=null，不会再去实例化instance，直接返回线程t1实例化的instance。

是不是觉得上面的程序没有任何bug？但这个 getInstance() 方法并不完美。问题出在new操作上，我们以为的new操作是：

指令1：分配一块内存 X；
指令2：在内存 X 上初始化 Singleton 对象；
指令3：然后 X 的地址赋值给 instance 变量。

但是实际上优化后的new却是这样的：

指令1：分配一块内存 X；
指令2：将 X 的地址赋值给 instance 变量；
指令3：最后在内存 X 上初始化 Singleton 对象。

优化后会导致什么问题呢？
依然假设线程 t1 先去执行 getInstance() 方法（和线程t2并不是同时去执行），直接获取到锁，并执行实例化new操作，当执行完指令 2 时恰好发生了线程切换，切换到了线程 t2 上；
如果此时线程 t2 也执行 getInstance() 方法，那么线程 t2 在执行第一个判断时会发现 instance != null ，所以直接返回 instance，而此时的 instance 是没有初始化过的，如果我们这个时候访问 instance 的成员变量就可能触发空指针异常。这就是编译优化带来的有序性问题。

这个时候你就可以使用volatile来修饰变量instance，按需禁用编译优化。上面的有序性也就解决了哈。

 static volatile Singleton instance;

总结

总结.png

沪漂程序员一枚。
坚持写博客，如果觉得还可以的话，给个小星星哦，你的支持就是我创作的动力。

个人微信公众号：“Java尖子生”，阅读更多干货。
<font color='red'>关注公众号，领取学习、面试资料。加技术讨论群。</font>