上下文切换过高怎么排查？cs 高 + CPU 忙系统态 = 锁/切换开销
答案：上下文切换过高通常是锁竞争、频繁唤醒、线程过多导致。排查三步：vmstat 1 看 cs 列 → pidstat -w 1 定位进程 → 结合 top 判断是忙等还是真忙。
排查三步
# 1. 看系统切换量趋势（cs 列）
vmstat 1
# 2. 定位是哪个进程切换多（cswch 列）
pidstat -w 1
# 3. 看 CPU 状态：us 低、sy 高 → 多半是锁/切换开销
top -1判断口诀：cs 高 + us（用户态）低 + sy（系统态）高 + wa 不高 → 性能被上下文切换/锁吃掉，而不是真的在算。
常见根因与对策
| 根因 | 特征 | 对策 |
|---|---|---|
| 锁竞争 | 线程互相 futex 等待 | 无锁/读写锁/分段锁；减少锁粒度 |
| 频繁唤醒-阻塞 | epoll 忙等、信号轰炸 | 事件驱动、批量处理、合并定时器 |
| 线程过多 | 每任务一线程 | 线程池，控制活跃线程数 |
| CPU 迁移 | 线程在核间跳 | 设置 CPU 亲和性（taskset/sched_setaffinity） |
| 抢占频繁 | 高优先级线程多 | 调整调度策略（SCHED_BATCH/IDLE） |
关键区分
- 上下文切换 ≠ 系统调用：切换是 CPU 换执行流；syscall 是进内核态。
pidstat -w看切换，strace -c看 syscall； - 线程多 ≠ 切换多：都阻塞在 epoll 上时切换很少；"频繁唤醒又阻塞"的线程才每轮抢 CPU。
深度入口
FAQ
Q: 上下文切换过高是什么原因？ A: 常见原因：锁竞争（线程互相等待）、频繁唤醒/睡眠（epoll 忙等或信号）、线程/进程数过多、CPU 亲和性差导致迁移、系统调用频繁触发抢占。
Q: 上下文切换过高怎么排查？ A: 1) vmstat 1 看 cs 列趋势；2) pidstat -w 1 定位是哪个进程切换多；3) 配合 top 看 CPU 是忙等还是真忙；4) strace/perf 看卡在什么调用。
Q: vmstat 里 cs 多高算高？ A: 没有绝对阈值，但结合 cswch/s 与 CPU 使用率看：cs 高 + 用户态 CPU 低 + 系统态 CPU 高，基本是锁/切换开销主导。
Q: 怎么降低上下文切换？ A: 减少锁竞争（无锁/读写锁/分段锁）、减少线程数（线程池）、避免忙轮询（用事件驱动）、设置 CPU 亲和性、合并小 IO 为批量。
Q: 线程多就一定切换多吗？ A: 不一定。线程多但都阻塞在事件上（epoll 等待），切换反而少；真正多的是"频繁唤醒又阻塞"的线程，每轮都抢 CPU。
Q: 上下文切换和 syscall 的区别？ A: 上下文切换是 CPU 切换执行流（线程/进程）；系统调用是 CPU 切到内核态执行内核代码，两者独立。pidstat -w 看切换，strace -c 看 syscall。
一句话总结：上下文切换过高 = 锁/唤醒/线程结构的问题；vmstat 看量、pidstat -w 找人、top 判性质，再对症减锁、减线程、加亲和性。