Java内存模型（JMM）是定义volatile、synchronized、final等关键字在多线程下如何约束读写、可见性与重排序的抽象规范，不描述内存布局，也不解决“怎么写”，只决定“如何执行”。
Java内存模型（JMM）不是虚拟机内存布局的描述，而是定义了多线程环境下，volatile、synchronized、final 等关键字如何约束变量读写行为、线程间可见性与操作重排序的抽象规范。它不解决“怎么写并发代码”，而是决定“你写的并发代码在JVM上到底按什么规则执行”。
为什么 synchronized 能保证可见性和原子性
synchronized 的语义由 JMM 严格规定：进入同步块前，线程必须从主内存刷新共享变量最新值；退出时，必须将修改后的变量强制写回主内存。这中间还隐含一个“锁释放-获取”的 happens-before 关系。
常见错误是以为只要加了 synchronized 就万事大吉——其实如果同步对象不一致（比如用 this 锁实例方法，却用 new Object() 锁另一段逻辑），JMM 不会建立 happens-before，变量修改依然不可见。
- 多个线程必须竞争同一把锁，才能触发 JMM 规定的内存屏障插入点
- 锁粒度太粗会降低并发度；太细（如每个字段用不同锁）可能破坏一致性，JMM 不帮你校验逻辑正确性
- 同步块内发生异常时，锁仍会正常释放，JMM 行为不受影响
volatile 变量的读写到底禁止了什么重排序
volatile 写操作禁止其后的任意读写操作被重排序到它前面；volatile 读操作禁止其前的任意读写操作被重排序到它后面。但它不提供原子性——i++ 这种复合操作即使作用于 volatile int i，依然线程不安全。
立即学习“Java免费学习笔记（深入）”；
典型误用是拿 volatile boolean flag 控制线程启停，却在 flag 设为 true 后才初始化相关资源。JMM 允许编译器或 CPU 把资源初始化指令重排到 flag 写入之前，导致其他线程看到 flag 已就绪，但资源仍是未初始化状态。
- 必须配合“写后读”模式使用：先完成所有依赖数据的写入，再写
volatile标志 - 不能用于需要原子性的场景，比如计数器、状态机跳转
- 在 x86 平台上，
volatile读几乎无开销，写会插入lock addl $0x0,(%rsp)类似指令，但 ARM/PowerPC 上成本更高
final 字段的内存语义常被忽略
构造器中对 final 字段的写入，在对象构造完成的那一刻，JMM 保证该写入对其他线程可见——哪怕这个对象被“逸出”（如发布到静态集合中），只要引用本身被正确发布（如通过 volatile 引用或锁保护），final 字段就不会看到默认值。
但注意：这个保障只对 final 字段本身有效，对其引用的对象内部状态不做任何承诺。例如 final List<string> list = new ArrayList()</string>，JMM 不阻止其他线程看到空列表，也不阻止后续往里面 add 元素时的竞态。
- 必须在构造器内完成
final字段赋值，且不能在构造过程中泄露this - 若字段类型是可变对象，仍需额外同步来保护其内部状态
- 反序列化创建的对象不享受此保障，因为绕过了构造器
JMM 的复杂性不在语法，而在它把硬件内存模型、编译器优化、JVM 实现细节全收束到一套可验证的语义规则里。写并发代码时，真正容易出问题的从来不是“没加锁”，而是“加了锁但锁不住该锁的变量”，或者“以为 volatile 能兜底，其实只是漏掉了更深层的数据依赖”。
