linux排查cpu上下文切换过高需先用vmstat看cs列是否异常（>5000/s需警惕），再用pidstat -w区分自愿（cswch/s）与非自愿切换（nvcswch/s），最后用perf抓sched_switch事件分析根因。
Linux 中排查 CPU 上下文切换过高导致的性能下降，关键不是盯着“CPU 使用率低就没事”，而是主动识别“CPU 在忙切换，没在干活”这种隐性卡顿。核心思路是：先确认是否异常高，再分层定位到进程、线程、切换类型，最后结合行为归因。
看整体是否异常：用 vmstat 快速抓基准
运行 vmstat 1，重点关注 cs（context switch）列：
- 空闲系统通常每秒几十到一两百次；持续超过 5000 次/秒需警惕，上万甚至十万级基本可判定为异常
- 同步看 r（就绪队列长度）和 in（中断次数）：若 r 很小但 cs 很高，说明不是 CPU 竞争导致，更可能是 I/O 或锁等待引发的自愿切换；若 in 也同步飙升，要怀疑中断风暴
- 注意 cs 包含所有切换——进程、线程、内核态/用户态模式切换，它只是“总报警灯”，不能直接定位根因
查具体是谁在切：用 pidstat -w 分进程分析
执行 pidstat -w 1，重点观察两列：
- cswch/s：每秒自愿上下文切换次数。高值常见于进程主动 sleep、wait、阻塞式 I/O（如未设 O_NONBLOCK 的 read）、锁竞争等待
- nvcswch/s：每秒非自愿切换次数。高值指向 CPU 时间片被抢、调度器强占，典型场景是大量线程争抢少数 CPU 核心，或存在高优先级实时任务干扰
- 重点关注 cswch/s 高但 %CPU 却很低的进程——这是“假空闲真卡顿”的典型信号，比如一个 Java 应用线程频繁调用
Object.wait()或阻塞读 socket
挖深层原因：结合 perf 和 /proc/PID/status 细查
仅靠统计不够，得知道“为什么切”和“切得有多痛苦”：
- 用 perf record -e sched:sched_switch -a sleep 10 抓调度事件，再用 perf script | grep -E '==>.*| 查看哪些进程/线程在频繁进出 CPU，以及被切出的原因（如
preempt、signal、io、timeout） - 查可疑进程的 /proc/PID/status，看
voluntary_ctxt_switches和nonvoluntary_ctxt_switches累计值。两者比值远大于 10:1，大概率是 I/O 或锁问题；接近 1:1 则偏向 CPU 资源争抢 - 对 Java 进程，配合 top -H -p PID 找高 cswch 的线程，用 printf '%x' TID 转 nid，再 jstack PID | grep nid -A5 -B5 看堆栈，确认是否卡在
WAITING或BLOCKED状态
常见诱因与对应线索
很多高频切换不是“多任务”本身造成的，而是某些编程或配置习惯触发的隐式调度：
-
阻塞 I/O：日志里看到大量
read/write系统调用耗时长，或strace -p PID -e trace=read,write发现频繁进入内核并返回 EAGAIN 后又重试 -
高频 clock_gettime：尤其
CLOCK_MONOTONIC在旧内核未 vDSO 化时，每次调用都陷内核，perf record -e syscalls:sys_enter_clock_gettime 可验证 -
信号轮询：如用
kill -USR1频繁通知 worker 线程，cat /proc/PID/status | grep Sig 可见挂起信号数激增 -
无界自旋：代码中出现
while(!flag);且无cpu_relax()，perf top -p PID 会显示该函数长期占用 CPU，但实际没做有效计算
