超过1000次/秒就该警惕——这不是绝对阈值，而是多数稳定服务的临界信号；vmstat输出的cs列代表每秒上下文切换总次数，需结合r、b列判断根因，但无法区分自愿/非自愿切换或定位具体进程。
直接看 cs 列，超过 1000 次/秒就该警惕了——这不是绝对阈值，而是多数稳定服务的临界信号。
用 vmstat 快速抓系统级上下文切换总量
vmstat 是最轻量、无需额外安装的入口工具，它输出的 cs（context switch）字段就是每秒上下文切换总次数。
- 运行
vmstat 1，重点关注第三行开头的cs值；数值持续 >1000 表示系统调度压力明显升高 - 注意对比
r（就绪队列长度）和b（不可中断进程数）：r高 +cs高 → 大量进程争抢 CPU；b高 +cs中等 → I/O 等待拖慢调度节奏，不是上下文切换本身的问题 -
vmstat不区分自愿/非自愿切换，也不能关联到具体进程，仅用于“有没有问题”的快速判断
用 pidstat -w 定位高切换进程和类型
要查清楚谁在频繁切换、为什么切，必须用 pidstat -w。它依赖 sysstat 包，Debian/Ubuntu 下装 sudo apt install sysstat，CentOS/RHEL 用 sudo yum install sysstat。
- 执行
pidstat -w 1，观察cswch/s（自愿切换）和nvcswch/s（非自愿切换）两列 -
cswch/s高：进程主动让出 CPU，常见于频繁阻塞等待，比如短连接 HTTP 服务反复read()/write()、日志同步刷盘、锁竞争导致futex等待 -
nvcswch/s高：CPU 时间片被强制收回，典型是线程/进程过多、优先级配置失当，或 Java 应用中 GC 线程频繁抢占 —— 这类切换开销更大，因涉及完整寄存器+内存映射保存 - 多线程程序若单个线程
nvcswch/s超 50，且%CPU却不高，大概率是锁粒度太细或线程数远超 CPU 核数
查 /proc/stat 看累计值，排除瞬时毛刺干扰
有些场景下 vmstat 或 pidstat 显示的峰值只是几秒抖动，未必反映真实负载。这时直接读内核统计更可靠：
- 运行
grep ctxt /proc/stat，输出形如ctxt 123456789，这是系统启动以来的总切换次数 - 隔 10 秒再查一次，用差值除以 10 得到平均 cps，比实时工具更平滑，适合判断长期趋势
- 该值本身无意义，关键是看增长速率：如果 1 小时内增长 360 万次（即平均 1000/s），而业务 QPS 没变，说明底层有隐性资源争抢
多线程性能分析不能只盯上下文切换
上下文切换高只是表象，背后常混着线程模型、锁、GC、系统调用等多层问题。实操中容易忽略的关键点：
- Java 应用务必结合
jstack看线程状态：java.lang.Thread.State: BLOCKED对应高cswch/s，RUNNABLE但 CPU 利用率低则可能卡在 safepoint 或 native 方法里 - Go 程序要注意
GOMAXPROCS设置：设得过大（如 > CPU 核数 2 倍）会导致 goroutine 调度器频繁抢占，nvcswch/s上升但实际吞吐不增 - 不要盲目减少线程数——某些 I/O 密集型服务（如 Redis AOF fsync）需要足够线程维持吞吐，此时高
cswch/s是合理代价，重点应是降低每次切换的开销（如用 io_uring 替代阻塞 syscall）
真正难的是区分“切换多是因为业务重”，还是“切换多是因为设计烂”。前者加机器能缓解，后者不改代码永远治标不治本。
