重量级锁触发上下文切换的核心开销在于线程挂起/唤醒时的用户态→内核态跳转、cpu缓存失效及调度重载；其物理起点是自旋失败后调用futex_wait，而非所有blocked线程均已完成切换。
重量级锁触发的上下文切换，核心开销不在“加锁动作本身”，而在线程被强制挂起、唤醒时发生的用户态到内核态跳转，以及CPU缓存和调度资源的重载。
上下文切换的真实发生点
不是所有 jstack 里显示 BLOCKED 的线程都已完成上下文切换。JVM 会先让线程自旋（默认约 10 次），只有自旋失败后才调用 futex_wait 进入内核态挂起——这才是上下文切换的物理起点。一次 futex_wait 调用意味着：保存寄存器、切换栈指针、移出 CPU 运行队列、同步 TLB 和 cache line（跨核时更贵）。
可观测的关键指标
-
involuntary_ctxt_switches：用
perf stat -e context-switches,involuntary_ctxt_switches,task-clock -p <pid></pid>抓取，这个值才是锁争用导致的“被迫让出 CPU”次数；voluntary 多是 IO 等待，不反映锁问题 -
cs 列持续高于 10k/s：用
vmstat 1观察，空闲系统通常低于 1k，高 cs + 低 CPU 利用率 + 吞吐骤降，是重量级锁的典型信号 -
Safepoint 停顿激增：加参数
-XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1，Monitor 争用活跃时 safepoint 频次明显上升
为什么开销远超几十纳秒
重量级锁每次获取/释放都伴随一次 pthread_mutex_lock/unlock 系统调用。实测单次开销在几百纳秒到微秒级，比轻量级锁高 10–100 倍。更严重的是副作用：
- 前一个线程的数据大概率被踢出 L1/L2 cache，新线程唤醒后 cache miss 激增
- 若等待线程和唤醒线程落在不同物理核，TLB 和 cache line 同步耗时比同核高 2~3 倍
- 即使 synchronized 块里只执行
return;，只要升级为重量级锁，这些开销照常发生
别踩的监控陷阱
strace -e trace=futex 在生产环境禁用——futex 调用频率极高，开启后自身就会拖慢服务。它只适合复现环境定位锁热点。真正要抓的是 Java 进程粒度的上下文切换数据，避免被其他进程噪声干扰。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
