不能直接用jvm参数查看上下文切换频率，需组合-xx:+printsafepointstatistics等jvm参数与vmstat、perf等系统工具协同定位：safepoint密集且原因为monitor enter表明重量级锁高争用，jstack中blocked线程数不等于实际切换次数，真实cs值须以vmstat的cs列或perf stat为准。
不能直接用 jvm 参数“查看”上下文切换频率——jvm 本身不暴露实时的上下文切换计数作为运行时参数，但可通过组合 jvm 启动参数 + 外部系统工具，精准定位 synchronized 高频争抢锁引发的上下文切换行为。
用 -XX:+PrintSafepointStatistics 辅助判断重量级锁活跃度
当 synchronized 升级为重量级锁（即线程真正进入 ObjectMonitor 的 futex_wait 阻塞），会频繁触发 JVM Safepoint。虽然这不是上下文切换的直接计数，但它是重量级锁高争用的强信号：
- 添加参数：-XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1
- 观察日志中 Safepoint 停顿是否密集（如每秒多次）、且停顿原因含 "no vm operation" 或 "blocking on monitor enter"
- 若 Safepoint 频繁且集中在 monitor 相关操作，说明大量线程正尝试获取同一把锁，已进入 OS 级阻塞准备阶段
用 -XX:+UnlockDiagnosticVMOptions + -XX:+LogVMOutput 捕获 Monitor 事件（JDK 8u60+）
启用 JVM 内部锁竞争日志，可看到锁膨胀、竞争线程数等关键信息：
- 添加参数：-XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=jvm_monitor.log -XX:+TraceMonitorInflation
- 日志中会出现类似："Inflating object monitor for ... with 12 competing threads"
- 竞争线程数持续 >5–10，基本意味着自旋失败率高，futex_wait 调用将密集发生 → 上下文切换风险陡增
必须配合操作系统工具才能获得真实 cs 值
JVM 层无上下文切换计数器，必须依赖 Linux 系统指标：
- vmstat 1：紧盯 cs 列 —— 空闲系统通常 5000/秒且与业务流量峰重合，大概率是锁争用所致
-
pidstat -w -p
1 ：确认该 Java 进程自身的上下文切换次数（CG 和 YC 列）是否异常偏高 -
perf stat -e context-switches,task-clock,cycles,instructions -p
：抓取进程粒度的精确切换次数，排除其他进程干扰
区分真假 BLOCKED：jstack 不等于切换已发生
jstack 显示大量 java.lang.Thread.State: BLOCKED (on object monitor) 是线索，但不是证据：
- 线程进入 BLOCKED 状态后，JVM 仍可能先执行自旋（默认约 10 次），未失败前不调用 futex_wait，不触发上下文切换
- 只有线程真正调用 pthread_cond_wait 或 futex(FUTEX_WAIT) 陷入内核态那一刻，才完成一次上下文切换
- 所以 jstack 中数百个 BLOCKED 线程，实际每秒发生的上下文切换可能只有几十到几百次——需以 vmstat 的 cs 值为准
