锁升级是JVM自动将锁从无锁→偏向锁→轻量级锁→重量级锁单向升级的自适应优化机制，依据竞争动态调整以平衡性能与安全，状态全存于对象头Mark Word中。
锁升级，指的是 JVM 在运行时根据实际竞争情况，自动将对象的锁状态从开销最小的形态逐步切换为更重、更安全但开销更大的形态。它不是开发者手动控制的行为，而是 HotSpot 虚拟机内置的自适应优化机制——目标很明确：**没竞争时尽量不折腾，有竞争时再“加码”保障正确性。**
锁升级的四步路径：无锁 → 偏向锁 → 轻量级锁 → 重量级锁
整个过程是单向的，只升不降（除 GC 清理或显式禁用等极少数场景）。所有状态都记录在对象头的 Mark Word 中，JVM 通过修改这个字段来切换锁类型。
- 无锁：对象刚创建，还没被任何线程加锁，Mark Word 存的是哈希码、GC 年龄等常规信息。
- 偏向锁：第一个线程执行 synchronized 时触发。JVM 用 CAS 把当前线程 ID 写进 Mark Word，后续该线程再进同步块，只需比对线程 ID，零同步开销。
- 轻量级锁：第二个线程尝试获取同一把锁时，偏向锁失效，JVM 撤销偏向（可能引发 STW），并在每个竞争线程的栈帧中生成 Lock Record，靠 CAS + 自旋抢锁。
- 重量级锁：自旋失败次数超阈值（默认 10 次），或多个线程同时争抢，JVM 就把对象头指向一个真正的 Monitor 对象，线程进入操作系统等待队列，挂起让出 CPU。
为什么必须升级？不直接上重量级锁？
因为重量级锁要进内核态、做线程挂起/唤醒，一次操作耗时可能是微秒级甚至更高。而现实中，绝大多数 synchronized 块执行极快、几乎不发生竞争。如果每次都走重量级流程，性能会断崖下跌。
- 偏向锁：适合单线程反复调用（如 Spring 单例 Bean 的同步方法）
- 轻量级锁：适合低频错峰加锁（如日志写入、串行化请求处理）
- 重量级锁：真正高竞争场景下的兜底方案（如高频账户扣款、库存抢购）
哪些操作会干扰锁升级？
不是所有代码都能顺利走完四步。有些行为会让 JVM “提前放弃”轻量或偏向路径：
立即学习“Java免费学习笔记（深入）”；
- 调用 Object.hashCode() 或 System.identityHashCode()：会占用 Mark Word 的 hashcode 字段，导致无法存储线程 ID，偏向锁直接禁用。
- 显式关闭偏向锁：-XX:-UseBiasedLocking（JDK 15+ 默认关闭，部分 JDK 8/11 生产环境也会关）
- 批量撤销：当大量对象同时出现竞争，JVM 可能批量撤销偏向锁以减少 STW 时间。
- 锁重入深度过大、或 Lock Record 栈空间不足：也可能跳过轻量级阶段直奔重量级。
怎么验证锁状态？
可通过 Java Agent 工具（如 JOL） 查看对象头内容，或用 JVM 参数开启打印：
- -XX:+PrintBiasedLockingStatistics：输出偏向锁统计
- -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly（需 hsdis）：查看底层锁指令
- 简单观察：在单线程循环调用 synchronized 方法后，用 JOL 的
ClassLayout.parseInstance(obj).toPrintable()查 Mark Word 低 3 位（锁标志位）
基本上就这些。锁升级不是玄学，它是 JVM 在“性能”和“安全”之间做的实时权衡——你看不见它，但它每时每刻都在默默工作。
