上篇文章我们讲了synchronized的用法和实现原理，我们总爱说synchronized是重量级锁，volatile是轻量级锁。为什么volatile是轻量级锁，体现在哪些方面？以及volatile的作用和实现原理是怎样的？本篇带你一块学习一下。

1. volatile是什么？

volatile是Java提供的一种轻量级的同步机制。与synchronized修饰方法、代码块不同，volatile只用来修饰变量。并且与synchronized、ReentrantLock等重量级锁不同的是，volatile更轻量级，因为它不会引起线程上下文的切换和调度。

2. volatile的作用

说volatile作用之前，先说一下并发编程的三大特性：原子性、可见性和有序性。

• 原子性

即一个或者多个操作作为一个整体，要么全部执行，要么都不执行，并且操作在执行过程中不会被线程调度机制打断；而且这种操作一旦开始，就一直运行到结束，中间不会有任何上下文切换。

• 可见性

可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。

• 有序性

为了提高程序的执行效率，编译器会对编译后的指令进行重排序，即代码的编写顺序不一定就是代码的执行顺序。

并发编程中只有同时满足这三大特性，才能保证程序正确的执行。而volatile的只保证了可见性和有序性，不保证原子性。

volatile的作用只有两个：

• 保证内存的可见性
• 禁止JVM内存重排序（保证有序性）

在并发多线程情况下，为什么会有可见性问题？如果不做控制，为什么一个线程修改了共享变量的值，其他线程不能立即看到？这就需要聊到JMM（Java内存模型，Java Memory Model）。

3. JMM是什么

JMM（Java内存模型，Java Memory Model）定义程序访问变量的规范，为了屏蔽不同操作系统之间的差异。

由于Java共享变量是存储在主内存中，而Java线程无法直接访问主内存中数据，只能把主内存中的数据读到本地内存（相当于拷贝一份副本），修改完本地内存的数据，再写回主内存。而此时另一个线程也把主内存的数据拷贝到自己私有的本地内存中，虽然线程1已经修改了主内存从数据，线程2却无法感知到，所以就出现了内存可见性问题。

4. 可见性问题

JMM定义的这套模型，会有可见性问题。当线程1修改了本地内存的数据，并刷会主内存中，其他线程中本地内存的数据并没有变化。也就是一个线程修改了共享变量的值，其他线程无法立即感知到。

像上图的流程，两个线程都把count=0的变量拷贝到自己私有的本地内存中，线程1把count的值修改为1，并写回主内存，而线程2本地内存的count值还是0。

那么volatile是怎么解决可见性问题呢？

volatile主要通过汇编lock前缀指令，它会锁定当前内存区域的缓存（缓存行），并且立即将当前缓存行数据写入主内存（耗时非常短），回写主内存的时候会通过MESI协议使其他线程缓存了该变量的地址失效，从而导致其他线程需要重新去主内存中重新读取数据到其工作线程中。

什么是MESI协议？

MESI协议（Modified Exclusive Shared Or Invalid）是各处理器访问缓存时都遵循一致性协议。核心思想是：

当CPU写数据时，如果发现操作的变量是共享变量，即在其他CPU中也存在该变量的副本，会发出信号通知其他CPU将该变量的缓存行置为无效状态，因此当其他CPU需要读取这个变量时，发现自己缓存中缓存该变量的缓存行是无效的，那么它就会从内存重新读取。

MESI分别代表缓存行数据所处的四种状态，通过对这四种状态的切换，来达到对缓存数据进行管理的目的。

而MESI协议是通过总线嗅探技术实现的：

总线嗅探是通过CPU侦听总线上发生的数据交换操作，当总线上发生了数据操作，那么总线就会广播对应的通知，CPU收到通知后，再根据本地的情况进行响应。

5. 有序性问题

虚拟机在进行代码编译时，对改变顺序后不会对最终结果造成影响的代码，虚拟机不一定会按我们写的代码顺序运行，有可能进行重排序。实际上虽然重排后不会对变量值有影响，但会造成线程安全问题。

重排序又可以分为三种：

• 编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序
• 指令级并行的重排序。现代CPU采用了指令级并行技术来将多条指令重叠执行。对于不存在数据依赖的指令，CPU可以改变语句对应机器指令的执行顺序
• 内存系统的重排序。由于CPU使用三级缓存结构，这使得数据加载和存储操作看上去可能是在乱序执行的

不过重排序也不是随便重排的，发生指令重排序的前提是：在单线程下不影响执行结果、对没有数值依赖的代码进行重排序。这就是as-if-serial语义。在多线程情况下有一套更具体的规则，那就是happens-before原则。

happens-before由以下八大原则组成：

• 程序次序规则：一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作（线程的执行结果有序）
• 锁定规则：一个unlock操作先行发生于后面对同一个锁的lock操作
• volatile变量规则：对一个volatile变量的写操作先行发生于后面对这个变量的读操作
• 传递规则：如果操作A先行发生于操作B，操作B先行发生于操作C，则可以得出操作A先行发生于操作C
• 线程启动规则：Thread对象的start()方法先行发生于该线程的其他任何操作
• 线程中断规则：对线程中断方法interrupt()的调用先行发生于被中断线程检测到中断事件的发生
• 线程终结规则：线程中所有操作先行发生于线程的终止检测。通过Thread.join()方法结束、Thread.isAlive()方法的返回值等手段检测到线程已经终止执行。比如在A线程中调用B.join()方法，B线程执行完成后，B对共享变量的修改，对A来说是可见的

对象终结规则：一个对象的初始化方法完成先行发生于该对象的finalize()方法的开始

如果两个操作不满足上述八大原则中的任意一个，那么这两个操作就没有顺序保证，虚拟机可以对这两个操作进行重排序。如果操作A happens-before 操作B，那么A在内存所做的修改对B都是可见的。

而volatile是通过插入内存屏障（Memory Barrier），在内存屏障前后禁止重排序优化，以此实现有序性。

内存屏障有两个作用：一是保证特定操作的执行顺序，二是保证某些变量的内存可见性。

volatile内存语义的实现： JMM 针对编译器制定的 volatile 重排序规则表

编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序：

• 在每个volatile写操作的前面插入一个StoreStore屏障
• 在每个volatile写操作的后面插入一个StoreLoad屏障
• 在每个volatile读操作的后面插入一个LoadLoad屏障
• 在每个volatile读操作的后面插入一个LoadStore屏障

6. volatile应用场景

volatile可以保证可见性和有序性，但无法保证原子性。所以它的应用场景就不如synchronized广泛，主要有两个场景：一是做状态变量，二是做需要重新赋值的共享对象。

比如：第二种场景常见的就有修饰单例模式的对象。

public class Singleton {
  // 使用volatile修饰，赋值后，其他线程能立即感知到
    private static volatile Singleton instance;

    private Singleton(){
    }

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

}
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.

还有就是CopyOnWriteArrayList的底层实现就是用volatile修饰的数组，因为CopyOnWriteArrayList每次修改数据后都会数组重新赋值，而不是只修改数据中的一个值，这样才能保证了CopyOnWriteArrayList的数据安全性。