如何在Linux中查看CPU的上下文切换次数 Linux分析多线程性能的方法

超过1000次/秒就该警惕——这不是绝对阈值，而是多数稳定服务的临界信号；vmstat输出的cs列代表每秒上下文切换总次数，需结合r、b列判断根因，但无法区分自愿/非自愿切换或定位具体进程。

直接看 cs 列，超过 1000 次/秒就该警惕了——这不是绝对阈值，而是多数稳定服务的临界信号。

vmstat 是最轻量、无需额外安装的入口工具，它输出的 cs（context switch）字段就是每秒上下文切换总次数。

运行 vmstat 1，重点关注第三行开头的 cs 值；数值持续 >1000 表示系统调度压力明显升高
注意对比 r（就绪队列长度）和 b（不可中断进程数）：r 高 + cs 高 → 大量进程争抢 CPU；b 高 + cs 中等 → I/O 等待拖慢调度节奏，不是上下文切换本身的问题
vmstat 不区分自愿/非自愿切换，也不能关联到具体进程，仅用于“有没有问题”的快速判断

要查清楚谁在频繁切换、为什么切，必须用 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 核数

有些场景下 vmstat 或 pidstat 显示的峰值只是几秒抖动，未必反映真实负载。这时直接读内核统计更可靠：

Docker Desktop（linux）

当前 Docker 最新稳定版本之一，主要针对稳定性和兼容性进行了修复优化，适合生产环境与日常开发使用。该版本继续强化 AI 开发支持、容器日志管理以及 Docker Engine 的安全能力，对 Windows/macOS/Linux 平台兼容性进行了进一步优化。

下载

上下文切换高只是表象，背后常混着线程模型、锁、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）

真正难的是区分“切换多是因为业务重”，还是“切换多是因为设计烂”。前者加机器能缓解，后者不改代码永远治标不治本。

《如何在Linux中查看CPU的上下文切换次数 Linux分析多线程性能的方法.doc》

下载本文的Word格式文档，以方便收藏与打印。