volatile、内存屏障、指令重排序、内存一致性解析

 

1. WHAT

volatile是java中的一个特征修饰符；可以用来修饰一个变量，如下所示

 

2. WHY

在了解为什么要使用volatile关键字之前，我们需要先了解一下几点

1. 什么是指令重排序
2. 什么是内存一致性问题

2.1 指令重排序

首先，我们先要了解下指令重排序。有下面一段代码

 

上面代码定义了一个 int 型变量，定义了一个 boolean 类型变量，然后分别对两个变量进行赋值操作。从代码顺序上看，语句 1 是在语句 2 前面的，那么 JVM 在真正执行这段代码的时候会保证语句 1 一定会在语句 2 前面执行吗？不一定，为什么呢？这里可能会发生指令重排序（Instruction Reorder）

下面解释一下什么是指令重排序，一般来说，处理器为了提高程序运行效率，可能会对输入代码进行优化，它不保证程序中各个语句的执行先后顺序同代码中的顺序一致，但是它会保证程序最终执行结果和代码顺序执行的结果是一致的。

比如上面的代码中，语句 1 和语句 2 谁先执行对最终的程序结果并没有影响，那么就有可能在执行过程中，语句 2 先执行而语句 1 后执行。

 

上述代码中，正常执行的顺序是语句1-->语句2-->语句3-->语句4。有没有可能语句3与语句4的执行顺序发生重排序，即执行顺序变成语句1-->语句2-->语句4-->语句3？

不可能，因为如果语句3与语句4的执行顺序发生变化，那么r的值是不同的。而重排序必须要保证重排序后，执行的结果与未重排序是一样的

在单线程的环境下，指令重排序是没有问题的，但是在并发的情况下，指令重排序，那么执行运行的结果可能不是我们期望的，如下代码

 

上述代码中，语句1与语句2由于不存在数据依赖，所以存在代码重排序的可能，如果发生重排序，先执行语句2，这时候线程2中的while(!inited)条件不能满足，则直接执行doSomethingwithconifg(context)；由于context没有初始化，这个时候调用context会抛出异常

从上面可以看出，指令重排序不会影响单个线程的执行，但是会影响到线程并发执行的正确性

2.2 内存一致性问题

内存模型相关概念

大家都知道，计算机在执行程序时，每条指令都是在 CPU 中执行的，而执行指令过程中，势必涉及到数据的读取和写入。由于程序运行过程中的临时数据是存放在主存（物理内存）当中的，这时就存在一个问题，由于CPU执行速度很快，而从内存读取数据和向内存写入数据的过程跟 CPU 执行指令的速度比起来要慢的多，因此如果任何时候对数据的操作都要通过和内存的交互来进行，会大大降低指令执行的速度。因此在 CPU 里面就有了高速缓存。

也就是，当程序在运行过程中，会将运算需要的数据从主存复制一份到 CPU 的高速缓存当中，那么CPU进行计算时就可以直接从它的高速缓存读取数据和向其中写入数据，当运算结束之后，再将高速缓存中的数据刷新到主存当中。举个简单的例子，比如下面的这段代码：

i = i + 1;

当线程执行这个语句时，会先从主存当中读取i的值，然后复制一份到高速缓存当中，然后 CPU 执行指令对 i 进行加 1 操作，然后将数据写入高速缓存，最后将高速缓存中i最新的值刷新到主存当中。

这个代码在单线程中运行是没有任何问题的，但是在多线程中运行就会有问题了。在多核 CPU 中，每条线程可能运行于不同的 CPU 中，因此每个线程运行时有自己的高速缓存（对单核CPU来说，其实也会出现这种问题，只不过是以线程调度的形式来分别执行的）。本文我们以多核 CPU 为例。

比如同时有 2 个线程执行这段代码，假如初始时 i 的值为 0，那么我们希望两个线程执行完之后 i 的值变为 2。但是事实会是这样吗？

可能存在下面一种情况：初始时，两个线程分别读取i的值存入各自所在的 CPU 的高速缓存当中，然后线程 1 进行加 1 操作，然后把i的最新值 1 写入到内存。此时线程 2 的高速缓存当中 i 的值还是 0，进行加 1 操作之后，i 的值为1，然后线程 2 把 i 的值写入内存。

最终结果 i 的值是 1，而不是 2。这就是著名的缓存一致性问题。通常称这种被多个线程访问的变量为共享变量。

也就是说，如果一个变量在多个CPU中都存在缓存（一般在多线程编程时才会出现），那么就可能存在缓存不一致的问题。

为了解决缓存不一致性问题，通常来说有以下 2 种解决方法：

• 通过在总线加 LOCK# 锁的方式
• 通过缓存一致性协议

这 2 种方式都是硬件层面上提供的方式。

在早期的 CPU 中，是通过在总线上加 LOCK# 锁的形式来解决缓存不一致的问题。因为 CPU 和其他部件进行通信都是通过总线来进行的，如果对总线加 LOCK# 锁的话，也就是说阻塞了其他 CPU 对其他部件访问（如内存），从而使得只能有一个 CPU 能使用这个变量的内存。比如上面例子中 如果一个线程在执行 i = i +1，如果在执行这段代码的过程中，在总线上发出了 LCOK# 锁的信号，那么只有等待这段代码完全执行完毕之后，其他CPU 才能从变量 i 所在的内存读取变量，然后进行相应的操作。这样就解决了缓存不一致的问题。

但是上面的方式会有一个问题，由于在锁住总线期间，其他 CPU 无法访问内存，导致效率低下。

所以就出现了缓存一致性协议。最出名的就是 Intel 的 MESI 协议，MESI 协议保证了每个缓存中使用的共享变量的副本是一致的。它核心的思想是：当 CPU 写数据时，如果发现操作的变量是共享变量，即在其他 CPU 中也存在该变量的副本，会发出信号通知其他 CPU 将该变量的缓存行置为无效状态，因此当其他 CPU 需要读取这个变量时，发现自己缓存中缓存该变量的缓存行是无效的，那么它就会从内存重新读取

 

由上述我们知道，代码在执行的过程中，指令重排序和缓存一致性问题都是我们需要解决的，而volatile关键字就可以解决这两个问题

3. HOW

在了解volatile是如何防止指令重排序与内存一致性的时候，我们需要先了解下内存屏障

3.1 内存屏障

内存屏障分为两种

• Load Barrier 读屏障
• Store Barrier 写屏障

内存屏障的两个作用

• 阻止屏障两侧的指令重排序
• 写的时候，强制把缓冲区/高速缓存中的数据写回主内存，并让缓冲中的数据失效；读的时候直接从主内存中读取

对于Load Barrier来说，在指令前插入Load Barrier，可以让高速缓存中的数据失效，强制从新从主内存加载数据

对于Store Barrier来说，在指令后插入Store Barrier，能让写入缓存中的最新数据更新写入主内存，让其他线程可见

java的内存屏障通常所谓的四种即LoadLoad,StoreStore,LoadStore,StoreLoad实际上也是上述两种的组合，完成一系列的屏障和数据同步功能

• LoadLoad屏障：对于这样的语句Load1; LoadLoad; Load2，在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕。
• StoreStore屏障：对于这样的语句Store1; StoreStore; Store2，在Store2及后续写入操作执行前，保证Store1的写入操作对其它处理器可见。
• LoadStore屏障：对于这样的语句Load1; LoadStore; Store2，在Store2及后续写入操作被刷出前，保证Load1要读取的数据被读取完毕。
• StoreLoad屏障：对于这样的语句Store1; StoreLoad; Load2，在Load2及后续所有读取操作执行前，保证Store1的写入对所有处理器可见。它的开销是四种屏障中最大的。在大多数处理器的实现中，这个屏障是个万能屏障，兼具其它三种内存屏障的功能

3.2 volatile与内存屏障

在每个volatile写操作前插入StoreStore屏障，在写操作后插入StoreLoad屏障；在每个volatile读操作前插入LoadLoad屏障，在读操作后插入LoadStore屏障；所以volatile防止了指令的重排序(保证有序性)和内存的一致性(保证可见性)

当然是用synchronized或者Lock给代码加锁，也是可以保证有序性与可见性的

4. WHERE

4.1 单例模式中使用volatile

上述代码中为什么要加volatile关键字呢？这就必须从对象的创建过程说成。对象创建过程主要分为4个部分

1. 看对象是否加载，没有加载，则加载
2. 分配内存空间，初始化实例
3. 调用构造构造函数
4. 返回地址引用

CPU为了优化，可能会指令重排序，顺序变成了1->2->4->3；即先返回引用地址，然后再进行初始化。

 

线程A执行到new Cache()，开始初始化实例对象，由于存在指令重排序，这次new操作，先把引用赋值了，还没有执行构造函数。这时时间片结束了，切换到线程B执行，线程B调用new Cache()方法，发现引用不等于null，就直接返回引用地址了，然后线程B执行了一些操作，就可能导致线程B使用了还没有被初始化的变量

加上volatile就可以防止指令重排序，从而避免异常的产生

转载原文地址：https://baijiahao.baidu.com/s?id=1667840029586081215&wfr=spider&for=pc