万字长文详细搞懂 volatile 关键字

volatile 这个关键字大家都不陌生，这个关键字一般通常用于并发编程中，是 Java 虚拟机提供的轻量化同步机制，你可能知道 volatile 是干啥的，但是你未必能够清晰明了的知道 volatile 的实现机制，以及 volatile 解决了什么问题，这篇文章我就来带大家解析一波。

volatile 能够保证共享变量之间的 ，共享变量是存在堆区的，而堆区又与内存模型有关，所以我们要聊 volatile ，就需要首先了解一下 Java 内存模型。Java 中的内存模型是 JVM 提供的，而 JVM 又是和内存进行交互的，所以在聊 Java 内存模型前，我们还需要了解一下操作系统层面中内存模型的相关概念。

先从内存模型谈起

计算机在执行程序时，会从内存中读取数据，然后加载到 CPU 中运行。由于 CPU 执行指令的速度要比从内存中读取和写入的速度快的多，所以如果每条指令都要和内存交互的话，会大大降低 CPU 的运行速度，造成昂贵的 CPU 性能损耗，为了解决这种问题，设计了 CPU 高速缓存。有了 CPU 高速缓存后，CPU 就不再需要频繁的和内存交互了，有高速缓存就行了，而 CPU 高速缓存，就是我们经常说的 L1 、L2、L3 cache。

当程序在运行过程中，会将运算需要的数据从主存复制一份到 CPU 的高速缓存中，在 CPU 进行计算时就可以直接从它的高速缓存读写数据，当运算结束之后，再将高速缓存中的数据刷新到主存中。

就拿我们常说的

来举例子

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

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

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

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

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

Java 内存模型

我们上面说到，共享变量会存在缓存不一致的问题，缓存不一致问题换种说法就是线程安全问题，那么共享变量在 Java 中是如何存在的呢VM 中有没有提供线程安全的变量或者数据呢/p>

这就要聊聊 Java 内存模型的问题了，图示如下

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

在 JDK 1.6 之后，优化了 synchronized 声言 LOCK# 的方式，不再对总线进行锁定，转而采取了对 CPU 缓存行进行锁定，因为本篇文章不是介绍 synchronized 实现细节的文章，所以不再对这种方式进行详细介绍，读者只需要知道在优化之后，synchronized 的性能不再成为并发问题的瓶颈了。

MESI 协议就是缓存一致性协议，即 Modified（被修改）Exclusive（独占的） Shared（共享的） Or Invalid（无效的）。MESI 的基本思想就是如果发现 CPU 操作的是共享变量，其他 CPU 中也会出现这个共享变量的副本，在 CPU 执行代码期间，会发出信 通知其他 CPU 自己正在修改共享变量，其他 CPU 收到通知后就会把自己的共享变量置为无效状态。

在多核时代，每个核都能够独立的运行一个线程，每个 CPU 都有自己的缓存，这时 CPU 缓存与内存的数据一致性就没那么容易解决了，当多个线程在不同的 CPU 上执行时，这些线程使用的是不同的 CPU 缓存。

有序性问题

在并发编程中还有带来让人非常头疼的 问题，有序性顾名思义就是顺序性，在计算机中指的就是指令的先后执行顺序。一个非常显而易见的例子就是 JVM 中的。

那么 volatile 不能保证原子性，那么该如何保证原子性呢/p>

在 JDK 5 的 java.util.concurrent.atomic 包下提供了一些原子操作类，例如 AtomicInteger、AtomicLong、AtomicBoolean，这些操作是原子性操作。它们是利用 CAS 来实现原子性操作的（Compare And Swap），CAS实际上是利用处理器提供的 指令实现的，而处理器执行 CMPXCHG 指令是一个原子性操作。

详情可以参考笔者的这篇文章 一场 Atomic XXX 的魔幻之旅。

那么 volatile 能不能保证有序性呢/p>

这里就需要和你聊一聊 volatile 对有序性的影响了

###有序性

上面提到过，重排序分为编译器重排序、处理器重排序和内存重排序。我们说的 volatile 会禁用指令重排序，实际上 volatile 禁用的是编译器重排序和处理器重排序。

下面是 volatile 禁用重排序的规则

下面是一个使用内存屏障的示例

这段代码虽然比较简单，但是使用了不少变量，看起来有些乱，我们反编译一下来分析一下内存屏障对这段代码的影响。

地址在 https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html

由内存屏障的表格可知，第一个操作是普通读写的情况下，只有第二个操作是 volatile 写才会设置内存屏障。

继续向下分析，遇到了 i = v，这个是把 volatile 变量赋值给局部变量，是一种 volatile 读，同样的 j = u 也是一种 volatile 读，所以这两个操作之间会设置 LoadLoad 屏障。

下面遇到了 a = i ，这是为全局变量赋值操作，所以其对应的字节码是 putfield

从上面的分析可知，volatile 实现有序性是通过内存屏障来实现的。

关键概念

在 volatile 实现可见性和有序性的过程中，有一些关键概念，cxuan 这里重新给读者朋友们唠叨下。

• 缓冲行：英文概念是 cache line，它是缓存中可以分配的最小存储单位。因为数据在内存中不是以独立的项进行存储的，而是以临近 64 字节的方式进行存储。

• 缓存行填充：cache line fill，当 CPU 把内存的数据载入缓存时，会把临近的共 64 字节的数据一同放入同一个 Cache line，因为局部性原理：临近的数据在将来被访问的可能性大。

• 缓存命中：cache hit，当 CPU 从内存地址中提取数据进行缓存行填充时，发现提取的位置仍然是上次访问的位置，此时 CPU 会选择从缓存中读取操作数，而不是从内存中取。

• 写命中：write hit ，当处理器打算将操作数写回到内存时，首先会检查这个缓存的内存地址是否在缓存行中，如果存在一个有效的缓存行，则处理器会将这个操作数写回到缓存，而不是写回到内存，这种方式被称为写命中。

• 内存屏障：memory barriers，是一组硬件指令，是 volatile 实现有序性的基础。

• 原子操作：atomic operations，是一组不可中断的一个或者一组操作。

如何正确的使用 volatile 变量

上面我们聊了这么多 volatile 的原理，下面我们就来谈一谈 volatile 的使用问题。

volatile 通常用来和 synchronized 锁进行比较，虽然它和锁都具有可见性，但是 volatile 不具有原子性，它不是真正意义上具有线程安全性的一种工具。

从程序代码简易性和可伸缩性角度来看，你可能更倾向于使用 volatile 而不是锁，因为 volatile 写起来更方便，并且 volatile 不会像锁那样造成线程阻塞，而且如果程序中的读操作的使用远远大于写操作的话，volatile 相对于锁还更加具有性能优势。

很多并发专家都推荐远离 volatile 变量，因为它们相对于锁更加容易出错，但是如果你谨慎的遵从一些模式，就能够安全的使用 volatile 变量，这里有一个 volatile 使用原则

只有在状态真正独立于程序内其他内容时才能使用 volatile。

下面我们通过几段代码来感受一下这条规则的力量。

状态标志

一种最简单使用 volatile 的方式就是将 volatile 作为状态标志来使用。

为了能够正确的调用 shutdown() 方法，你需要确保 shutdownRequested 的可见性。这种状态标志的一种特性就是通常只有一种状态转换：shutdownRequested 的标志从 false 转为 true，然后程序停止。这种模式可以相互来回转换。

双重检查锁

使用 volatile 和 synchronized 可以满足双重检查锁的单例模式。

这里说下为什么要用两次检查，假如有两个线程，线程一在进入到 synchronized 同步代码块之后，在还没有生成 Singleton 对象前发生线程切换，此时线程二判断 instance == null 为 true，会发生线程切换，切换到线程一，然后退出同步代码块，线程切换，线程二进入同步代码块后，会再判断一下 instance 的值，这就是双重检查锁的必要所在。

读-写锁

这也是 volatile 和 synchronized 一起使用的示例，用于实现开销比较低的读-写锁。

如果只使用 volatile 是不能安全实现计数器的，但是你能够在读操作中使用 volatile 保证可见性。如果你想要实现一种读写锁的话，必须进行外部加锁。

我自己肝了六本 PDF，全 传播超过10w+ ，你需要关注一下我的 CSDN 账 ，私信回复 cxuan ，领取全部 PDF，这些 PDF 如下

下载链接 密码：7im6