深入剖析Java内存模型与volatile关键字
缓存一致性问题
计算机在运行程序时,每条指令都是在CPU中执行的,在执行过程中会涉及到数据的读写。我们知道程序运行的数据是存储在主存中,这时就会有一个问题,读写主存中的数据没有 CPU 中执行指令的速度快,如果任何的交互都需要与主存打交道则会大大降低效率,所以就有了 CPU寄存器、各级缓存、主存构成了一个速度与容量的平衡金字塔。
有了 CPU 高速缓存虽然解决了效率问题,但是它会带来一个新的问题:数据一致性。
缓存一致性问题的本质
在程序运行中,会将运行所需要的数据复制一份到 CPU 高速缓存中,在进行运算时 CPU 不再和主存打交道,而是直接从高速缓存中读写数据,只有当运行结束后,才会将数据刷新到主存中。
举一个简单的例子:
i = i + 1;
当线程运行这段代码时,首先会从主存中读取 i 的值( 假设此时 i = 1 ),然后复制一份到 CPU 高速缓存中,然后 CPU 执行 + 1 的操作(此时 i = 2),然后将数据 i = 2 写入到高速缓存中,最后刷新到主存中。
其实这样做在单线程中是没有问题的,有问题的是在多线程中。如下:
假如有两个线程 A、B 都执行这个操作( i++ ),两个线程从主存中读取 i 的值( 假设此时 i = 1 ),到各自的高速缓存中,然后线程 A 执行 +1 操作并将结果写入高速缓存中,最后写入主存中,此时主存 i = 2 。线程B做同样的操作,主存中的 i 仍然 = 2 。
让我们通过一个时序图来理解问题所在:
线程A 线程B 主存
│ │ i=1
├─读取i───┐ │ │
│ │ │ │
│ 得到i=1 │ │ │
│ │ │ │
│ 计算i+1=2 │ │
│ │ ├─读取i─┐ │
│ 写入缓存 │ │ │ │
│ │ │ 得到i=1 │ │
│ 刷新到主存 │ │ │
│ │ │ 计算i+1=2 │
│ 主存i=2←───────────────→│ │ │
│ │ 写入缓存 │ │
│ │ 刷新到主存 │
│ │ 主存i=2←─→
│ │ │
最终结果:i=2,而非期望的3。这就是经典的缓存一致性问题。
解决缓存一致性方案有两种:
- 通过在总线加 LOCK# 锁的方式
- 通过缓存一致性协议(MESI 协议)
| 解决方案 | 实现机制 | 优点 | 缺点 | 用场景 |
|---|---|---|---|---|
| 总线加锁 | 通过LOCK#信号锁住总线 | 实现简单 | 性能差,串行化 | 早期处理器 |
| MESI协议 | 缓存行状态机管理 | 性能好,部分并行 | 实现复杂 | 现代处理器 |
MESI协议核心状态:
- Modified:缓存行被修改,与主存不一致
- Exclusive:缓存行独占,与主存一致
- Shared:缓存行被多个CPU共享
- Invalid:缓存行无效,需重新加载
方案分析:
- 第一种方案存在一个问题,它是采用一种独占的方式来实现的,即总线加 LOCK# 锁的话,只能有一个 CPU 能够运行,其他 CPU 都得阻塞,效率较为低下。
- 第二种方案,缓存一致性协议(MESI 协议),它确保每个缓存中使用的共享变量的副本是一致的。
Java内存模型(JMM)
上面从操作系统层次阐述了如何保证数据一致性,下面我们来看一下 Java 内存模型,稍微研究一下它为我们提供了哪些保证,以及在 Java 中提供了哪些方法和机制,来让我们在进行多线程编程时能够保证程序执行的正确性。
在Java中,所有的实例、静态变量和数组元素都存储在堆内存中,堆内存在线程之间是共享的。局部变量,方法定义参数和异常数量参数是存放在Java虚拟机栈上面的。Java虚拟机栈是线程私有的因此不会在线程之间共享,它们不存在内存可见性的问题,也不受内存模型的影响。
Java内存模型(Java Memory Model 简称 JMM),决定一个一个线程对共享变量的写入何时对其它线程可见。JMM定义了线程和主内存之间的抽象关系:线程之间共享变量存储在主内存中,每个线程都有一个私有的本地内存,本地内存中存储了该线程共享变量的副本。本地内存是JMM的一个抽象概率,并不真实的存在。它涵盖了缓存,写缓存区,寄存器以及其他的硬件和编译优化。
Java内存模型的抽象概念图如下所示:
Java 内存模型
看完了Java内存模型的概念,我们再来看看内存模型中主内存是如何和线程本地内存之间交互的。
JMM定义了8个原子操作规范主内存与工作内存的交互:
┌───────────────────┐ ┌───────────────────┐
│ 主内存操作 │ │ 本地内存操作 │
├───────────────────┤ ├───────────────────┤
│ 1. lock (锁定) │ │ 4. load (载入) │
│ 2. unlock (解锁) │←--→│ 5. use (使用) │
│ 3. read (读取) │ │ 6. assign (赋值) │
│ 8. write (写入) │ │ 7. store (存储) │
└───────────────────┘ └───────────────────┘
主内存和本地内存间的交互:
主内存和本地内存的交互即一个变量是如何从主内存中拷贝到本地内存又是如何从本地内存中回写到主内存中的实现,Java内存模型提供了8中操作来完成主内存和本地内存之间的交互。它们分别如下:
- lock(锁定):作用于主内存的变量,它把一个变量标识为一条线程独占的状态。
- unlock(解锁):作用于主内存的变量,它把一个处于锁定状态的变量释放出来,释放后的变量才能被其它线程锁定。
- read(读取):作用于主内存的变量,它把一个变量从主内存传输到线程的本地内存中,以便随后的load动作使用。
- load(载入):作用于本地内存的变量,它把read操作从主内存中的到的变量值放入本地内存的变量副本中。
- use(使用):作用于本地内存的变量,它把本地内存中一个变量的值传递给执行引擎,每当虚拟机遇到一个需要使用到变量值的字节码指令时将会执行这个操作。
- assign(赋值):作用于本地内存的变量,它把一个从执行引擎接收到的变量赋予给本地内存的变量,每当虚拟机遇到一个给变量赋值的字节码指令时将会执行这个操作。
- store(存储):作用于本地内存的变量,它把本地内存中的变量的值传递给主内存中,以便后面的write操作使用。
- write(写入):作用于主内存的变量,它把store操作从本地内存中得到的变量的值放入主内存的变量中。
从上面8种操作中,我们可以看出,当一个变量从主内存复制到线程的本地内存中时,需要顺序的执行read和load操作,当一个变量从本地内存同步到主内存中时,需要顺序的执行store和write操作。Java内存模型只要求上述的2组操作是顺序的执行的,但并不要求连续执行。比如对主内存中的变量a 和 b 进行访问时,有可能出现的顺序是read a read b load b load a。除此之外,Java内存模型还规定了在执行上述8种基本操作时必须满足以下规则:
- read/load 和 store/write 必须成对出现
- 不允许一个线程丢弃它最近的assign操作。即变量在线程的本地内存中改变后必须同步到主内存中。
- 不允许一个线程无原因的把数据从线程的本地内存同步到主内存中。
- 不允许线程的本地内存中使用一个未被初始化的变量。
- 一个变量在同一时刻只允许一个线程对其进行lock操作,但是一个线程可以对一个变量进行多次的lock操作,当线程对同一变量进行了多次lock操作后需要进行同样次数的unlock操作才能将变量释放。
- 如果一个变量执行了lock操作,则会清空本地内存中变量的拷贝,当需要使用这个变量时需要重新执行read和load操作。
- 如果一个变量没有执行lock操作,那么就不能对这个变量执行unlock操作,同样也不允许unlock一个被其它线程执行了lock操作的变量。也就是说lock 和unlock操作是成对出现的并且是在同一个线程中。
- 对一个变量执行unlock操作之前,必须将这个变量的值同步到主内存中去。
内存屏障
内存屏障(Memory Barrier,或有时叫做内存栅栏,Memory Fence)是一种CPU指令,用于控制特定条件下的重排序和内存可见性问题。Java编译器也会根据内存屏障的规则禁止重排序。
内存屏障可以被分为以下几种类型
- LoadLoad屏障:对于这样的语句Load1; LoadLoad; Load2,在Load2及后续读取操作要读取的数据被访问前,保证Load1要读取的数据被读取完毕。
- StoreStore屏障:对于这样的语句Store1; StoreStore; Store2,在Store2及后续写入操作执行前,保证Store1的写入操作对其它处理器可见。
- LoadStore屏障:对于这样的语句Load1; LoadStore; Store2,在Store2及后续写入操作被刷出前,保证Load1要读取的数据被读取完毕。
- StoreLoad屏障:对于这样的语句Store1; StoreLoad; Load2,在Load2及后续所有读取操作执行前,保证Store1的写入对所有处理器可见。它的开销是四种屏障中最大的。在大多数处理器的实现中,这个屏障是个万能屏障,兼具其它三种内存屏障的功能。
volatile
volatile的三大特性:
- 可见性
- 禁止指令重排
- 不保证原子性
public class VolatileFeatures {
// 1. 可见性保证
volatile boolean flag = false;
// 2. 禁止指令重排序
volatile int counter = 0;
// 3. 不保证原子性
volatile int nonAtomic = 0;
public void write() {
// 普通写操作
int temp = 100;
// volatile写 - 建立happens-before关系
flag = true;
}
public void read() {
// volatile读 - 建立happens-before关系
if (flag) {
// 能读到之前所有的写入
System.out.println("Flag is true");
}
}
}
核心规则:
- volatile写前的所有操作不能重排序到写后
- volatile读后的所有操作不能重排序到读前
- volatile写与volatile读之间不能重排序
volatile可见性
volatile 可以保证线程可见性且提供了一定的有序性,但是无法保证原子性。在 JVM 底层,volatile 是采用“内存屏障”来实现的。
volatile禁止重排序
什么是重排序?重排序规则?
在介绍volatile的禁止重排序之前,我们先来了解下什么是重排序。重排序是指编译器和处理器为了优化程序性能而对指令进行重新排序的一种手段。那么重排序有哪些规则呢?不可能任何代码都可以重排序,如果是这样的话,那么在单线程中,我们将不能得到明确的运行的结果。重排序规则如下:
- 具有数据依赖性操作不能重排序,数据依赖性是指两个操作访问同一个变量,如果一个操作是写操作,那么这两个操作就存在数据依赖性。
- 重排序会遵循 as-if-serial语义 与 happens-before原则。
as-if-serial语义
意思是不管怎么重排序,单线程的程序执行结果是不会改变的。
happens-before原则
Java 内存模型下一共有 8 条 happens-before 规则,这样我们就可以根据规则去推论跨线程的内存可见性问题,而不用再去理解底层重排序的规则。
具体的8项规则:
- 程序次序规则(Program Order Rule):在一个线程内,按照程序代码顺序,书写在前面的操作先行发生于书写在后面的操作。准确地说,应该是控制流顺序而不是程序代码顺序,因为要考虑分支、循环等结构。
- 管程锁定规则(Monitor Lock Rule):一个 unlock 操作先行发生于后面对同一个锁的 lock 操作。这里必须强调的是同一个锁,而 “后面” 是指时间上的先后顺序。
- volatile 变量规则(Volatile Variable Rule):对一个 volatile 变量的写操作先行发生于后面对这个变量的读操作,这里的 “后面” 同样是指时间上的先后顺序。
- 线程启动规则(Thread Start Rule):Thread 对象的 start () 方法先行发生于此线程的每一个动作。
- 线程终止规则(Thread Termination Rule):线程中的所有操作都先行发生于对此线程的终止检测,我们可以通过 Thread.join () 方法结束、Thread.isAlive () 的返回值等手段检测到线程已经终止执行。
- 线程中断规则(Thread Interruption Rule):对线程 interrupt () 方法的调用先行发生于被中断线程的代码检测到中断事件的发生,可以通过 Thread.interrupted () 方法检测到是否有中断发生。
- 对象终结规则(Finalizer Rule):一个对象的初始化完成(构造函数执行结束)先行发生于它的 finalize () 方法的开始。
- 传递性(Transitivity):如果操作 A 先行发生于操作 B,操作 B 先行发生于操作 C,那就可以得出操作 A 先行发生于操作 C 的结论。
多线程问题的Happens-Before分析法
步骤1:识别共享变量
class ProblematicCounter {
private int count = 0; // 共享变量
public void increment() {
count++; // 非原子操作
}
}
步骤2:分析操作顺序
线程A: read count(0) → add 1 → write count(1)
线程B: read count(0) → add 1 → write count(1)
最终结果: 1 (期望2)
步骤3:应用Happens-Before规则
线程A内部:符合程序顺序规则
线程B内部:符合程序顺序规则
线程A与线程B之间:没有Happens-Before关系
步骤4:选择同步机制
// 方案1:synchronized(监视器锁规则)
public synchronized void increment() {
count++;
}
// 方案2:volatile + Atomic(volatile变量规则)
private volatile int count = 0;
public void increment() {
// 需要原子操作,volatile不够
}
// 方案3:使用AtomicInteger
private AtomicInteger count = new AtomicInteger(0);
public void increment() {
count.incrementAndGet(); // 内部使用volatile
}
总结
Happens-Before原则是理解Java并发编程的钥匙,它提供了:
- 可见性保证:确保一个线程的修改对其他线程可见
- 顺序约束:建立操作之间的偏序关系
- 推理工具:让程序员可以推导多线程程序的正确性
关键要点:
- Happens-Before是JMM的核心抽象,不是具体实现
- 八大规则是构建线程安全程序的基础
- volatile和synchronized是实现Happens-Before的主要手段
- 传递性规则是最强大的推理工具