用vmstat 1观察cs列飙升可识别synchronized高争用引发的上下文切换：空闲系统cs通常
怎么用 vmstat 和 perf 观察 synchronized 引发的上下文切换飙升
当 synchronized 在高争用下升级为重量级锁，线程会进入操作系统级阻塞队列（ObjectMonitor 内部调用 futex_wait），此时每次抢锁失败都会触发一次线程挂起 —— 这就是上下文切换的直接源头。
实操建议：
- 用
vmstat 1持续观察cs（context switch）列：空闲系统通常 - 配合
perf stat -e context-switches,task-clock,cycles -p <pid></pid>抓取 Java 进程粒度数据，避免被其他进程干扰 - 注意区分
cs和involuntary_ctxt_switches：后者才是因锁失败被迫让出 CPU 的次数，voluntary多为 IO 等待，意义不同
为什么 jstack 看到大量 BLOCKED 却不等于上下文切换已发生
jstack 输出中出现成百上千个 java.lang.Thread.State: BLOCKED (on object monitor)，只说明线程在等待 Monitor 入口，但不意味着它们都已完成上下文切换。真实切换发生在 JVM 调用 pthread_cond_wait 或 futex_wait 进入内核态那一刻。
关键点：
- 线程进入
BLOCKED状态后，JVM 会先尝试自旋（轻量级锁阶段），自旋失败才真正调用 OS 接口挂起 —— 所以不是每个 BLOCKED 都对应一次上下文切换 - 自旋阈值由
-XX:PreBlockSpin控制（默认 10），但 JDK 6+ 后该参数已失效，实际由 JVM 自适应决定 - 用
java -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1可间接观察 Monitor 争用是否引发 safepoint 停顿，这是重量级锁活跃的强信号
ObjectMonitor 内部 futex_wait 怎么把线程拖进内核态
JVM 对 ObjectMonitor 的实现，在 Linux 上最终落到 futex(FUTEX_WAIT) 系统调用。一旦线程调用它，就会从用户态陷入内核态，保存寄存器、栈指针、程序计数器，然后被移出运行队列 —— 这就是一次完整上下文切换的物理动作。
影响因素：
- 频繁调用
futex_wait会破坏 CPU 缓存局部性：前一个线程的数据大概率被踢出 L1/L2 cache，新线程唤醒后要重新加载，cache miss 激增 - 跨 CPU 核调度更贵：若等待线程和唤醒线程不在同一物理核，还需同步 TLB 和 cache line，耗时比同核切换高 2~3 倍
- 不要依赖
strace -e trace=futex监控生产环境：futex 调用极频繁，开销本身就会拖慢服务，仅限复现环境定位
如何用 -XX:+PrintGCDetails 和 -XX:+TraceClassLoading 查锁升级痕迹
重量级锁不是凭空出现的，它由偏向锁 → 轻量级锁 → 重量级锁逐级升级而来。JVM 不会主动打印锁升级日志，但可通过组合参数捕捉线索：
实操建议：
- 加
-XX:+UnlockDiagnosticVMOptions -XX:+PrintBiasedLockingStatistics：查看偏向锁撤销次数，若每秒撤销超百次，说明单线程场景已崩，偏向锁失效 - 加
-XX:+PrintCompilation：观察是否频繁触发osr_compilation（栈上替换），这是轻量级锁自旋失败后 JIT 优化退化信号 - 结合 GC 日志中的
safepoint时间：若time-to-safepoint突增且与并发线程数正相关，大概率是重量级锁导致 Monitor 竞争卡住全局 safepoint
真正难处理的不是锁本身，而是多个线程在同一个 ObjectMonitor 上反复进出内核态 —— 它不像纯计算那样容易压测复现，往往在流量毛刺或 GC 暂停后才集中爆发。监控不能只盯 cpu usage，得把 cs、involuntary_ctxt_switches、safepoint sync time 三项串起来看。
