重量级锁通过让线程阻塞而非自旋来避免cpu空转，虽自身开销大，但在高竞争或长临界区场景下，以少量上下文切换代价换取整体cpu利用率可控和系统稳定性提升。
Java 中 synchronized 的重量级锁本身不降低 CPU 占用，反而是高 CPU 开销的“兜底机制”；它的作用是在竞争激烈时避免 CPU 空转浪费，通过让线程进入阻塞态（BLOCKED），把 CPU 时间片让给其他线程，从而间接降低无效自旋带来的 CPU 占用率。
换句话说：重量级锁不是靠“高效”来省 CPU，而是靠“及时放弃”来止损。
重量级锁如何避免 CPU 空转
当轻量级锁的自旋失败（比如默认 10 次自旋后仍拿不到锁），JVM 就会将锁膨胀为重量级锁。此时：
- 线程不再循环检查锁状态（即停止自旋）
- 调用操作系统互斥量（如
pthread_mutex），进入内核态等待 - 线程被挂起（park），从运行态变为 BLOCKED 态
- CPU 不再为其调度时间片，资源交由其他就绪线程使用
✅ 这样做的直接效果是：把原本可能持续占用 CPU 的“忙等”（busy-wait），转为“休眠等待”（sleep-wait）。
举个对比：
- 轻量级锁自旋 10 次 → 每次都是空循环，消耗几十到上百 CPU 周期
- 重量级锁阻塞 10ms → CPU 完全不执行该线程，零计算开销（仅少量上下文切换成本）
注意：上下文切换本身有开销（约 1000–2000 纳秒），但远小于长时间自旋——尤其在锁持有时间较长（>100ns）或竞争线程较多时，阻塞更划算。
重量级锁降低 CPU 占用的关键前提
它能“省 CPU”，依赖两个重要条件：
- 锁持有时间足够长：如果临界区执行慢（比如含 I/O、网络调用、复杂计算），自旋毫无意义，早进阻塞更明智
- 竞争线程数量较多：2 个线程自旋尚可接受；10 个线程同时自旋，CPU 很快被占满，响应变慢
这时重量级锁的“让出 CPU”策略，反而提升了整体吞吐和系统稳定性。
实际影响示例
假设一个支付接口同步块平均耗时 5ms，有 20 个并发请求：
- 若强行用轻量级锁 + 长自旋（比如 1000 次）→ 每个失败线程空跑数微秒，20 个线程反复争抢，CPU 使用率飙升至 90%+，响应延迟抖动大
- 升级为重量级锁后 → 大部分线程快速阻塞，CPU 专注服务正在执行的那 1–2 个线程，利用率稳定在 30%–50%，平均响应更平稳
这就是“牺牲单线程等待效率，换取整体 CPU 利用率可控”。
补充：为什么不是越早用重量级锁越好？
因为重量级锁触发内核态切换，单次开销比自旋高一个数量级。所以 JVM 的设计逻辑是：
- 无竞争 → 偏向锁（几乎零开销）
- 轻微竞争 → 轻量级锁 + 自旋（短时竞争，省切换）
- 明确高竞争 → 重量级锁（止盈止损，防 CPU 过载）
它是一套渐进式降级容忍策略，而非单纯追求“最快”或“最省”。
不复杂但容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
