JMM通过抽象规则、关键字语义和内存屏障，在硬件缓存不一致前提下保障并发代码行为可预期；它定义主内存与工作内存模型，规定volatile写读插入屏障确保可见性与有序性，synchronized实现全量刷新与完整屏障，happens-before提供最小安全契约。

JMM 不是直接“解决”缓存不一致，而是通过抽象规则 + 关键字语义 + 内存屏障，让程序员能在硬件不可靠的前提下写出行为可预期的并发代码。它不消除 MESI、Store Buffer 或重排序，而是定义在哪些点必须强制同步，从而绕过底层弱一致性带来的不确定性。

主内存与工作内存的抽象隔离

每个线程操作的不是物理内存，也不是某个核的 L1 缓存，而是 JMM 定义的“工作内存”——这是对 CPU 缓存 + 寄存器的逻辑封装。所有共享变量初始都存在“主内存”（对应 RAM 抽象），线程读写前必须先拷贝副本到自己的工作内存。这个模型把缓存不一致问题显式暴露出来：你写的值没刷回主内存，别人就看不到。

关键约束：

• 线程不能直接读写主内存，必须经由工作内存中转
• 线程间无法访问彼此的工作内存，通信只能通过主内存完成
• 只有特定动作（如 volatile 写、synchronized 释放锁、线程 start/join）才触发工作内存与主内存的同步

volatile：用内存屏障驯服 Store Buffer

普通变量写入可能卡在 CPU 的 Store Buffer 中，迟迟不发往其他核。volatile 写操作会插入 StoreLoad 屏障（x86 下表现为 lock addl 指令），强制清空当前核的 Store Buffer，并等待所有失效请求被处理完毕。volatile 读则插入 LoadLoad 和 LoadStore 屏障，防止后续读写被重排到它前面。

这使得 volatile 变量具备两个效果：

• 写后立即对其他线程可见（绕过 Store Buffer 延迟）
• 禁止编译器和 CPU 对 volatile 读写做重排序（保障有序性）

注意：它只管单个变量的读写，不保证复合操作原子性（比如 i++ 仍是三步）。

Java调试

通过 JDWP 实现 Java 远程调试：连接远程 JVM、设置断点、单步执行代码、查看变量值、获取调用栈。适用于需要调试远程 Java 应用、排查运行时状态、追踪代码执行流程的场景。 术语注解 JDWP：Java Debug Wire Protocol，Java 调试有线协议（Java 远程调试底层通信协议） remote JVM：远程 Java 虚拟机 step through code：代码单步调试（步入 / 步过 / 步出调试） inspect variables：变量查看 / 变量检视 stac

下载

synchronized：全量刷新 + 完整屏障序列

退出 synchronized 块时，JVM 要求将本线程工作内存中所有修改过的变量（包括非 volatile 字段）全部刷新回主内存。背后是一套完整内存屏障序列：清空 Store Buffer、等待 Invalidation Queue 处理完成、广播 Invalidate 消息。

这意味着：

• 临界区内的所有写操作，在锁释放后对其他线程可见
• 进入锁时，会从主内存重新加载所有共享变量（避免使用旧缓存副本）
• 整个块内指令不会被重排序出临界区边界

相比 volatile，它开销更大，但提供原子性 + 可见性 + 有序性三位一体保障。

happens-before 规则：定义可见性的最小安全契约

它不规定硬件怎么做，只声明“如果 A happens-before B，那么 A 的结果对 B 可见”。常见规则包括：

• 程序顺序规则：同一线程中，按代码顺序，前一个操作 happens-before 后一个
• 监视器锁规则：unlock happens-before 后续对该锁的 lock
• volatile 规则：对 volatile 变量的写 happens-before 后续对该变量的读
• 线程启动/终止规则：Thread.start() happens-before 子线程任意动作；子线程所有动作 happens-before Thread.join() 返回

只要满足任一规则，JVM 就必须确保前操作的结果能被后操作观察到——无论底层是 x86 强模型还是 ARM 弱模型，JVM 都会插入必要屏障来兑现这个承诺。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南