重量级锁开销主要来自线程阻塞/唤醒、用户态与内核态切换及操作系统调度参与：每次系统调用切换耗几十至上百纳秒，唤醒存在毫秒级调度延迟，且互斥量需内核维护数据结构，争用激烈时futex退化为全内核锁，开销难以规避。
当 synchronized 锁升级到重量级锁时，JVM 会将锁的实现从用户态的 CAS 自旋切换为依赖操作系统内核的互斥量（Mutex），此时开销主要来自三方面：线程阻塞/唤醒、用户态与内核态切换、以及操作系统调度参与。
用户态与内核态切换成本高
每次加锁或释放重量级锁，JVM 必须通过系统调用（如 Linux 的 futex）进入内核。一次完整的切换涉及寄存器保存、页表刷新、上下文保存与恢复，单次开销通常在 **几十到上百纳秒**，远高于偏向锁（几乎为零）或轻量级锁（几十纳秒内完成 CAS）。若临界区极短但竞争频繁，这种切换会成为性能瓶颈。
线程挂起与唤醒带来调度延迟
当线程抢不到重量级锁时，JVM 会将其置为阻塞态（BLOCKED），交由操作系统线程调度器管理。该过程包括：
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 从运行队列移出，加入等待队列
- 触发调度器重新选择下一个运行线程
- 锁释放后需唤醒等待线程，并重新竞争 CPU 时间片
唤醒不是即时的——存在调度延迟（毫秒级），尤其在高负载系统中，可能叠加多个线程的排队等待，造成“锁拖尾”现象。
互斥量本身引入额外资源开销
操作系统互斥量需要内核维护数据结构（如等待队列、所有权标记、优先级继承逻辑等），每个重量级锁对象对应一个内核级 Mutex 实例。大量并发锁对象会增加内核内存占用和锁管理复杂度；同时，futex 在争用激烈时可能退化为完全内核态的 mutex 或 semaphore，进一步放大开销。
为什么这个开销难以规避？
重量级锁是 JVM 在竞争不可调和时的兜底方案，其设计目标是正确性优先于性能。一旦升级，所有后续操作都绕不开内核介入——包括锁重入检测、等待队列管理、中断响应等，这些都无法在纯用户态完成。这也是锁升级不可逆的根本原因：JVM 不再信任当前对象能回归低竞争状态，因此放弃优化尝试。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
