Java内存模型（JMM）是定义多线程下可见性、有序性和原子性的抽象规范，非JVM内存结构；它通过主内存与工作内存（虚构概念）描述线程交互，volatile靠内存屏障实现可见性与禁止重排序但不保证原子性，synchronized基于happens-before保证锁释放前修改对后续获取该锁的线程可见，final字段在正确构造前提下提供初始化安全性。
Java内存模型不是JVM内存结构
很多人一看到“Java内存模型”就去翻JVM堆、栈、方法区的图，这是错的。JMM（Java Memory Model）是抽象的并发规范，不对应任何物理内存布局，它只定义volatile、synchronized、final等关键字在多线程下如何保证可见性、有序性和原子性。
主内存和工作内存也不是“主存 vs CPU缓存”的直译——它们是JMM为描述线程间交互虚构的概念：所有变量都存在主内存；每个线程有自己的工作内存（可理解为寄存器+高速缓存的组合效果），线程对变量的所有操作（读、赋值）必须发生在工作内存中，不能直接读写主内存。
- 工作内存不是JVM运行时数据区里的“虚拟机栈”或“本地方法栈”，它不存储对象实例，只保存该线程用到的变量副本
- 变量包括实例字段、静态字段、构成数组对象的元素，但不包括局部变量（它们在线程私有栈帧里，天然线程安全）
-
long和double的非原子性读写问题，在JMM中被明确要求：JVM必须保证它们的读写是原子的（即不允许半个long被另一个线程看到），但早期某些32位JVM实现没遵守
volatile怎么触发主内存与工作内存同步
volatile是JMM里最轻量级的同步机制，但它只解决可见性和禁止重排序，不保证原子性。它的语义不是“每次读都从主内存拉”，也不是“每次写都立刻刷回主内存”，而是通过插入内存屏障（Memory Barrier）来约束编译器和CPU的行为。
- 写一个
volatile变量时，JMM会强制把该线程工作内存中所有先前的写操作（包括非volatile变量）都刷新到主内存（StoreStore屏障） - 读一个
volatile变量时，JMM会强制该线程丢弃工作内存中该变量的旧值，并从主内存重新读取最新值（LoadLoad + LoadStore屏障） - 禁止指令重排序：编译器不会把volatile读/写操作与它前后的普通读写重排序（但volatile读和volatile写之间仍可能重排）
- 常见误用：
volatile int counter = 0;然后多个线程执行counter++——这仍是线程不安全的，因为++包含读-改-写三步，volatile无法保证这三步的原子性
synchronized如何建立happens-before关系
synchronized块的进入和退出，构成了JMM中最重要的happens-before规则之一：解锁操作happens-before后续对同一锁的加锁操作。这意味着，线程A释放锁前对共享变量的所有修改，对之后获得该锁的线程B是可见的。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 不是“synchronized代码块执行完才刷主内存”，而是在
monitorexit指令执行时，强制将工作内存中该锁保护的所有变量刷新回主内存 - 不是“synchronized会清空工作内存”，而是线程B在获取锁后，会依据happens-before规则，确保能看到A写入的最新值（JVM可能通过缓存一致性协议或显式内存屏障实现）
- 锁粗化、锁消除等JIT优化不会破坏happens-before语义——这是JVM必须守住的底线
- 注意锁对象本身要是同一个实例：用
this、类名.class、或显式声明的private final Object lock = new Object()；别用new Object()临时对象，那根本不是同一把锁
final字段的内存语义常被低估
final字段不只是语法限制“不可变”，它在JMM中有特殊保障：只要构造器正确完成（没有this逃逸），其他线程就能看到该final字段的正确初始化值，无需额外同步。
- 原理是：JMM禁止把final字段的写操作与构造器中的其他写操作重排序到构造器之外；同时禁止把final字段的读操作与后续读操作重排序到读取该对象引用之前
- 关键前提是“正确构造”：如果构造器里把
this引用泄露出去（比如启动新线程、注册监听器、传给static集合），其他线程可能看到final字段未初始化或默认值（0、null） - 这个语义仅适用于final引用类型字段的**引用本身**，不保证其指向对象内部状态的可见性——例如
final List<string> list = new ArrayList()</string>，list引用不可变，但list.add()的操作仍需同步 - String、Integer等不可变类的final字段，天然享受这一保障；但自己写的类，必须确保构造过程无this逃逸
真正容易被忽略的是：JMM的这些规则，只有在多线程访问**共享可变状态**时才生效。单线程、或变量只在一个线程内使用，连“主内存”“工作内存”的概念都不需要动。很多性能问题其实源于过早抽象，而不是没搞懂JMM。
