计算机在运行程序时，每条指令都是在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协议 | 缓存行状态机管理 | 性能好，部分并行 | 实现复杂 | 现代处理器 |
MESI协议核心状态：
方案分析：
上面从操作系统层次阐述了如何保证数据一致性，下面我们来看一下 Java 内存模型，稍微研究一下它为我们提供了哪些保证，以及在 Java 中提供了哪些方法和机制，来让我们在进行多线程编程时能够保证程序执行的正确性。
在Java中，所有的实例、静态变量和数组元素都存储在堆内存中，堆内存在线程之间是共享的。局部变量，方法定义参数和异常数量参数是存放在Java虚拟机栈上面的。Java虚拟机栈是线程私有的因此不会在线程之间共享，它们不存在内存可见性的问题，也不受内存模型的影响。
Java内存模型（Java Memory Model 简称 JMM），决定一个一个线程对共享变量的写入何时对其它线程可见。JMM定义了线程和主内存之间的抽象关系：线程之间共享变量存储在主内存中，每个线程都有一个私有的本地内存，本地内存中存储了该线程共享变量的副本。本地内存是JMM的一个抽象概率，并不真实的存在。它涵盖了缓存，写缓存区，寄存器以及其他的硬件和编译优化。
Java内存模型的抽象概念图如下所示：
看完了Java内存模型的概念，我们再来看看内存模型中主内存是如何和线程本地内存之间交互的。
JMM定义了8个原子操作规范主内存与工作内存的交互：
┌───────────────────┐ ┌───────────────────┐
│ 主内存操作 │ │ 本地内存操作 │
├───────────────────┤ ├───────────────────┤
│ 1. lock (锁定) │ │ 4. load (载入) │
│ 2. unlock (解锁) │←--→│ 5. use (使用) │
│ 3. read (读取) │ │ 6. assign (赋值) │
│ 8. write (写入) │ │ 7. store (存储) │
└───────────────────┘ └───────────────────┘
主内存和本地内存间的交互：
主内存和本地内存的交互即一个变量是如何从主内存中拷贝到本地内存又是如何从本地内存中回写到主内存中的实现，Java内存模型提供了8中操作来完成主内存和本地内存之间的交互。它们分别如下：
从上面8种操作中，我们可以看出，当一个变量从主内存复制到线程的本地内存中时，需要顺序的执行read和load操作，当一个变量从本地内存同步到主内存中时，需要顺序的执行store和write操作。Java内存模型只要求上述的2组操作是顺序的执行的，但并不要求连续执行。比如对主内存中的变量a 和 b 进行访问时，有可能出现的顺序是read a read b load b load a。除此之外，Java内存模型还规定了在执行上述8种基本操作时必须满足以下规则：
内存屏障（Memory Barrier，或有时叫做内存栅栏，Memory Fence）是一种CPU指令，用于控制特定条件下的重排序和内存可见性问题。Java编译器也会根据内存屏障的规则禁止重排序。
内存屏障可以被分为以下几种类型
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 可以保证线程可见性且提供了一定的有序性，但是无法保证原子性。在 JVM 底层，volatile 是采用“内存屏障”来实现的。
volatile禁止重排序
什么是重排序？重排序规则？
在介绍volatile的禁止重排序之前，我们先来了解下什么是重排序。重排序是指编译器和处理器为了优化程序性能而对指令进行重新排序的一种手段。那么重排序有哪些规则呢？不可能任何代码都可以重排序，如果是这样的话，那么在单线程中，我们将不能得到明确的运行的结果。重排序规则如下：
as-if-serial语义
意思是不管怎么重排序，单线程的程序执行结果是不会改变的。
happens-before原则
Java 内存模型下一共有 8 条 happens-before 规则，这样我们就可以根据规则去推论跨线程的内存可见性问题，而不用再去理解底层重排序的规则。
具体的8项规则：
多线程问题的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并发编程的钥匙，它提供了：
关键要点：
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。