JMM

📚 Java 内存模型（JMM）深度解析

🌟 JMM 的核心目标

Java 内存模型（Java Memory Model, JMM）定义了多线程环境下共享变量的访问规则，确保在不同线程间操作共享数据时的可见性、有序性和原子性。它是 Java 并发编程的基石，帮助开发者在复杂的硬件和编译器优化中编写线程安全的代码。

🧩 JMM 的核心概念

1. 主内存（Main Memory）与工作内存（Working Memory）

主内存：所有线程共享的内存区域，存储所有变量（实例字段、静态字段、数组对象元素）。
工作内存：每个线程私有的内存空间，存储该线程使用的变量的副本。
交互规则：
```
[线程] ←→ [工作内存] ←→ [主内存]
```
所有变量操作必须通过工作内存与主内存交互（JMM 抽象模型，不直接对应物理硬件）。

2. 内存间交互的原子操作

JMM 定义了 8 种原子操作（如 read、load、use、assign、store、write 等），控制线程与内存的交互流程。例如：

线程读取变量：read → load → use
线程修改变量：assign → store → write

⚙️ 三大核心问题与 JMM 解决方案

1. 可见性（Visibility）

问题：一个线程修改共享变量，其他线程无法立即看到修改。
JMM 方案：
- volatile 关键字：强制将修改刷新到主内存，并使其他线程的副本失效。
- synchronized 锁：释放锁前将变量同步到主内存，获取锁时从主内存重新加载。
- final 字段：正确初始化后对其他线程可见。

2. 有序性（Ordering）

问题：编译器/处理器优化导致指令重排序，破坏程序预期顺序。
JMM 方案：
- happens-before 规则：定义操作间的可见性顺序约束。
- 内存屏障（volatile、synchronized 隐式插入屏障）禁止特定重排序。

3. 原子性（Atomicity）

问题：多线程操作导致非原子步骤被中断。
JMM 方案：
- synchronized：通过锁机制保证代码块原子性。
- 原子类（AtomicInteger 等）：基于 CAS 实现无锁原子操作。

🔍 Happens-Before 原则详解

JMM 通过 happens-before 规则定义操作的可见性顺序，若操作 A happens-before 操作 B，则 A 的结果对 B 可见。

六大核心规则

规则	说明	示例
程序顺序规则	同一线程内的操作按代码顺序保证有序性（但不禁止指令重排序）	`int x = 1; int y = x;`（y 的赋值能看到 x=1）
锁规则	解锁操作 happens-before 后续的加锁操作	`synchronized(lock) { x=1; }` → `synchronized(lock) { print(x); }`
`volatile` 规则	对 volatile 变量的写操作 happens-before 后续的读操作	`volatile boolean flag = true;` → `if(flag) {...}`
线程启动规则	父线程启动子线程前的修改对子线程可见	`thread.start()` 前的修改对 `run()` 可见
线程终止规则	线程的所有操作 happens-before 其他线程检测到该线程终止	`thread.join()` 后的代码能看到线程内的修改
传递性规则	若 A happens-before B，且 B happens-before C，则 A happens-before C	组合多个规则形成顺序链

💻 JMM 的实现机制

1. 内存屏障（Memory Barriers）

屏障类型	作用	对应代码示例
LoadLoad	禁止该屏障前后的读操作重排序	`volatile读` 后插入
StoreStore	禁止该屏障前后的写操作重排序	`volatile写` 前插入
LoadStore	禁止读操作与后续写操作重排序	较少显式使用
StoreLoad	禁止写操作与后续读操作重排序（全能屏障）	`volatile写` 后插入（开销最大）

2. `volatile` 的内存语义

写操作：
1. 将工作内存的值刷新到主内存（store + write）。
2. 插入 StoreStore + StoreLoad 屏障。
读操作：
1. 从主内存重新加载最新值（read + load）。
2. 插入 LoadLoad + LoadStore 屏障。

3. 锁的内存语义（以 `synchronized` 为例）

加锁（monitorenter）：
- 将工作内存中的共享变量置为无效，强制从主内存重新加载。
释放锁（monitorexit）：
- 将工作内存的修改刷新到主内存。

🌰 JMM 实战案例

案例 1：双重检查锁定（DCL）与 `volatile`

class Singleton {
    private static volatile Singleton instance; // 必须 volatile
    
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton(); // 无 volatile 可能看到未初始化对象
                }
            }
        }
        return instance;
    }
}

问题根源：new Singleton() 的非原子操作（分配内存→初始化→赋值引用）可能被重排序。
volatile 作用：禁止指令重排序，保证其他线程看到完全初始化的对象。

案例 2：不可变对象与 `final`

class ImmutableObject {
    private final int x;
    
    public ImmutableObject(int x) {
        this.x = x; // final 字段的初始化保证可见性
    }
}

JMM 保证：正确构造的不可变对象（所有字段为 final），无需同步即可安全发布。

⚠️ 常见误区与陷阱

误区	正确理解
`volatile` 能保证原子性	只能保证单次读/写的原子性，复合操作仍需锁或原子类
`synchronized` 完全禁止指令重排序	仅保证同步块内的有序性（临界区外的代码仍可能被重排序）
无竞争时无需考虑内存可见性	即使单线程，JIT 优化可能导致可见性问题（如循环中读取未标记为 volatile 的变量）
64 位变量（long/double）原子性	32 位 JVM 上 long/double 的非 volatile 变量可能被分解为两次 32 位操作

📊 JMM 与硬件内存架构的关系

           [Java Thread]          [Java Thread]
               ↓   ↑                   ↓   ↑
           [工作内存]               [工作内存]
               ↓   ↑                   ↓   ↑
           [CPU 缓存]               [CPU 缓存]
               ↖   ↗               ↖   ↗
                 [主内存/RAM]

JMM 是抽象模型：不直接对应物理硬件结构，但最终映射到 CPU 缓存一致性协议（如 MESI）。
缓存行（Cache Line）：伪共享问题的根源（如 @Contended 注解的优化场景）。

💡 JMM 开发最佳实践

优先使用高层工具：
- 并发集合（ConcurrentHashMap）
- 原子类（AtomicInteger）
- 线程池（ExecutorService）
严格遵循 happens-before 规则：
- 通过 volatile、锁、final 等建立明确的可见性顺序。
避免过度优化：
- 在未出现性能问题前，优先使用简单的 synchronized。
使用分析工具验证：
- JMM 验证工具：JCStress、Java Pathfinder。
- 性能分析：JProfiler、Async Profiler。

🌟 总结

Java 内存模型通过定义线程与内存的交互规则，为开发者提供了在多线程环境中控制可见性、有序性和原子性的工具。理解其核心机制（如 happens-before、内存屏障、volatile 语义）是编写高性能并发代码的关键。记住三个黄金法则：

可见性：通过同步机制（锁/volatile）保证修改可见。
有序性：依赖 happens-before 规则约束指令顺序。
原子性：使用锁或原子类保护复合操作。