jmm 通过 happens-before 规则明确操作顺序，屏蔽底层干扰，确保共享变量的可见性、有序性与原子性；volatile 解决可见性与重排序，synchronized 提供三重保障，atomicxxx 适合无竞争场景，final 字段天然线程安全。
JMM 不是教你怎么加锁，而是帮你搞清楚“什么时候必须加锁、什么时候可以不加、加了又该怎么加才不拖慢性能”。它用一套可验证的规则，把硬件缓存、CPU重排序、线程私有副本这些底层干扰屏蔽掉，让你写的并发逻辑既正确又轻量。
理解主内存与工作内存的分工
所有共享变量（实例字段、静态字段、数组元素）都存在主内存里；每个线程操作前，先从主内存拷一份到自己的工作内存。线程读写只在工作内存发生，改完再同步回主内存——这个“中间层”就是可见性问题的根源。
- 局部变量和方法参数不在 JMM 管辖范围，因为它们天然线程私有，无需同步
- 如果多个线程频繁读写同一个变量，但没做同步，很可能一个线程改了值，另一个线程还在用旧副本，根本看不到变化
- 不是所有变量都要同步：只对真正被多线程共享且可变的变量才需关注 JMM 规则
用 happens-before 明确操作顺序边界
它不是时间先后，而是一套逻辑依赖关系。只要 A happens-before B，那么 A 的结果（比如变量赋值）对 B 就一定可见，且 A 的执行不会被重排序到 B 之后。
- volatile 写 → 后续 volatile 读：保证可见性和禁止重排序
- synchronized 解锁 → 后续 synchronized 加锁：进入临界区前能看到之前所有释放的数据
- Thread.start() → 新线程内任意操作：确保新线程能看见启动前主线程已写入的数据
- 避免靠“代码写在前面”来假设执行顺序，要用 HB 规则锚定关键点
按需选择同步强度，避免过度保护
JMM 本身不强制你用 synchronized，而是告诉你不同机制提供的保障等级：
- volatile：解决可见性 + 禁止重排序，但不保证复合操作（如 i++）的原子性
- synchronized / Lock：提供原子性 + 可见性 + 有序性三重保障，但有锁开销
- AtomicXXX 类：基于 CAS，在无竞争时比锁更轻量，适合计数器、状态标志等场景
- final 字段：初始化完成后不可变，天然满足 HB，发布对象时用它可免去额外同步
识别并消除隐式重排序风险
编译器或 CPU 可能为优化把两行代码调换顺序，只要单线程语义不变。但在多线程下，这可能破坏逻辑依赖。
- 典型陷阱：先设标志位再写数据，但重排序导致标志先被其他线程看到，而数据还没写完
- volatile 修饰标志位可禁止该重排序；synchronized 块内操作也天然有序
- 构造函数中不要让 this 引用逸出，否则其他线程可能看到未初始化完成的对象
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
