——从 vmstat 到调度器行为的全链路解读
多任务操作系统的光辉幻术，是它能让每个程序都感觉自己独占整台机器。撑起这个幻术的，是 CPU 上下文切换（context switch）。上一节我们拆解了上下文切换本身的内部构造：寄存器、内核栈、页表等不同层次的状态迁移；也区分了三条路径：进程上下文切换、线程上下文切换与中断上下文切换。
理解它们的机制只是开篇，真正考验工程师水平的，是当系统负载偏高、性能暴跌、响应时间异常波动时，你能否在第一时间知道：
问题是否来自过量的上下文切换？
是哪一类切换？
是谁在制造切换？
问题发生在哪个资源层次？
这一节，我们就用更偏实战的视角，讲清楚“怎么看”“怎么分析”“怎么定位”。
一、为什么上下文切换需要被监控？
上下文切换本身不是坏事，它是让多任务系统得以存在的基础。但切换不是免费的。每次切换都意味着：
- 保存上一任务的寄存器、状态、页表（TLB 失效）
- 加载新任务的对应信息
- 刷新 CPU cache、TLB，迫使缓存亲和性降低
- 调度器需要重新决策，消耗调度时间片
换句话说，上下文切换越多，CPU 越忙于“整理桌面”，越没时间“真正干活”。
现代 Linux 的 CFS 调度器（Completely Fair Scheduler）进一步强化了这一点：它会频繁调整任务的 vruntime（一种虚拟运行时间），试图让所有任务公平共享 CPU，公平越强烈，调度动作越频繁。如果系统里任务数庞大、I/O 密集、线程模型设计不良，CFS 的调度压力会指数级放大。
于是就有了我们需要“观察”和“诊断”的理由。
二、如何观察系统的上下文切换情况？
站在系统层面，上下文切换最直接的观测工具就是 vmstat。
试运行：
vmstat 5
示例输出：
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 7005360 91564 818900 0 0 0 0 25 33 0 0 100 0 0
四个最关键的列：
1. cs —— 每秒上下文切换次数（context switch）
系统是否“忙于切换任务”就看它。
经验值：
- 几百：正常，轻载系统
- 数千：可能存在大量线程调度或 I/O 阻塞
- 几万：系统已经出现性能瓶颈
- 十万以上：极大概率存在锁竞争、过度线程化、中断风暴等问题
2. in —— 每秒中断次数（interrupt）
用于判断：
- 硬件中断是否异常（网卡、磁盘产生风暴）
- 高频 I/O 是否导致软中断（softirq）堆积
高 in 不一定是坏事，但高 in + 高 CPU sys 就很值得注意。
3. r —— 运行队列长度（run queue）
代表正在运行或等待 CPU 的任务。
- r ≈ CPU 核数：良好
- r 大幅超过 CPU 核数：可能出现 CPU 争抢
- r 上千：系统已无法实时处理任务
4. b —— 不可中断状态（blocked）
主要用于检测：
- 磁盘 I/O 卡顿
- NFS、块设备异常
- 内核等待 I/O
b 长期不为 0，说明有任务被卡在内核 I/O 路径。
三、vmstat 只是入口：更细粒度的分析方法
vmstat 告诉你 有问题，但它并不知道是谁制造的切换。
真正的工作从这里开始。
四、谁在制造上下文切换？
答案来自 pidstat。
运行：
pidstat -w 5
关键输出列：
- cswch/s（voluntary context switch）
主动让出 CPU，比如线程 sleep、等待锁、等待 I/O。 - nvcswch/s（non-voluntary context switch）
被动调度，比如时间片耗尽、优先级被抢占。
如何理解？
主动切换高：
→ 应用设计问题（锁竞争、协程 yield 频繁、I/O 等待）
被动切换高：
→ CPU 竞争、线程过多、调度器负担重
这是判断应用层问题 vs 系统层问题的核心指标。
五、深入内核：从 /proc 出发
Linux 内核对每个线程的切换次数都记录在：
cat /proc/<pid>/task/<tid>/status
能看到：
voluntary_ctxt_switches: 1234
nonvoluntary_ctxt_switches: 5678
特别适用于跟踪 Java、Go、Nginx 等多线程程序。
如果看到某线程的 nonvoluntary 飙高：
那几乎可以肯定是线程数太多或 CPU 不够。
六、中断风暴：/proc/interrupts
当 vmstat 的 in 异常升高，你需要查看哪个硬件在制造中断：
cat /proc/interrupts
如果看到类似：
eth0: 123456 98765 112233 ...
nvme0: 987654 ...
说明网卡或磁盘在进行高频中断。
现代内核通常启用 中断合并（Interrupt Coalescing） 来减少中断频率，但如果配置不当（如高 TPS 的数据库服务器），中断会成为瓶颈。
七、CPU 调度器本身可能是瓶颈
CFS 调度器在面对：
- 大量线程
- 短生命周期任务
- 多核间频繁迁移
- CPU cache 不亲和
时，会大量触发 non-voluntary 切换。为了公平，CFS 会不断重新排序 vruntime，触发调度。
你可以用：
schedstat
或开启：
kernel.sched_debug
来观察调度器自身是否成为性能瓶颈。
八、上下文切换问题的典型根因
从线上经验来看，上下文切换暴涨通常来自三类问题：
1. 线程数量远大于 CPU 核数
Go、Java 线程池、协程调度器不合理，都是高发地带。
2. 大量短生命周期任务
Kafka 消费者频繁 rebalance、任务队列处理微任务，CFS 会忙到飞起。
3. 中断风暴
网卡、SSD、高速 I/O 很容易导致这种情况。
九、总结：上下文切换从“现象”到“原因”再到“解决”
上下文切换是多任务时代的代价，也是系统性能问题的放大镜。
你可以按下面的链路排查：
- vmstat：系统总览，判断是否存在异常
- pidstat -w：找出制造切换的具体进程
- /proc/*/status：确认是主动切换还是被动切换
- /proc/interrupts：排查是否是中断风暴
- 调度器调试信息：判断是否是系统层调度瓶颈
- 回到应用层：从线程、锁、I/O、队列、连接池等角度优化
上下文切换不是复杂概念，但它牵扯的层级极深——CPU、内核、调度器、应用框架。真正掌握它，你能看到系统运行的立体结构，而不仅仅是表象的 load average 或 CPU 使用率。
