一旦cs值冲到每秒1000次以上，基本就该着手排查了——这往往就是不少服务开始变得不稳定的第一个明确信号。排查时，先用vmstat 1盯住整体量级，但别只看一个数字，必须把r、b、in几个指标一起联动起来判断根因；接着再用pidstat -w 1（加-t）下钻到进程和线程层面，分别定位自愿/非自愿切换的情况，最后再结合/proc/stat里ctxt的增量，确认长期趋势到底是偶发波动，还是已经持续走高。
超过1000次/秒的cs值就该动手查了——这不是警报阈值，而是多数服务开始失稳的信号起点。
用vmstat 1看系统级总量，但别只盯cs数字
运行vmstat 1，第三行开头的cs列是每秒上下文切换总次数，但它混着进程、中断、软中断三类切换，不能直接归因到代码或配置问题。
cs高 +r（就绪队列）远大于 CPU 核数 → CPU 资源争抢严重，优先查线程数或调度策略cs中等 +b（不可中断进程）> 0 → 真正卡点在 I/O 或锁，不是切换本身的问题- 首次输出是累计值，第二秒起才是真实速率；单次峰值可能是毛刺，连续 5 秒 >1000 才值得跟进
in（中断次数）同步飙升时，cs高大概率来自网卡、磁盘驱动等硬件中断，和应用层无关
用pidstat -w 1定位具体进程和切换类型
pidstat -w必须带采样间隔（如1），否则立即退出无输出——这是最常卡住的地方。它能拆出两类关键指标：
cswch/s：自愿切换，进程主动让出 CPU，常见于read()/write()阻塞、锁等待、条件变量休眠nvcswch/s：非自愿切换，时间片被强制收回，典型如线程数远超 CPU 核数、Ja va GC 抢占、实时进程抢占- Ja va 应用中
cswch/s突增 +jstack显示大量BLOCKED→ 锁竞争；nvcswch/s>50 且%CPU低 → 线程模型过载 - 加
-t才能看到线程级数据（LWP），否则多线程进程的切换会被平均稀释，看不出真实热点
用grep ctxt /proc/stat验证长期趋势，避开瞬时抖动
直接读内核统计比工具更稳：grep ctxt /proc/stat返回的是系统启动以来的总切换次数，适合排除毛刺干扰。
- 隔 10 秒执行两次，差值除以 10 得到平滑 cps，比
vmstat或pidstat的瞬时值更可靠 - 如果 1 小时内增长 360 万次（即平均 1000/s），而业务 QPS 没变 → 底层有隐性资源争抢，比如连接池耗尽、日志刷盘频率突增
- 注意：
/proc/stat的ctxt值本身无意义，关键是看单位时间内的增量速率，不是绝对数值
容易忽略的底层细节：中断和线程模型混淆判断
vmstat的cs包含中断上下文切换，而pidstat -w只统计用户态进程——两者永远对不上，这不是工具 bug，是设计使然。
- 网卡每秒触发 5000 次软中断，
vmstat照样计入cs，但pidstat完全不体现 - 进程状态为
D（不可中断睡眠）时，pidstat -w不会显示该进程，哪怕它正卡在磁盘 I/O 上引发连锁唤醒 - 老版本
sysstat（如 RHEL 7 自带的 10.1.5）不支持-w和-t同时生效，先跑pidstat -V确认版本 ≥ 11.0.0
真正难的不是看到cs高，而是分清这高到底是来自你的 Ja va 线程、Nginx 工作进程、还是网卡驱动——三者修复路径完全不同。别跳过r/b/in联动分析，也别绕过pidstat -t看线程级数据，否则你只是在给表象打补丁。
