17370845950

JMM是Java为解决多线程可见性、有序性、原子性问题制定的内存模型规则，规定变量存于主内存，线程操作需通过工作内存读写，volatile仅保证可见性与禁止重排序，不保证原子性与互斥，happens-before是判断操作可见性的逻辑先行关系。

JMM不是物理内存结构，而是Java为解决多线程下“变量改了别人看不见、执行顺序乱了、操作一半被插队”这三类问题，定的一套规则。 它不描述堆栈在哪，只规定：变量必须存在主内存；每个线程操作前得先拷一份到自己的工作内存；改完必须写回去，读之前得重新拉最新值——否则就可能卡死、算错、永远等不到结果。

主内存 vs 工作内存：为什么 ready = true 后另一个线程还在死循环？

这是最典型的可见性失效场景。线程A把 ready 写成 true，但只更新了自己工作内存，没刷回主内存；线程B一直从自己工作内存里读 ready，始终是 false。

• 主内存是共享的，存所有实例字段、静态字段、数组元素（volatile 和 final 字段也在此）
• 工作内存是线程私有的，不是JVM运行时数据区里的“栈”或“本地方法栈”，而是一个抽象概念，涵盖CPU缓存、寄存器、写缓冲区等硬件优化层
• 局部变量、方法参数不在JMM管理范围内——它们天生线程私有，不存在可见性问题
• 变量访问流程强制分步：read → load → use → assign → store → write，中间任何一步缺失或延迟，都可能导致不一致

volatile 怎么破局？它管什么、不管什么？

volatile 是JMM提供的轻量级同步机制，它直接作用于这8个原子操作中的 read/load 和 assign/stor

• ✅ 保证可见性：一个线程写 volatile 变量，其他线程后续读一定能见到新值（靠 volatile 变量规则的 happens-before 保障）
• ✅ 禁止指令重排序：编译器和CPU不会把对 volatile 变量的读写“挪”到临界区外（如单例双重检查锁中防止对象未构造完成就被引用）
• ❌ 不保证原子性：count++ 即使 count 是 volatile，仍是“读-改-写”三步，仍可能丢更新；要用 AtomicInteger 或 synchronized
• ❌ 不提供互斥：多个线程同时进 volatile 标记的临界区，不会排队，只是“大家都能看到最新状态”

happens-before 是什么？为什么它是JMM的“灵魂”？

它不是内存操作，而是一组**逻辑先行关系**，用来判断“操作A的结果是否对操作B可见”。只要满足任一 happens-before 规则，JMM就保证A对B可见且不重排序——开发者不用纠结底层怎么刷缓存，只看代码逻辑是否符合这些规则。

• 程序顺序规则：同一线程内，前面的语句 happens-before 后面的语句（即使被重排序，效果也等价）
• 监视器锁规则：unlock() happens-before 后续任意线程的 lock()
• volatile 变量规则：volatile 写 happens-before 后续任意线程对该变量的读
• 线程启动规则：Thread.start() happens-before 新线程的任意动作
• 传递性：若 A happens-before B，B happens-before C，则 A happens-before C

真正容易被忽略的是：happens-before 是**充分不必要条件**——不满足它不一定出错（比如碰巧缓存同步了），但一旦出错，几乎肯定是因为它断了。调试并发Bug时，第一反应不该是加日志，而是画出关键变量的 happens-before 链，看哪一环断了。