任务调度基础：操作系统调度器原理、上下文切换开销、调度延迟分析

调度器，说白了就是操作系统的「交通警察」。它决定哪个任务先跑、哪个任务后跑、跑多久让位。我早年做嵌入式实时系统时，总觉得调度是内核的事，应用层不用管。直到有一次，一个视频采集任务因为调度延迟过大，丢了一帧关键数据……嗯，从那以后，我再也不敢轻视调度器了。

调度器核心原理：谁来决定下一个？

调度器的工作可以拆成三个步骤：选任务、切上下文、恢复执行。你想想看，这其实和你在办公室排队用打印机差不多——谁先来、谁优先级高、谁占的时间长，都得有个规则。

常见的调度策略，我按实际项目中的使用频率排个序：

调度策略	核心逻辑	典型场景	我踩过的坑
时间片轮转（RR）	每个任务分一个固定时间片，轮流执行	通用操作系统（Linux 默认 CFS 也类似）	时间片设太短，系统吞吐量直接腰斩
优先级抢占	高优先级任务随时打断低优先级任务	实时系统（FreeRTOS、VxWorks）	优先级反转导致高优先级任务被「饿死」
截止时间优先（EDF）	谁最接近截止时间，谁先跑	硬实时多媒体处理	过载时系统崩溃，没有优雅降级
多级反馈队列	动态调整优先级，I/O 密集型任务优先	Linux、Windows 通用调度	交互任务响应慢，原来是队列参数没调好

上下文切换：看不见的性能杀手

上下文切换，就是 CPU 从一个任务换到另一个任务时，保存现场、恢复现场的过程。听起来简单，但开销比你想象的大得多。

我曾在一次性能调优中，发现系统 30% 的 CPU 时间都花在了上下文切换上。当时我还不信，直到用 perf 工具抓了一把，才确认问题。

一次完整的上下文切换，到底干了什么？

1. 保存当前任务上下文：寄存器、程序计数器、栈指针、内存映射（MMU）、浮点寄存器……
2. 更新调度数据结构：把当前任务放回就绪队列，选下一个任务。
3. 切换地址空间：如果两个任务属于不同进程，需要刷 TLB（快表），这个开销最大。
4. 恢复新任务上下文：把之前保存的寄存器、栈指针等全部装回去。
5. 跳转到新任务执行：CPU 开始跑新任务的代码。

你看，这可不是简单的「换个人」——每次切换都涉及几十甚至上百条指令。我测过一个典型数据：

切换类型	开销（微秒）	主要瓶颈
线程切换（同进程）	1-3 µs	寄存器保存/恢复
进程切换（不同进程）	3-10 µs	TLB 刷新 + 地址空间切换
系统调用（不切换任务）	0.2-0.5 µs	用户态/内核态切换

调度延迟分析：从「请求」到「执行」到底有多远？

调度延迟，指的是一个任务从「就绪」到「真正开始执行」的时间差。这个指标在实时系统中是生死攸关的——如果延迟超过截止时间，系统就出错了。

调度延迟由三部分组成：

• 中断延迟：从硬件中断触发到 CPU 开始处理中断服务程序。这个受中断屏蔽、中断优先级影响。
• 调度决策时间：调度器从就绪队列中选任务的时间。如果队列里有几百个任务，这个时间不可忽略。
• 上下文切换时间：上面讲过的，保存/恢复现场的时间。

我画了一张图，帮你理清调度延迟的全链路：

从图上你能看到，调度延迟不是单一指标，而是一条链。任何一个环节出问题，都会拖累整体响应。

如何测量调度延迟？

光说不练假把式。我分享一个在 Linux 下实测调度延迟的方法：

// 使用 cyclictest 测量调度延迟
// 安装：apt-get install rt-tests

// 运行：测量实时线程的调度延迟
cyclictest -t 1 -p 99 -i 1000 -l 10000

// 输出示例：
// T: 0 (0) P: 99 I: 1000 C: 10000 Min: 2 Act: 5 Avg: 4 Max: 18

这个工具会创建一个高优先级实时线程，每隔 1ms 醒来一次，记录实际唤醒时间与预期时间的差值。Min/Act/Avg/Max 分别代表最小、当前、平均、最大延迟。

减少调度延迟的实战技巧

说了这么多问题，总得给点解法。我总结了几条经过验证的优化手段：

• 减少中断屏蔽时间：中断服务程序只做最紧急的事，把耗时操作推到下半部（tasklet/workqueue）。
• 使用实时优先级：对时间敏感的任务，设置实时优先级（SCHED_FIFO 或 SCHED_RR），避免被普通任务干扰。
• 绑定 CPU 核心：把关键任务和它的中断绑定到同一个 CPU 核心，减少缓存迁移开销。
• 控制任务数量：就绪队列里任务越多，调度决策时间越长。能合并的任务尽量合并。
• 避免频繁创建/销毁线程：线程池是好朋友，别每次都 new thread。