Java锁升级机制是JVM根据线程竞争程度自动将锁从无锁→偏向锁→轻量级锁→重量级锁单向升级的过程：无锁初始状态；偏向锁适用于单线程重复加锁，仅比对线程ID，开销最低；轻量级锁通过自旋+CAS应对短暂多线程交替竞争；重量级锁在持续高竞争时启用，依赖操作系统Mutex，触发内核态切换与线程阻塞，性能开销最大。
短时间内大量加锁会触发频繁的锁升级，但实际影响取决于竞争模式而非单纯次数——关键看是否发生线程竞争以及竞争持续时长。
偏向锁在高频率单线程加锁下最高效
如果同一对象被同一个线程反复加锁（例如循环内多次进入同一 synchronized 块），JVM 会维持偏向锁状态。此时仅需比对 Mark Word 中的线程 ID，无需 CAS 或系统调用，开销极低。这种场景下，哪怕每毫秒加锁数百次，也不会触发升级，性能几乎无损。
轻量级锁应对短暂多线程竞争较友好
当两个或少量线程交替抢锁，且每次持有时间很短（微秒级），轻量级锁通过自旋 + CAS 尝试获取锁，避免陷入内核态。只要自旋未超时（默认10次左右，可由 -XX:PreBlockSpin 调整），就不会膨胀为重量级锁。这种情况下，短时高频加锁仍能保持较低延迟。
- 自旋成功：线程在用户态忙等，不挂起，上下文切换零成本
- 自旋失败：才触发锁膨胀，真正代价在此刻产生
重量级锁是性能拐点，大量加锁会放大其代价
一旦出现三线程及以上持续争抢，或单次持锁时间较长（如含 I/O、sleep），轻量级锁就会升级为重量级锁。此时每次加锁/解锁都涉及：
立即学习“Java免费学习笔记（深入）”；
- 操作系统 Mutex 的用户态→内核态切换（约 1000+ 纳秒）
- 线程挂起与唤醒的调度开销
- Monitor 对象在堆中分配与管理（虽复用，但首次创建有额外 GC 压力）
若短时间内大量触发重量级锁操作，CPU 时间会明显消耗在调度和上下文切换上，吞吐下降、延迟抖动加剧，甚至引发线程饥饿。
锁撤销与批量重偏向带来隐性开销
当一个已偏向的锁被其他线程尝试获取，JVM 需要“撤销偏向”：暂停目标线程（安全点）、清空 Mark Word、恢复为无锁状态，再走轻量级锁流程。若大量对象同时被不同线程首次争抢（如新服务启动初期），可能引发：
- 频繁安全点停顿（Stop-The-World 小幅暂停）
- 批量撤销导致的短暂 CPU 尖峰
- 后续重新偏向的重复开销
这类行为在 JDK 15+ 已优化（如禁用偏向锁默认），但在老版本或显式开启时需警惕。
