「JVM」并发编程基石：Java 内存模型（JMM）与 Synchronized 锁升级原理

引言：别把"内存结构"和"内存模型"搞混了！

面试官说"讲讲 JMM"，你开口就是"堆栈方法区"，面试官直接让你回家等通知。
正解： JVM 内存结构（堆栈）是物理空间的划分；而 JMM（Java Memory Model）是一套"规矩"，它规定了多线程在读写共享变量时，如何保证数据的准确性。这套规矩的核心就是解决多线程的三座大山：原子性、可见性、有序性。

一、多线程的"三座大山"（并发 BUG 的万恶之源）

原子性（防插队）：

现象： 两个线程各执行 5000 次 i++ 和 i--，结果竟然不是 0？
- 本质： 一句 i++ 在 CPU 眼里是三步（读、加、写）。单线程没问题，多线程下指令一交错，数据就乱套了。
- ****底层推演（撕开伪装的单步操作）： 在高级语言里，i++ 看似是一行代码，但在 CPU 和 JVM 字节码眼里，它是个彻头彻尾的"三步曲"：
  1. 读（getstatic）： 从主内存把 i 的值读到 CPU 寄存器（或者线程的工作内存）。
  2. 加（iadd）： 在寄存器里对这个值加 1。
  3. 写（putstatic）： 把计算后的新值写回主内存。

如果在执行完第 1 步或第 2 步时，操作系统的时间片耗尽（发生上下文切换） ，你的线程就会被无情挂起。此时另一个线程趁虚而入，把自己的 i++ 跑完了。等你再次醒来，继续执行第 3 步的"写"操作时，就会把别人辛苦计算的结果直接覆盖掉。这就叫指令交错，也就是丧失了原子性。

🔥 ** 面试陷阱： "既然多线程下 **i++** 不安全，那如果我给 **i** 加上 **volatile** 关键字，是不是就彻底安全了？"**
**完美回答： **绝对不能！这是一个极具迷惑性的初级陷阱。volatile 只能保证可见性（别的线程改了你能立刻看到）和有序性，但它绝对无法保证原子性。volatile 无法阻止多线程在"读-算-写"这三步中发生上下文切换。要解决这个问题，必须上重武器（如 synchronized 锁）或者用底层的 CAS（如 AtomicInteger 原子类）。

🛡️ 真实业务防坑指南

业务踩坑场景（外卖库存超卖）： ** 在类似"苍穹外卖"这样有商品秒杀或限量抢购的系统中，如果库存扣减逻辑（**stock = stock - 1**）没有保证原子性。中午 12 点流量洪峰打过来，100 个请求同时读取到库存剩余 1 份，分别在自己的线程里减 1 并写回数据库。最终的结果是：一份饭卖给了 100 个人，客诉爆炸，直接 P0 级线上事故。**
防坑指南：绝不能在应用层做简单的减法。应当依赖数据库层面的原子锁（ **UPDATE stock SET count = count - 1 WHERE id = ? AND count > 0**），或者在 Redis 中使用 Lua 脚本/分布式锁来保证这一系列扣减动作的原子性。

2.可见性（防瞎子）：

直观现象： 主线程已经把控制开关 run 改成了 false，但子线程却像个瞎子一样视而不见，还在里面疯狂死循环，导致系统 CPU 飙升无法退出。
底层推演（JIT 与 CPU 缓存的副作用）： 为了弥补 CPU 极速运算和内存龟速读写之间的巨大落差，现代 CPU 引入了 L1/L2/L3 多级缓存。映射到 JVM 中，这就是所谓的"工作内存"。

当子线程在一个 while(run) 循环里频繁读取变量时，JVM 的 JIT（即时编译器） 会极其聪明地做个优化：它觉得每次去主内存读太慢了，直接把 run 的值"拷贝"一份放在自己的工作内存（或者寄存器）里。此时，哪怕主线程在主内存中把 run 改成了 false，子线程也根本不知道，它依然在痴情地读取自己缓存里的旧值（历史残影）。

🔥 ** 追问：** "如果我死活不加 volatile 修饰 run 变量，难道那个子线程就一辈子死循环，永远看不到主线程的修改了吗？"
完美回答： 不一定！如果在 while 循环内部有 System.out.println()、Thread.sleep() 或者进入了某个 synchronized 代码块，循环是有极大可能停下来的。因为这些重量级操作会触发线程的上下文切换，或者遇到内存屏障（Memory Barrier）。此时，JVM 会被迫清空当前线程的工作内存，去主内存重新加载最新数据，从而"阴差阳错"地恢复了可见性。但作为资深开发，绝不能依赖这种玄学特性来写并发代码。

🛡️** 真实业务防坑指南**

业务踩坑场景（热更新配置失效）： 在高并发微服务中，我们经常从 Nacos 或 Apollo 拉取动态配置（例如：boolean isDiscountActive 开启促销打折）。如果不小心漏加了 volatile，当运营在后台紧急关闭打折开关时，某些处理订单的机器上的线程由于缓存原因，依然读取的是 true。结果就是：部分机器继续按打折价结账，公司疯狂流失营收，查日志却死活找不出代码逻辑的毛病。

3.有序性（防乱排）：

直观现象： 代码明明写着先执行 A，再执行 B。结果在多线程极端并发下，程序居然先执行了 B。

**底层推演（为了榨干性能的极致重排）： 编译器（如 Javac）和底层的 CPU 在执行指令时，为了最大化流水线的吞吐量，会自动对那些"看起来没有因果关联"**的指令进行位置互换（Instruction Reordering）。单线程下这招叫性能飞跃，多线程下这就叫"埋雷"。

最经典的灾难就是 DCL（Double-Checked Locking）单例模式。 当执行 INSTANCE = new Singleton(); 时，底层其实分为三步：

分配内存空间。
调用构造函数，初始化对象内部的成员变量。
将 INSTANCE 引用指向刚分配的内存地址。 重点来了： 第 2 步和第 3 步在 CPU 看来没有先后依赖关系，极容易被重排为 1 -> 3 -> 2。如果是这种顺序，发生线程切换时，另一个线程一判断 INSTANCE != null（此时第 3 步刚执行完），就兴冲冲地拿着这个**"还没初始化完毕的半成品对象"**去用了，直接引发空指针异常！

****面试手写题： "请在白板上写一个绝对线程安全的 DCL 单例，并解释为什么你要加两次 if 检查？最后那个 volatile 到底起什么作用？"
完美回答：

plain 复制代码

public class Singleton {
    // 坑点3：必须加 volatile 关键字（防指令重排）
    private static volatile Singleton INSTANCE = null;

    // 私有化构造方法，防止外部直接 new
    private Singleton() {
        // 这里可能会有很多耗时的初始化操作...
    }

    public static Singleton getInstance() {
        // 坑点1：第一次检查（在外层）
        if (INSTANCE == null) {
            // 加一把类级别的重量级锁
            synchronized (Singleton.class) {
                // 坑点2：第二次检查（在锁内部）
                if (INSTANCE == null) {
                    INSTANCE = new Singleton();
                }
            }
        }
        return INSTANCE;
    }
}

++第一次 check (在外层)：纯粹为了系统性能，拦住 99% 的无用排队++
- 假设没有外层 if (INSTANCE == null)，那么代码一进来就是 synchronized (Singleton.class)。你想想，单例模式整个系统运行期间只需要创建一次 。但如果并发很高，每天有 100 万次请求来获取这个单例。那这意味着，除了第 1 次是真的进去创建对象，剩下的 999,999 次，明明对象已经存在了，各个线程居然还要排着队、互相阻塞、抢锁、释放锁 ，只为了进去拿一个现成的对象！这会让高并发系统的性能直接暴跌。
- 加上第一层 if 后： 当那 999,999 个请求过来时，一看 INSTANCE 已经不是 null 了，连锁都不用碰，直接 return INSTANCE 走人。速度快到飞起。
1. ++第二次 check (在同步块内)：++ ++纯粹为了线程安全，防止并发创建出多个单例++
- 假设此时系统刚启动，INSTANCE 确实是 null。线程 A 和线程 B 同时到达外层，同时发现 INSTANCE == null，于是都准备往下走。但是门太窄，线程 A 抢到了锁，进去了。线程 B 只能在门外（同步块外）干等着。线程 A 在里面高高兴兴地执行了 INSTANCE = new Singleton();，创建完毕，释放锁出门了。此时，一直在门外等的线程 B 终于拿到了锁，冲了进去。致命时刻：如果里面没有第二层 if (INSTANCE == null) 拦着，线程 B 根本不知道 A 已经建好房子了，它会闭着眼睛再执行一次INSTANCE = new Singleton();！结果就是，单例被破坏，内存里出现了两个不同的对象。
1. volatile++的作用：++ ++就是为了++ ++禁止底层指令重排++ ++！++
- 在修饰了 volatile 之后，JVM 会在字节码中插入一道"内存屏障"，强制要求 CPU 必须严格按照 1 -> 2 -> 3 的顺序执行实例化，彻底杜绝别的线程拿到半成品对象。

🛡️** 真实业务防坑指南**

业务踩坑场景（连接池懒加载雪崩）： 后端项目中经常懒加载一些重量级的资源组件，比如 Redis 分布式锁工具类或复杂的第三方 RPC 客户端。如果在初始化时发生了指令重排，并发的请求就会拿到一个"外壳存在，但内部连接尚未建立"的伪劣连接池。第一批冲进来的几百个订单请求会在调用 redis.get() 时瞬间引发大面积 NullPointerException 或连接异常，直接导致服务短暂不可用。

二、破局利器一：轻巧灵动的 volatile 与规矩 happens-before

++可见性的救星：volatile++
- 前面我们说过，线程为了图快，会把变量缓存在自己的"工作内存"（CPU L1/L2 缓存）里。当你给一个变量加上 volatile 后，JVM 会在底层生成一段特殊的汇编指令（带有 Lock 前缀）。这个指令相当于贴了一张"大字报"：

写操作时： 只要你改了 volatile 变量，CPU 必须立刻把新值强制刷新回主内存 ，并且通过底层的缓存一致性协议（如 MESI），通知其他所有线程："你们工作内存里的这个变量已经作废了（Invalid）！"
读操作时： 其他线程再去读这个变量时，发现缓存失效，只能老老实实去主内存里重新拉取最新值。

++有序性的保安：内存屏障（Memory Barrier）禁用指令重排++
- 还记得上面导致 DCL 单例模式爆炸的"指令重排"吗？volatile 怎么防止 CPU 瞎排顺序？ JVM 的做法是在编译后的汇编指令中，硬塞入一块叫做**"内存屏障"**的东西（你可以理解为路障）。

StoreStore 屏障 / LoadLoad 屏障等： 在 volatile 变量写之前/后，或者读之前/后，竖起一面墙。CPU 执行到这里时，一看前面有屏障，必须等屏障前面的所有指令执行完，才能执行屏障后面的指令。彻底封死了 CPU 和编译器擅自换座位的可能。

++终极契约：happens-before 原则++
- 日常开发写代码，不可能天天盯着底层的汇编指令和内存屏障看。于是 JVM 给开发者提供了一套"人类能看懂"的业务契约------happens-before。

大白话契约： 只要 A 动作 happens-before（先行发生于） B 动作，那么 JVM 就向你发誓：A 动作产生的影响，B 一定能看到！
比如："对一个 volatile 变量的写操作，happens-before 于后续对这个变量的读操作"。这就意味着，只要你写完了，我担保别人一定能读到最新的，底层怎么加屏障你不用管。这就大大降低了我们写并发代码的脑力负担。
陷阱题： "既然 volatile 能保证可见性，那 volatile int count = 0; 然后多线程执行 count++，能保证线程安全吗？为什么？"
完美回答： 不能保证！这是一个经典的偷换概念陷阱。volatile 只保证你每次去主内存读的时候，拿到的是最新值。但是 count++ 是个复合操作（读、算、写）。线程 A 读到了最新的值 10，准备加 1 时被切走了；线程 B 也读到了 10，变成了 11 写回去；线程 A 醒来后，把手里算好的 11 也写回去。可见性≠原子性，结果依然会被覆盖丢失。

三、破局利器二：乐观派的坚守 ------ CAS 与原子类

如果说 synchronized 是防贼一样防着其他线程，那 CAS 的核心哲学就是"和气生财"------大家都不锁门，谁手快谁赢，手慢的重头再来。

🔴 底层原理剖析：一场不锁门的"暗号核对"游戏

悲观锁（synchronized）的痛点： 只要加上 synchronized，哪怕实际上只有你一个人在访问，JVM 也会老老实实地去申请操作系统的互斥锁（Mutex）。一旦发生锁竞争，抢不到的线程就会被挂起（阻塞） ，等锁释放了还要被唤醒。这种用户态到内核态的频繁切换，极其消耗 CPU 性能。

乐观锁（CAS）的破局之道： CAS 全称是 Compare And Swap（比较并交换）。它认为："大概率没人和我抢，我不锁门，直接改。但在写回内存的最后一刻，我要对一下'暗号'。"

CAS 的执行需要三个关键变量：

V（内存真实地址）： 变量现在在主内存里的实际位置。
A（预期旧值/暗号）： 我刚开始干活时，从主内存读出来的那个旧值。
B（新值）： 我经过计算后，想要写回去的结果。

底层推演全过程（以 i++ 为例）：

线程 1 从主内存 V 读到旧值 A = 0，然后在自己的工作内存里算出新值 B = 1。
准备写回主内存时，发起 CAS 灵魂拷问："现在的 V 里面，还是我当初看到的 A 吗？"
情况一（没人捣乱）： 发现 V 确实还是 0。暗号对上了！直接把 V 替换成 B (1)，成功下班。
情况二（有人插队）： 此时线程 2 已经捷足先登，把 V 改成了 5。线程 1 一对比，发现 V(5) != A(0)。暗号不对！说明数据脏了。
自旋重试（Spin）： 线程 1 不会去睡觉（不阻塞），而是立刻重新去读现在的旧值（A变成5），重新算新值（B变成6），再次尝试比对。在 while(true) 循环里疯狂打转，直到成功为止。

底层基石 **Unsafe** 类与原子级指令： 你可能会问："对比和交换明明是两步，万一在对比完、还没来得及交换的瞬间，被别的线程改了怎么办？" 这正是 Java 的聪明之处。Java 作为一个跑在虚拟机里的安全语言，是不能直接操作底层内存地址的。但它开了一个名叫 Unsafe 的后门（这个类里面的方法几乎都是 native 的）。通过 Unsafe，Java 直接呼叫了底层操作系统的 C++ 代码，最终转化为 CPU 层面的一条汇编指令（比如 x86 架构下的 lock cmpxchg）。CPU 在硬件层面上保证了这条指令的绝对原子性，只要执行，期间连总线或缓存行都会被锁住，绝不给任何线程插队的机会！

开箱即用的封装：Atomic 原子类（以 AtomicInteger 为例） JDK 的开发者怕你直接用 Unsafe 把内存搞崩，于是贴心地封装了 java.util.concurrent.atomic 包。以 AtomicInteger 为例，它为什么既安全又不会阻塞线程？它的底层源码其实只有两行核心逻辑：

内部维护了一个被 volatile 修饰的 value 变量（保证了每次读取都是最新值）。
在做增减操作时，把 Unsafe.compareAndSwapInt 包在一个 do-while 循环里疯狂自旋，直到更新成功。这就是 CAS + volatile 强强联手的无锁并发巅峰。

大厂面试提问

题 1："CAS 听起来完美无缺，它有什么致命的逻辑漏洞？听说过 ABA 问题吗？"

完美破局回答： CAS 最大的盲区在于它"只看结果，不看过程"。假设线程 1 读到旧值是 A，随后被系统挂起。线程 2 冲进来把 A 改成了 B，然后又偷偷摸摸改回了 A。当线程 1 醒来执行 CAS 比对时，发现内存里的值还是 A，它就会天真地以为"没人动过"，然后稀里糊涂地更新成功了。这就是经典的 ABA 问题 。
- 解决方案： 引入版本号（Version）或时间戳。每次修改不仅改值，还要让版本号加 1（A(v1) -> B(v2) -> A(v3)）。JUC 中专门提供了 AtomicStampedReference 类，比对时同时校验"值"和"版本戳"，完美破解此局。

题 2："如果外卖系统大促，并发量达到每秒几万次，这时候所有线程都在用 **AtomicInteger** 进行 CAS 自旋，会发生什么后果？"

完美破局回答： 会引发灾难性的 CPU 空转风暴 。当竞争极其激烈时，大部分线程的 CAS 操作都会失败，它们会在 while(true) 循环里无休止地空转重试，白白烧毁 CPU 资源（导致 CPU 使用率瞬间飙到 100%）。
- 解决方案： 在 JDK 8 之后，面对这种极端高并发的计数场景，强烈推荐使用 LongAdder 代替 AtomicInteger。LongAdder 采用了"分散热点"的精妙思想：把一个单一的共享变量，拆散成一个 Cell[] 数组。多个线程各自去 CAS 自己对应的坑位，互不干扰；最后取值时，把数组里的所有值累加即可。直接把高并发瓶颈彻底击碎！

四、破局利器三：老大哥的蜕变 ------ synchronized 与锁升级

很多人一听到 synchronized 就觉得"重、慢、会阻塞"。其实，现在的 synchronized 极其聪明，它有一套极其丝滑的**"看人下菜碟"**机制（锁升级）。

1. 🔴 底层原理剖析：一场发生在"对象头"里的无间道

在讲锁升级之前，我们必须先认识 JVM 里极其重要的一块自留地：对象头（Object Header）里的 Mark Word。你可以把 Mark Word 理解为每个对象随身携带的**"动态身份证"**。锁升级的过程，其实就是这张身份证不断被涂改的过程。

阶段一：无锁状态（岁月静好）

对象刚被 new 出来，没人抢它。它的身份证上干干净净，只写着自己的基本信息（比如 HashCode、分代年龄）。

阶段二：偏向锁（霸道总裁的"专属刺青"）

业务场景： 很多时候，虽然代码里写了同步块 synchronized(obj)，但实际上从头到尾都只有【同一个线程】在反复进入这个代码块（比如单线程环境下的 StringBuffer.append）。
底层推演： JVM 觉得每次都去加锁释放锁太蠢了。于是，当线程 A 第一次进来时，JVM 直接用 CAS 操作，把线程 A 的 Thread ID 像刺青一样死死地刻在对象的 Mark Word 里。
效果： 以后线程 A 再来，只要拿自己的 ID 和对象头上的"刺青"对一下，发现是自己人，直接长驱直入！全程没有任何加锁、释放锁的开销，性能无限接近无锁。

阶段三：轻量级锁（文明人的"课本占座"）

业务场景： 这时候【线程 B】来了！它看到对象头上的刺青是 A，知道有别人来过。但是，A 和 B 错开了运行时间（比如 A 刚走，B 才来，两人没当面打起来）。
底层推演： 既然出现了多线程，偏向锁的规矩就被打破了（撤销偏向）。JVM 会指挥线程 B 在自己的线程栈里腾出一个空间，叫 Lock Record（锁记录）。然后，线程 B 会用 CAS 操作，把对象头里的 Mark Word **"偷换"**成指向自己 Lock Record 的指针。
效果： 这就像大学自习室的**"课本占座"**。B 放了一本书在桌上（CAS 成功），A 回来一看桌上有书，知道有人在用，A 就在旁边稍微等一下（自旋）。大家都是文明人，不惊动操作系统，全在用户态通过 CAS 解决。

阶段四：重量级锁（撕破脸皮，呼叫保安 Monitor）

业务场景： 极其惨烈！A 和 B 同时冲进自习室抢同一个座位。两人同时用 CAS 尝试"课本占座"，结果 A 抢赢了，B 失败了。B 恼羞成怒，原地转了几圈（自旋）还是没抢到。
底层推演： 场面失控，文明人的规矩不管用了，只能锁膨胀 ，呼叫终极保安 ------ Monitor（管程） 。此时，对象的 Mark Word 会被彻底改写成指向 C++ 底层 ObjectMonitor 对象的指针。 Monitor 保安一出马，铁面无私。它内部维护了两个核心区域：
- _owner（老板椅）：A 抢到了锁，A 坐在里面干活。
- _EntryList（小黑屋）：B 没抢到，Monitor 直接把 B 扒掉一层皮（发生用户态到内核态的切换），强制把 B 塞进小黑屋挂起（Blocked 阻塞）。
效果： B 被挂起后交出了 CPU 执行权，不会像 CAS 那样疯狂空转烧 CPU 了。但代价是，等 A 干完活，系统还得再次进入内核态去把 B 唤醒，这套上下文切换的开销极其巨大，需要消耗成千上万个 CPU 周期。

2. 💡 大厂面试提问

🔥****题 1："既然偏向锁性能这么好，那如果一个对象已经被加上了偏向锁，此时我在业务代码里调用了它的 **hashCode()** 方法，会发生什么？"

完美回答： 这是一个极其经典的"坑"。偏向锁会立刻被撤销，甚至直接膨胀为重量级锁！
- 底层逻辑： 回顾一下对象头的 Mark Word 结构，空间是有限的（64 位系统下只有 64 bit）。在偏向锁状态下，原本用来存储 HashCode 的 31 bit 空间，被强行霸占 用来存储线程 ID 了。一旦你调用了对象的 hashCode()，JVM 必须找个地方把生成的 HashCode 存下来。没办法，它只能把线程 ID 踢掉，撤销偏向锁，把对象升级回无锁（存入 HashCode），或者膨胀成轻量级/重量级锁（把 HashCode 转移到线程栈的 Lock Record 或 Monitor 对象里）。

🔥** 题 2："锁升级的过程大家都说是无后退的（偏向 -> 轻量 -> 重量），难道就永远不能降级了吗？"**

完美破局回答： 在常规的业务应用运行期间，我们可以认为锁升级是单向不可逆 的。因为一旦发生过严重竞争，JVM 就会认为这个对象是"热点资源"，降级没有意义。
- （加分项）： 但是，在极其底层的 JVM 内部机制中（比如到了全局安全点 SafePoint 发生 GC 时），如果 JVM 发现那个重量级锁 Monitor 已经没有任何线程在使用了，它是会主动去清理和降级（Deflate Monitor）的。不过这对普通业务开发来说毫无感知。

五、极致压榨性能：JVM 的其他锁优化（了解即可）

自旋优化： 抢不到锁别急着睡觉，原地转几圈（空循环），说不定锁就释放了。
锁粗化与锁消除： JVM 编译器在后台默默帮你做优化（比如合并多次加锁，或者发现没有竞争直接把锁删了）。

六、总结：撕开黑盒，敬畏底层

回看本文，我们从多线程的"三座大山"（原子性、可见性、有序性）出发，见识了并发 Bug 的残酷现实；随后，我们拿起了 volatile 和 CAS 这两把不锁门的"极客武器"，体验了无锁化并发的轻盈与精妙；最后，我们撕开了对象头的伪装，看懂了 synchronized 这位"老大哥"从偏向锁到重量级锁的四段霸道蜕变，以及 JIT 编译器在后台为你默默兜底的极限优化操作。

很多写业务的同学可能会问："现在到处都是 Redis 分布式锁、各种现成的微服务框架，我平时写写 CRUD，真的需要懂这么深的 JVM 底层吗？"

答案是肯定的。因为高并发架构，从来都不是建在沙滩上的。

平常调用的数据库乐观锁，本质上就是 CAS 思想的延伸；你用的 Zookeeper 或 Redis 分布式锁，底层依然逃不开对可见性和原子性的权衡；当你负责的外卖大促系统、秒杀系统在线上遭遇神秘的 CPU 飙升、接口 RT（响应时间）剧烈抖动、甚至死锁宕机时，如果你不懂 JVM 的上下文切换开销、不懂 JIT 的逃逸分析、不懂偏向锁撤销引发的 STW，你对着日志看三天三夜也找不到根本原因。

懂得这些底层原理，你的眼中将不再只有冰冷的代码。当你敲下每一个 volatile、每一个 synchronized 时，你脑海中浮现的会是 CPU 缓存的一致性协议、是内存屏障的拦截、是管程小黑屋里的线程调度。

这，就是从"框架调用工程师"蜕变为"底层架构师"的必经之路。敬畏底层，写顺应机器天性的代码，这才是大厂后端工程师的核心护城河。

「JVM」 并发编程基石：Java 内存模型（JMM）与 Synchronized 锁升级原理