synchronized锁升级是JVM根据竞争状态自动触发的对象头Mark Word标志位变更过程，顺序为无锁（001）→偏向锁（101）→轻量级锁（000）→重量级锁（010），不可逆，依赖monitorenter指令执行时的CAS操作与竞争检测。
synchronized 锁升级不是由 Java 代码主动触发的，而是 JVM 在运行时根据对象的锁竞争状态，自动调整对象头（Mark Word）中锁标志位的过程。整个过程完全在底层发生，开发者看不到显式调用，但可以通过对象头变化和线程行为感知它。
锁升级依赖对象头的 Mark Word 状态切换
每个 Java 对象在堆中都有一个对象头，其中 Mark Word 占 64 位（64 位 JVM），最后 3 位是锁状态标识。JVM 就靠这 3 位来区分当前锁处于哪种形态：
- 最后两位是 01，倒数第三位是 0 → 无锁状态（Normal）
- 最后两位是 01，倒数第三位是 1 → 偏向锁（Biased）
- 最后两位是 00 → 轻量级锁（Lightweight）
- 最后两位是 10 → 重量级锁（Heavyweight）
锁升级就是这几位值随竞争加剧而逐步改变：001 → 101 → 000 → 010。这个过程不可逆，一旦升级就不会退回。
升级每一步都对应具体运行行为
不是定时器或后台线程在“检查”，而是每次线程执行 monitorenter 指令时，JVM 都会读取并尝试修改 Mark Word，根据当前值和线程上下文决定走哪条路径：
立即学习“Java免费学习笔记（深入）”；
- 偏向锁获取：线程第一次进入同步块，发现对象处于无锁态（001），且偏向锁未禁用，就用 CAS 把自己的线程 ID 写入 Mark Word，并将状态设为 101；后续该线程再次进入，只需比对线程 ID，无需加锁开销
- 偏向锁撤销：另一个线程来竞争，发现已有偏向线程，就会暂停偏向线程（可能触发 safepoint），清空偏向信息，把状态从 101 改为 001，再升级为轻量级锁
- 轻量级锁加锁：线程在栈帧中新建一个 Lock Record，用 CAS 将其地址替换 Mark Word；成功则进入临界区；失败说明有竞争，开始自旋重试
- 升级为重量级锁：自旋一定次数（默认 10 次）仍抢不到锁，JVM 就放弃自旋，把 Lock Record 中的指针替换成指向堆中 ObjectMonitor 的指针，状态改为 010；所有后续竞争线程都会被挂起进 _entryList
ObjectMonitor 是重量级锁的实际载体
当锁升级到重量级，synchronized 就不再靠对象头或栈上记录控制，而是委托给操作系统级的互斥原语。ObjectMonitor 是 HotSpot 中的具体实现，核心字段包括：
- _owner：指向持有锁的线程指针
- _count：可重入计数器，每次加锁 +1，解锁 -1，归零才真正释放
- _entryList：阻塞等待获取锁的线程队列（通过 park/unpark 操作）
-
_waiters：调用
wait()后挂起的线程队列
此时，monitorenter 和 monitorexit 指令实际操作的是这个 Monitor 结构，不再是简单的 CPU 指令或栈操作，已涉及内核态调度，开销显著增大。
升级不是凭空发生的，需要真实竞争信号
JVM 不会预判或提前升级。只有当以下任一情况出现，才会推动状态变更：
- 偏向锁下有其他线程尝试加锁（触发偏向撤销）
- 轻量级锁自旋失败达到阈值（-XX:PreBlockSpin，默认 10）
- 存在多个线程频繁进出同一把锁（JVM 可能记录锁的“竞争历史”，辅助决策）
你可以用 JOL（Java Object Layout）工具打印对象头，在不同阶段观察 Mark Word 变化；也可以用 -XX:+PrintSynchronizationStatistics 查看锁统计，验证是否发生了升级。
