Java并发三大特性（可见性、原子性、有序性）根植于JMM：可见性由主内存/工作内存模型及volatile/synchronized/final保障；原子性取决于操作是否不可分，volatile不保证复合操作原子性；有序性通过happens-before规则和内存屏障约束。
Java 并发编程的三大特性——可见性、原子性、有序性——不是孤立的概念，而是根植于 Java 内存模型（JMM）这一底层规范中。脱离 JMM 谈三大特性，容易停留在“记关键字”层面；只有把它们和主内存、工作内存、读写交互、重排序等机制串起来，才能真正理解 为什么 volatile 能保证可见性和有序性却不能保证原子性，为什么 synchronized 既能锁住临界区又能刷新缓存，为什么 i++ 在多线程下总是出错。
从 JMM 的“主内存-工作内存”结构理解可见性
JMM 规定：所有共享变量都存在主内存中，每个线程有自己的工作内存（可类比 CPU 缓存），线程对变量的所有操作（读、写、计算）都发生在工作内存里，再同步到主内存。这就带来一个关键问题——线程 A 修改了变量，但还没写回主内存，线程 B 仍从自己缓存中读旧值。
- volatile 关键字强制每次读取都从主内存加载，每次写入都立即刷回主内存，绕过工作内存缓存
- synchronized 块结束时，会把工作内存中所有共享变量的最新值刷新到主内存；进入时，会把主内存中变量值重新读入工作内存
- final 字段在构造器完成时即对其他线程可见，这是 JMM 对不可变对象的特殊保障
用“操作原子性”和“指令重排边界”把握原子性与有序性
JMM 定义了 8 种底层原子操作（read、load、assign、use、store、write 等），但这些操作对开发者是透明的。我们看到的“非原子行为”，本质是多个原子操作被拆开执行，中间可能插入其他线程的操作或被重排序。
- a++ 包含 read→use→assign→store→write 五步，任意一步被打断都会导致结果丢失；而 int a = 1 是单次 assign+write，天然原子
- volatile 写之后插入 StoreStore 和 StoreLoad 屏障，禁止其后的普通读写重排到它前面；volatile 读之前插入 LoadLoad 和 LoadStore 屏障，禁止其前的普通读写重排到它后面
- synchronized 块内语句在本线程看来是顺序执行的（串行语义），且加锁与解锁构成 happens-before 关系，天然约束跨线程的执行顺序
以 happens-before 规则为线索统一三大特性
happens-before 不是物理时间先后，而是 JMM 定义的“内存操作可见性契约”。只要满足任一 happens-before 规则，前一个操作的结果就对后一个操作可见，且不会被重排序破坏。
立即学习“Java免费学习笔记（深入）”；
- 程序顺序规则：同一线程中，按代码顺序，前面的操作 happens-before 后面的操作 → 保障单线程内的有序性
- 监视器锁规则：unlock 操作 happens-before 后续对同一锁的 lock 操作 → 解锁时刷新变量，加锁时重载变量，同时约束顺序
- volatile 规则：对 volatile 变量的写操作 happens-before 后续对该变量的读操作 → 直接支撑可见性 + 有限有序性
- 线程启动/终止规则、传递性等进一步串联起跨线程的数据流
避开常见认知误区
很多并发 bug 正是源于对三大特性与 JMM 关系的模糊：
- 误以为 volatile 能防止 i++ 竞争：它能保证 flag 读写可见，但不能把 i++ 这个三步操作变成一个不可分割的整体
- 误以为 synchronized 只是“让代码慢下来”：它实际触发了工作内存与主内存的双向同步，并建立强 happens-before 链
- 忽略 final 字段的内存语义：final 域在构造器结束时对其他线程可见，这是 JMM 为安全发布对象提供的轻量级保证
