1. JMM内存模型基础认知

第一次接触JMM这个概念是在处理一个多线程数据不一致的bug时。当时有个计数器变量被多个线程同时修改，明明逻辑上应该累加到1000，但实际运行结果总是在800-900之间波动。加了synchronized解决问题后，我意识到需要系统理解Java内存模型的运作机制。

JMM（Java Memory Model）定义了Java程序中各种变量（线程共享变量）的访问规则，以及在JVM中将变量存储到内存和从内存中读取变量的底层细节。它解决的核心问题是：当多个线程同时修改和读取共享数据时，如何保证数据的一致性。

与JVM运行时数据区不同，JMM是更上层的抽象概念。举个例子，JVM内存区域像是计算机的物理内存条，而JMM更像是操作系统对内存访问制定的协议规范。JMM主要关注以下特性：

• 原子性：一个操作要么全部执行完成，要么完全不执行。就像银行转账，不能只扣款不收款。
• 可见性：当某线程修改了共享变量，其他线程能立即看到修改后的值。这就像办公室白板通知，修改后所有人都能看到最新内容。
• 有序性：程序执行的顺序按照代码的先后顺序执行。但实际运行时，编译器和处理器会进行指令重排序优化。

在HotSpot虚拟机中，JMM的具体实现涉及以下几个关键部分：

1. 主内存（Main Memory）：存储所有共享变量的实际值
2. 工作内存（Work Memory）：每个线程私有的内存空间，保存该线程使用到的变量副本
3. 内存屏障（Memory Barrier）：禁止特定类型的处理器重排序

关键理解：JMM通过控制主内存与工作内存之间的交互协议，来保证多线程环境下的可见性、有序性和原子性。这是理解所有Java并发编程的基础。

2. JMM的核心工作原理

2.1 内存间的交互操作

JMM定义了8种原子操作来完成主内存与工作内存的交互：

1. lock（锁定）：作用于主内存变量，将其标识为线程独占状态
2. unlock（解锁）：释放锁定状态的变量
3. read（读取）：从主内存传输变量值到工作内存
4. load（载入）：把read得到的值放入工作内存的变量副本
5. use（使用）：把工作内存中的变量值传递给执行引擎
6. assign（赋值）：将执行引擎接收到的值赋给工作内存变量
7. store（存储）：把工作内存中的变量值传送到主内存
8. write（写入）：将store得到的值放入主内存变量

这些操作必须满足以下规则：

• read和load、store和write必须成对出现
• 不允许线程丢弃最近的assign操作（即工作内存变化必须同步回主内存）
• 新变量只能在主内存"诞生"，不允许工作内存直接使用未初始化变量

2.2 原子性保障机制

对于基本数据类型的访问读写（除long和double外），JMM保证这些操作具有原子性。但像i++这种复合操作，在字节码层面其实是多个指令：

// 源代码 i++; // 字节码等价操作 int temp = i; temp = temp + 1; i = temp;

要保证这种操作的原子性，就需要使用synchronized或Lock等同步机制。在HotSpot内部，这些同步操作最终会转化为底层的内存屏障指令。

2.3 可见性实现原理

可见性问题产生的根本原因是：

1. 现代CPU的多级缓存架构
2. 编译器的指令重排序优化

JMM通过以下方式保证可见性：

• volatile关键字：修饰的变量在修改后会立即刷新到主内存，且每次使用前都从主内存重新读取
• synchronized同步块：在unlock前必须把变量同步回主内存
• final关键字：被final修饰的字段在构造器初始化完成后对其他线程可见

在x86架构下，volatile变量的写操作会插入StoreLoad屏障，防止写操作与后续可能的读操作重排序。

3. 指令重排序与happens-before原则

3.1 重排序的三种类型

1. 编译器优化重排序：在不改变单线程语义前提下，调整语句执行顺序
2. 指令级并行重排序：现代处理器采用指令级并行技术将多条指令重叠执行
3. 内存系统重排序：由于使用缓存，使得加载和存储操作看上去可能是乱序执行

// 典型的重排序问题示例 class ReorderExample { int a = 0; boolean flag = false; public void writer() { a = 1; // 操作1 flag = true; // 操作2 } public void reader() { if (flag) { // 操作3 int i = a; // 操作4 } } }

在没有同步的情况下，操作1和操作2可能被重排序，导致操作4读取到a的旧值0。

3.2 happens-before规则

JMM通过happens-before关系定义操作间的可见性保证：

1. 程序顺序规则：同一线程中的每个操作，happens-before于该线程中的任意后续操作
2. 监视器锁规则：对一个锁的解锁，happens-before于随后对这个锁的加锁
3. volatile变量规则：对一个volatile域的写，happens-before于任意后续对这个volatile域的读
4. 传递性规则：如果A happens-before B，且B happens-before C，那么A happens-before C

这些规则为开发者提供了足够强的内存可见性保证，同时给了JVM足够的优化空间。

4. volatile关键字的深度解析

4.1 volatile的语义特性

volatile变量具有两种特性：

1. 保证变量的可见性
2. 禁止指令重排序（通过内存屏障实现）

但需要注意：

• volatile不保证复合操作的原子性（如count++）
• 过度使用volatile会导致性能下降，因为禁止了优化

4.2 volatile的内存屏障策略

在JVM层面，volatile通过在指令序列中插入内存屏障来禁止特定类型的处理器重排序：

• StoreStore屏障：确保volatile写之前的普通写操作先于volatile写
• StoreLoad屏障：确保volatile写之后的操作不会被重排序到volatile写之前
• LoadLoad屏障：确保volatile读之后的操作不会被重排序到volatile读之前
• LoadStore屏障：确保volatile读之后的操作不会被重排序到volatile读之前

在x86架构下，JVM只需要在volatile写操作后插入StoreLoad屏障，因为x86处理器不会对读-读、读-写和写-写操作做重排序。

4.3 volatile的使用场景

适合使用volatile的场景包括：

1. 状态标志位（如shutdown标志）
2. 一次性安全发布（如双重检查锁定模式）
3. 独立观察（定期发布观察结果供程序使用）
4. 开销较低的读-写锁策略

// 典型的使用volatile的场景 public class ShutdownRequested { private volatile boolean shutdownRequested; public void shutdown() { shutdownRequested = true; } public void doWork() { while (!shutdownRequested) { // 执行任务 } } }

5. 同步机制与JMM实现

5.1 synchronized的实现原理

synchronized同步块在JVM中的实现涉及以下关键机制：

1. 对象头Mark Word：每个Java对象都有一个对象头，其中包含锁状态信息
2. Monitor对象：每个对象都关联一个Monitor，用于管理线程的等待/通知机制
3. 锁升级过程：从无锁→偏向锁→轻量级锁→重量级锁的转换

在字节码层面，synchronized通过monitorenter和monitorexit指令实现：

// 源代码 public void syncMethod() { synchronized(this) { // 临界区代码 } } // 字节码等价表示 public void syncMethod(); Code: 0: aload_0 1: dup 2: astore_1 3: monitorenter // 进入同步块 4: aload_1 5: monitorexit // 正常退出同步块 6: goto 14 9: astore_2 10: aload_1 11: monitorexit // 异常退出同步块 12: aload_2 13: athrow 14: return

5.2 Lock接口的实现分析

与synchronized不同，java.util.concurrent.locks.Lock接口的实现类（如ReentrantLock）使用AQS（AbstractQueuedSynchronizer）实现同步：

1. CAS操作：通过Unsafe类提供的compareAndSwapInt等原子操作
2. CLH队列：将暂时获取不到锁的线程加入到队列中
3. 可中断获取：支持线程在等待锁的过程中响应中断

AQS内部维护一个volatile int state变量表示同步状态，配合LockSupport.park/unpark实现线程阻塞和唤醒。

5.3 锁的性能对比

在JDK1.6之后，synchronized经过优化（偏向锁、适应性自旋等）性能已经大幅提升。以下是典型场景下的性能对比：

在实际项目中，建议优先考虑synchronized，除非需要ReentrantLock的高级特性。

6. 双重检查锁定与单例模式

6.1 经典的双重检查问题

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; } }

这段代码在多线程环境下可能存在问题，因为instance = new Singleton()不是一个原子操作，它包含：

1. 分配内存空间
2. 初始化对象
3. 将instance指向分配的内存地址

由于指令重排序，可能导致步骤3在步骤2之前执行，此时其他线程可能访问到未完全初始化的对象。

6.2 正确的实现方式

解决方案有三种：

1. 使用volatile修饰instance

private static volatile Singleton instance;

2. 基于类初始化的解决方案（静态内部类）

public class Singleton { private static class Holder { static final Singleton INSTANCE = new Singleton(); } public static Singleton getInstance() { return Holder.INSTANCE; } }

3. 使用枚举实现单例（推荐方式）

public enum Singleton { INSTANCE; public void doSomething() { // 方法实现 } }

6.3 各方案对比

在实际开发中，枚举方式是最佳实践，它不仅能避免多线程同步问题，还能防止反序列化重新创建新的对象。

7. JMM在实际项目中的应用技巧

7.1 线程安全容器的选择

Java集合框架中，不同容器的线程安全保证级别不同：

1. 完全不可变对象：如Collections.emptyList()，绝对线程安全
2. 条件线程安全：如Hashtable、Vector（单个方法调用线程安全，但复合操作需要额外同步）
3. 并发容器：如ConcurrentHashMap、CopyOnWriteArrayList，设计用于高并发场景
4. 非线程安全容器：如ArrayList、HashMap，需要外部同步

对于读多写少的场景，CopyOnWriteArrayList是很好的选择，它的迭代器不会抛出ConcurrentModificationException：

List<String> list = new CopyOnWriteArrayList<>(); // 多线程可以安全地迭代和修改 list.add("item1"); for(String item : list) { list.add("newItem"); // 不会抛出异常 }

7.2 避免内存可见性问题的实践

1. 尽量使用不可变对象：final字段天然具有线程安全性
2. 优先使用并发工具类：如CountDownLatch、CyclicBarrier等
3. 谨慎发布对象：避免在构造方法中发布this引用
4. 使用线程封闭：如ThreadLocal或局部变量

一个常见的错误是在构造方法中启动线程：

public class ThisEscape { public ThisEscape(EventSource source) { source.registerListener( new EventListener() { public void onEvent(Event e) { doSomething(e); } }); // 其他初始化代码... } }

此时EventListener隐式持有ThisEscape的this引用，可能导致对象未完全构造就被使用。正确的做法是使用工厂方法：

public class SafeListener { private final EventListener listener; private SafeListener() { listener = new EventListener() { public void onEvent(Event e) { doSomething(e); } }; } public static SafeListener newInstance(EventSource source) { SafeListener safe = new SafeListener(); source.registerListener(safe.listener); return safe; } }

7.3 性能优化建议

1. 减小锁粒度：如ConcurrentHashMap的分段锁设计
2. 减少锁持有时间：只在必要的时候获取锁
3. 使用读写锁：如ReentrantReadWriteLock适用于读多写少场景
4. 避免锁嵌套：容易导致死锁
5. 考虑无锁算法：如CAS-based并发类

一个典型的锁优化示例：

// 优化前 - 粗粒度锁 public synchronized void processRequest(Request request) { // 处理请求 writeToDisk(request); // 耗时IO操作 } // 优化后 - 细粒度锁 public void processRequest(Request request) { // 快速处理部分 synchronized(this) { // 只同步必要部分 } writeToDisk(request); // 耗时操作放在锁外 }

8. JMM相关工具与诊断方法

8.1 内存可见性问题诊断

1. JConsole/VisualVM：监控线程状态和锁竞争情况
2. Java Mission Control：提供更详细的内存和线程分析
3. jstack：生成线程转储分析锁持有情况
4. JEP 188: Java Memory Model Tools：实验性的JMM验证工具

8.2 常见的并发问题模式

1. 数据竞争：多个线程同时访问共享数据且至少有一个是写操作
2. 死锁：线程互相等待对方持有的锁
3. 活锁：线程不断重试失败的操作
4. 资源耗尽：如线程池耗尽导致任务拒绝

使用jstack检测死锁的示例输出：

Found one Java-level deadlock: ============================= "Thread-1": waiting to lock monitor 0x00007f88e4003fc8 (object 0x000000076ab270c8, a java.lang.Object), which is held by "Thread-0" "Thread-0": waiting to lock monitor 0x00007f88e4004e18 (object 0x000000076ab270d8, a java.lang.Object), which is held by "Thread-1"

8.3 测试并发代码的方法

1. 压力测试：使用大量线程反复执行目标代码
2. 交错测试：通过Thread.yield()人为制造线程切换
3. 静态分析工具：如FindBugs、Coverity可以检测部分并发问题
4. 形式化验证：使用模型检查工具如Java PathFinder

一个简单的并发测试框架示例：

public class ConcurrentTest { static final int THREADS = Runtime.getRuntime().availableProcessors() * 2; static final ExecutorService pool = Executors.newFixedThreadPool(THREADS); public static void execute(Runnable task) throws InterruptedException { CountDownLatch start = new CountDownLatch(1); CountDownLatch end = new CountDownLatch(THREADS); for (int i = 0; i < THREADS; i++) { pool.execute(() -> { try { start.await(); task.run(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { end.countDown(); } }); } start.countDown(); // 所有线程同时开始 end.await(); // 等待所有线程完成 } }

9. JMM与新一代Java特性

9.1 Java 9+中的改进

1. VarHandle：提供对变量各种访问模式的低级别、高性能操作
2. Memory Order Mode：更细粒度的内存顺序控制
3. Fences：显式内存屏障API

VarHandle示例：

class Point { private int x; private static final VarHandle X; static { try { X = MethodHandles.lookup() .findVarHandle(Point.class, "x", int.class); } catch (ReflectiveOperationException e) { throw new Error(e); } } public void atomicIncrement() { X.getAndAdd(this, 1); // 原子性操作 } }

9.2 Project Loom的影响

虽然Project Loom主要关注轻量级线程（虚拟线程），但它对JMM也有影响：

1. 线程局部变量的语义变化：虚拟线程的ThreadLocal可能更轻量
2. 锁的实现优化：synchronized在虚拟线程上的行为可能不同
3. 内存可见性保证：虚拟线程切换不会影响JMM的基本保证

9.3 值类型（Valhalla项目）

未来Java可能引入值类型，这将带来新的内存模型考虑：

1. 扁平化存储：值类型可能直接嵌入到对象中，减少间接引用
2. 内存布局控制：对缓存友好的数据排列
3. 原子性粒度：对值类型字段的原子更新语义

10. 常见误区与最佳实践

10.1 典型理解错误

1. volatile能保证原子性：实际上它只能保证单次读/写的原子性，不能保证复合操作
2. synchronized影响JMM所有内存：实际上它只保证同步块内变量的可见性
3. final字段不需要同步：虽然final字段有特殊的初始化保证，但引用对象内部状态仍可能需要同步
4. 无竞争时同步开销可忽略：现代JVM已优化，但同步仍有一定开销

10.2 性能陷阱

1. 过度同步：同步范围过大或使用不必要的同步
2. 对象池滥用：现代GC已高度优化，对象池可能反而降低性能
3. 误用ThreadLocal：不清理ThreadLocal可能导致内存泄漏
4. 忽视缓存效应：伪共享（False Sharing）问题

检测伪共享的示例：

// 可能产生伪共享的代码 class Data { volatile long x; volatile long y; // 可能与x位于同一缓存行 } // 解决方案 - 缓存行填充 class PaddedData { volatile long x; long p1, p2, p3, p4, p5, p6, p7; // 填充 volatile long y; long p8, p9, p10, p11, p12, p13, p14; // 填充 }

10.3 最佳实践总结

1. 优先使用并发工具类：如ConcurrentHashMap、CountDownLatch等
2. 尽量减小同步范围：同步块越小越好
3. 考虑不可变性：final字段和不可变对象是最简单的线程安全方案
4. 文档化线程安全策略：明确说明类的线程安全级别
5. 避免过度优化：先保证正确性，再考虑性能优化

在大型项目中，我通常会建立以下并发编程规范：

• 所有共享变量访问必须同步
• 优先使用java.util.concurrent中的类
• 避免在同步块中调用外部方法
• 使用@GuardedBy注解标注被保护的字段
• 定期进行并发代码审查