第一章：Java内存模型解析
Java内存模型（Java Memory Model, JMM）是Java并发编程的核心基础之一，它定义了多线程环境下变量的可见性、原子性和有序性规则。JMM并不描述物理内存结构，而是规范了线程如何与主内存及本地内存交互，确保程序在不同平台下具有一致的并发行为。
主内存与工作内存
每个Java线程都拥有独立的工作内存，用于存储共享变量的副本。所有变量的读写操作最终必须与主内存同步。这种分离设计提高了性能，但也带来了可见性问题。
- 主内存：存放所有共享变量的原始值
- 工作内存：线程私有，保存变量副本
- 线程间通信通过主内存间接完成
内存屏障与volatile关键字
volatile变量具备特殊的内存语义，能够禁止指令重排序，并强制刷新工作内存到主内存。
public class VolatileExample {
private volatile boolean flag = false;
public void writer() {
flag = true; // 写操作会插入store-store屏障
}
public void reader() {
if (flag) { // 读操作会插入load-load屏障
System.out.println("Flag is true");
}
}
}
上述代码中，
volatile保证了
flag的修改对其他线程立即可见，避免了由于缓存不一致导致的延迟感知。
happens-before原则
该原则定义了操作间的先行关系，是判断数据依赖和可见性的关键依据。
| 规则类型 | 说明 |
|---|
| 程序顺序规则 | 同一线程内，前面的操作happens-before后续操作 |
| volatile变量规则 | 对volatile变量的写happens-before任何后续读 |
| 传递性 | 若A happens-before B，B happens-before C，则A happens-before C |
第二章：深入理解happens-before法则
2.1 happens-before的基本定义与核心作用
内存可见性保障机制
happens-before 是 Java 内存模型（JMM）中用于定义多线程操作之间可见性关系的核心规则。它保证在一个操作 A happens-before 操作 B 时，A 的执行结果对 B 可见。
典型规则示例
- 程序顺序规则：同一线程内，前面的操作 happens-before 后续操作
- 监视器锁规则：解锁 happens-before 之后对该锁的加锁
- volatile 变量规则：对 volatile 变量的写操作 happens-before 后续读操作
volatile int ready = 0;
int data = 0;
// 线程1
data = 42; // 1
ready = 1; // 2 写volatile，happens-before线程2的读
// 线程2
if (ready == 1) { // 3 读volatile
System.out.println(data); // 4 能正确读取到42
}
上述代码中，由于 volatile 写（2）happens-before volatile 读（3），进而确保了 data 的写入（1）对读取（4）可见，避免了重排序导致的数据不一致问题。
2.2 程序顺序规则在实际代码中的体现
程序顺序规则是确保代码按预期执行的基础。在单线程环境中，语句通常按照书写顺序依次执行。
基本执行顺序示例
package main
import "fmt"
func main() {
a := 10
b := a + 5 // 依赖上一行的 a
fmt.Println(b) // 输出 15
}
上述代码中，变量
b 的计算必须等待
a 赋值完成后进行，体现了语句间的先后依赖关系。编译器和处理器会尊重这种数据依赖，避免重排序破坏逻辑正确性。
指令重排序的边界
虽然现代CPU和编译器可能对无依赖指令进行重排序以优化性能，但以下情况会强制保持顺序：
- 存在数据依赖的语句
- 包含内存屏障或同步原语的操作
- 有异常控制流（如 panic、recover）的语句
2.3 监视器锁规则与synchronized的正确使用
Java中的监视器锁（Monitor Lock）是实现线程同步的核心机制，每个对象实例都关联一个监视器锁。当线程进入synchronized方法或代码块时，必须先获取该对象的锁，执行完毕后自动释放。
同步代码块的基本语法
synchronized (this) {
// 临界区
count++;
}
上述代码确保同一时刻只有一个线程能执行临界区操作。this表示当前实例对象作为锁对象，适用于实例方法同步。
常见使用场景对比
| 场景 | 锁对象 | 适用性 |
|---|
| 实例方法 | 实例对象 | 多个线程操作同一实例 |
| 静态方法 | 类Class对象 | 全局唯一控制 |
正确选择锁对象可避免竞态条件，提升并发安全性。
2.4 volatile变量规则及其内存语义分析
volatile的内存语义
在Java内存模型中，
volatile变量具备特殊的内存语义。当一个变量被声明为
volatile，JVM会确保该变量的每次读操作都从主内存中获取，写操作立即刷新到主内存，从而保证可见性。
禁止指令重排序
volatile通过插入内存屏障（Memory Barrier）防止编译器和处理器对指令进行重排序，确保程序执行顺序与代码顺序一致。
public class VolatileExample {
private volatile boolean flag = false;
private int data = 0;
public void writer() {
data = 42; // 步骤1
flag = true; // 步骤2：volatile写，插入store-store屏障
}
public void reader() {
if (flag) { // volatile读，插入load-load屏障
System.out.println(data);
}
}
}
上述代码中，
volatile确保了
data = 42在
flag = true之前完成，且其他线程读取
flag为
true时，必定能看到
data的最新值。
| 操作类型 | 内存屏障 | 作用 |
|---|
| volatile写 | StoreStore | 确保前面的普通写不被重排到volatile写之后 |
| volatile读 | LoadLoad | 确保后面的volatile读/写不被重排到当前读之前 |
2.5 启动、终止与中断操作间的先行发生关系
在并发编程中，线程的启动、终止和中断操作之间存在明确的“先行发生”（happens-before）关系，这些关系是确保内存可见性的基础。
启动操作的先行性
当一个线程调用
start() 方法启动另一个线程时，该操作先行于被启动线程中的任何动作。
Thread t1 = new Thread(() -> {
System.out.println("t1 执行"); // 此处能看到 t1 启动前的所有写操作
});
t1.start(); // 此操作 happens-before t1 的 run() 方法
上述代码中，主线程对共享变量的修改在 t1 中可见，得益于启动的先行发生规则。
终止与中断的顺序保证
若线程 A 在终止前调用
t.join()，则 A 能看到 t 中的所有操作结果。同样，中断调用
interrupt() 先行于被中断线程检测到中断状态。
- 线程启动：start() → 线程内执行
- 线程终止：run() 结束 → join() 返回
- 线程中断：interrupt() 调用 → isInterrupted() 为 true
第三章：JMM中的可见性与有序性保障
3.1 主内存与工作内存的交互机制
在Java内存模型（JMM）中，主内存（Main Memory）存放所有共享变量的原始值，而每个线程拥有独立的工作内存（Working Memory），用于缓存从主内存读取的变量副本。
数据同步机制
线程对变量的操作必须在工作内存中进行，修改后需刷新回主内存。这一过程涉及8种原子操作：read、load、use、assign、store、write、lock 和 unlock。
- read：将变量值从主内存读取到工作内存
- load：将 read 获取的值放入工作内存副本中
- use：线程使用变量前调用，传递值给执行引擎
- assign：为变量赋新值
- store：将工作内存中的值传送到主内存
- write：将 store 传送的值写入主内存变量
// 示例：volatile 变量确保可见性
volatile boolean flag = false;
public void writer() {
flag = true; // assign → store → write，立即刷新到主内存
}
public void reader() {
while (!flag) { // use ← load ← read，每次从主内存读取
Thread.yield();
}
}
上述代码中，
volatile 关键字强制线程在读写时与主内存同步，避免了工作内存中缓存过期的问题，确保了多线程环境下的可见性。
3.2 指令重排序问题与as-if-serial语义
在多线程环境下，编译器和处理器为了优化性能，可能对指令执行顺序进行重排序。这种重排序在单线程中不会改变程序的最终结果，这得益于 **as-if-serial** 语义：只要执行结果与顺序执行一致，允许内部重排。
重排序类型
- 编译器重排序：在编译期调整指令顺序
- 处理器重排序：CPU执行时乱序执行（Out-of-Order Execution）
- 内存系统重排序：缓存与写缓冲区导致的可见性延迟
代码示例与分析
int a = 0;
boolean flag = false;
// 线程1
a = 1; // 步骤1
flag = true; // 步骤2
// 线程2
if (flag) { // 步骤3
int i = a * a; // 步骤4
}
尽管程序员期望先执行步骤1再步骤2，但编译器或CPU可能将
flag = true提前，导致线程2读取到
a=0的旧值。as-if-serial仅保证单线程语义正确，不保障跨线程顺序一致性。
解决思路
通过内存屏障（Memory Barrier）或
volatile等关键字限制重排序，确保关键指令的顺序性与可见性。
3.3 内存屏障如何支撑happens-before语义
内存屏障与指令重排控制
在多线程环境中，编译器和处理器可能对指令进行重排序以优化性能，但这会破坏程序的逻辑顺序。内存屏障（Memory Barrier）通过强制规定某些内存操作的执行顺序，确保一个操作“happens-before”另一个操作。
内存屏障类型与作用
常见的内存屏障包括：
- LoadLoad：确保后续的加载操作不会被提前到当前加载之前；
- StoreStore：保证前面的存储操作完成后，才执行后续的存储；
- LoadStore 和 StoreLoad：控制加载与存储之间的顺序。
// 使用volatile变量触发内存屏障
public class MemoryBarrierExample {
private volatile boolean ready = false;
private int data = 0;
public void writer() {
data = 42; // 步骤1
ready = true; // 步骤2，volatile写插入StoreStore屏障
}
public void reader() {
if (ready) { // volatile读插入LoadLoad屏障
System.out.println(data);
}
}
}
上述代码中，
volatile变量的写入和读取会插入相应的内存屏障，确保步骤1一定发生在步骤2之前，且读线程能看到正确的数据状态，从而建立happens-before关系。
第四章：典型并发错误案例剖析
4.1 双重检查锁定模式中的内存模型陷阱
在多线程环境下，双重检查锁定（Double-Checked Locking）常用于实现延迟初始化的单例模式，但其正确性高度依赖于内存模型的保障。
典型错误实现
public class Singleton {
private static Singleton instance;
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton(); // 可能发生指令重排序
}
}
}
return instance;
}
}
上述代码在 Java 中存在严重问题：`new Singleton()` 操作可能被编译器或处理器重排序为分配内存 → 构造对象 → 写入引用，若线程 A 在写入引用前被切换，线程 B 可能读取到未完全构造的实例。
解决方案与内存屏障
使用
volatile 关键字可禁止重排序：
- 确保 instance 的写操作对所有线程可见
- 强制执行顺序一致性语义
修正后的代码：
private static volatile Singleton instance;
volatile 的加入使 JVM 插入适当的内存屏障，防止初始化过程中的指令重排，从而保证线程安全。
4.2 不恰当的volatile使用导致的可见性失效
volatile关键字的误用场景
volatile关键字确保变量的修改对所有线程立即可见，但不保证原子性。开发者常误以为
volatile可替代锁机制，导致并发问题。
public class Counter {
private volatile int count = 0;
public void increment() {
count++; // 非原子操作：读取、修改、写入
}
}
上述代码中，
count++包含三个步骤，尽管
volatile保证了每次读取的是最新值，但多个线程仍可能同时读取相同值，造成更新丢失。
正确同步策略对比
volatile适用于状态标志位等单一读写场景- 复合操作应使用
synchronized或AtomicInteger - 错误依赖
volatile将导致可见性与原子性混淆
4.3 错误假设程序顺序能保证跨线程一致性
在多线程编程中，开发者常误以为代码的编写顺序会自然映射为执行顺序。然而，由于编译器优化和处理器的乱序执行机制，实际运行时指令可能被重排，导致共享数据状态不一致。
典型问题示例
// 两个线程共享的变量
int a = 0;
boolean flag = false;
// 线程1
a = 1;
flag = true;
// 线程2
if (flag) {
System.out.println(a); // 可能输出0！
}
尽管线程1先赋值
a = 1 再设置
flag = true，但线程2仍可能读取到
a=0。这是由于写操作未同步，JVM 或 CPU 可能对指令重排序，或缓存未及时刷新。
解决方案对比
| 方法 | 原理 | 适用场景 |
|---|
| volatile | 禁止指令重排，保证可见性 | 布尔标志、状态变量 |
| synchronized | 互斥与内存屏障 | 复合操作保护 |
4.4 happens-before链断裂引发的数据竞争
可见性保障与顺序一致性
Java内存模型通过happens-before规则确保线程间的操作有序性。若两个操作间无法通过happens-before关系串联，则存在数据竞争风险。
链断裂场景分析
当共享变量未正确同步时，happens-before链可能断裂。例如，一个线程写入变量后未使用volatile或synchronized，另一线程读取该变量将无法保证看到最新值。
// 线程1
sharedVar = 42; // 写操作
flag = true; // 通知线程2
// 线程2
if (flag) { // 读操作
System.out.println(sharedVar); // 可能读到旧值
}
上述代码中，由于
flag和
sharedVar无同步机制，JVM可能重排序或缓存，导致线程2读取
sharedVar时出现竞态。只有通过volatile修饰
flag，才能建立跨线程的happens-before关系，修复链断裂问题。
第五章：构建线程安全程序的设计原则
避免共享可变状态
最有效的线程安全策略是消除共享状态。当多个线程不共享数据时，自然避免了竞态条件。优先使用局部变量和不可变对象。
- 使用
const 或 final 关键字声明不可变对象 - 避免全局变量或静态可变状态
- 通过消息传递替代共享内存（如 Go 的 channel 模型）
同步访问共享资源
当共享状态不可避免时，必须通过同步机制保护临界区。常见的手段包括互斥锁、读写锁和原子操作。
var mu sync.RWMutex
var cache = make(map[string]string)
func Get(key string) string {
mu.RLock()
defer mu.RUnlock()
return cache[key]
}
func Set(key, value string) {
mu.Lock()
defer mu.Unlock()
cache[key] = value
}
使用线程安全的数据结构
现代语言通常提供内置的并发安全容器。例如 Java 的
ConcurrentHashMap 或 Go 的
sync.Map，它们在设计上优化了高并发场景下的性能与安全性。
| 数据结构 | 适用场景 | 并发优势 |
|---|
| sync.Map | 读多写少 | 无锁读取，降低竞争 |
| ConcurrentHashMap | 高并发读写 | 分段锁机制 |
避免死锁的设计实践
确保锁的获取顺序一致，并设置超时机制。使用工具如 Go 的
deadlock 检测包或 Java 的
jstack 分析潜在死锁。
流程图：
[线程A请求锁1] → [线程B请求锁2]
[线程A尝试获取锁2] ↔ [线程B尝试获取锁1] → 死锁
解决方案：统一加锁顺序（如始终先锁1再锁2）
扫一扫
3261
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
