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