synchronized锁升级本身不产生额外开销，它是JVM根据竞争情况被动触发的状态迁移，仅修改对象头Mark Word的位模式；真正性能代价来自重量级锁引发的线程阻塞、内核态切换及上下文切换。
Java 中 synchronized 锁升级本身**不产生额外开销**，它是 JVM 在运行时根据竞争情况**被动触发的优化策略**，不是主动“执行升级操作”，所以没有传统意义上的“升级开销”。真正影响性能的是锁升级后所依赖的重量级锁机制（如操作系统互斥量）带来的线程阻塞、上下文切换等代价。
锁升级是状态迁移，不是主动操作
JVM 对每个对象头中的锁标记位（Mark Word）进行动态管理。锁状态按：无锁 → 偏向锁 → 轻量级锁 → 重量级锁 逐级演进。这个过程本质是 Mark Word 的位模式变更和少量字段重写（如记录线程 ID、栈帧地址、指向 Monitor 的指针），全部在用户态完成，不涉及系统调用。
- 偏向锁撤销：检测到竞争时，需暂停目标线程（安全点）、清除偏向状态、恢复为无锁或直接膨胀为轻量级锁
- 轻量级锁膨胀：当自旋失败或自旋次数超限，JVM 将对象头指向堆中一个 ObjectMonitor 实例，并将所有等待线程挂入该 Monitor 的 _cxq 或 _EntryList 队列
真正的开销来自重量级锁的底层实现
一旦膨胀为重量级锁，后续所有未获取锁的线程都会被 park()（即阻塞），这会触发：
- 线程状态从 RUNNABLE 变为 WAITING/TIMED_WAITING，进入操作系统线程调度器管理
- 发生用户态到内核态的切换（syscall），如 Linux 下调用
futex_wait - 后续唤醒（unpark）需由持有锁线程释放锁时调用
unpark()，再经内核调度重新激活等待线程 - 频繁的上下文切换（context switch）带来 CPU 缓存失效、TLB 刷新等隐性成本
如何降低重量级锁的实际影响
关键不是阻止升级（JVM 自动决策已较合理），而是减少进入重量级锁场景的概率：
立即学习“Java免费学习笔记（深入）”；
- 缩小同步块范围：只锁必要代码，避免 I/O、长循环、方法调用等耗时操作在 synchronized 内
- 避免锁竞争热点：如用 ConcurrentHashMap 替代 Hashtable；对日志、计数器等场景考虑分段锁或 LongAdder
-
合理设置 JVM 参数（仅调试/调优阶段）：
-XX:+UseBiasedLocking（默认开启）、-XX:BiasedLockingStartupDelay=0（加速偏向启用）、-XX:PretenureSizeThreshold配合对象分配避免锁相关对象过早进入老年代 -
监控锁状态：使用
jstat -printcompilation或 JFR 事件（java.util.concurrent.locks.BiasedLockRevocation）观察偏向撤销频率；通过jstack查看 BLOCKED 线程数量判断是否已大量膨胀
补充说明：锁降级不存在
JVM 不支持重量级锁“降级”回轻量级或偏向锁。一旦膨胀，该对象后续所有锁获取都直接走 Monitor 流程，直到对象被 GC 回收。这也是为什么高竞争对象长期处于重量级状态——不是升级慢，而是“一升永重”。
