3. 调度器核心原理：调度器的职责、调度时机与上下文切换开销
各位同学，今天我们来聊聊调度器。说实话，调度器是实时操作系统的灵魂。我做了这么多年嵌入式，见过太多系统因为调度策略没选好而翻车。嗯，咱们今天就把调度器的老底儿给揭了。
3.1 调度器的职责——它到底在忙什么？
调度器的职责，说白了就三件事：选谁跑、怎么切、切多快。
- 任务选择：从就绪队列里挑一个优先级最高的任务。我习惯用位图法来加速查找，尤其是任务数多的时候，O(1)的复杂度真香。
- 资源分配：CPU只有一个，谁用谁不用，调度器说了算。你想想看，如果两个任务都抢CPU，没个裁判怎么行？
- 时间管理：每个任务跑多久？时间片到了怎么办？这些都是调度器的活儿。
核心要点：调度器不是万能的，但没有调度器是万万不能的。它的核心目标就一个——保证高优先级任务及时响应。
3.2 调度时机——什么时候触发调度？
调度不是随时都能发生的。我见过新手写代码，在中断里直接调调度函数，结果系统直接崩了。为什么会这样？因为调度时机是有讲究的。
3.2.1 时钟中断——最常用的调度触发器
时钟中断就像系统的「心跳」。每次滴答一声，调度器就醒过来看看：有没有更高优先级的任务需要跑？
// 典型的时钟中断处理流程
void SysTick_Handler(void) {
// 保存当前任务上下文
save_context(current_task);
// 更新任务时间片
current_task->remaining_ticks--;
// 如果时间片用完，触发调度
if (current_task->remaining_ticks == 0) {
need_schedule = 1;
}
// 恢复新任务上下文
restore_context(next_task);
}
我在项目中遇到过一个问题：时钟中断频率设得太高（1ms一次），结果调度开销占了CPU的30%。后来改成5ms一次，系统瞬间流畅了。所以啊，时钟中断频率不是越高越好。
3.2.2 任务主动挂起——自愿让出CPU
有时候任务自己知道该歇会儿了。比如等待一个外设数据，或者延时一段时间。这时候调用 task_yield() 或者 task_sleep()，主动把CPU让出来。
我的经验：主动挂起比被动抢占更高效。因为任务知道自己什么时候该停，省去了时钟中断的检查开销。我曾经在一个低功耗项目里，全靠任务主动挂起，把系统功耗降了40%。
3.2.3 其他调度时机
- 中断退出时：中断服务程序跑完了，要不要切回原来的任务？还是跑更高优先级的？
- 任务创建/删除时：新任务优先级更高？那得赶紧切过去。
- 资源释放时：信号量、消息队列等资源被释放了，可能有更高优先级的任务在等。
3.3 上下文切换开销——看不见的性能杀手
上下文切换，说白了就是「保存现场、恢复现场」。每次切换，CPU都要把当前任务的寄存器、堆栈指针、状态字等一股脑儿存起来，再把新任务的这些玩意儿恢复回去。
你想想看，这中间有多少操作？我算过一笔账：
| 操作 | CPU周期数（ARM Cortex-M4） | 说明 |
|---|---|---|
| 保存通用寄存器（R0-R12） | ~50 | 13个寄存器，每个约4周期 |
| 保存特殊寄存器（LR, PC, xPSR） | ~15 | 硬件自动压栈 |
| 保存FPU寄存器 | ~100 | 如果有FPU，开销翻倍 |
| 切换堆栈指针 | ~5 | 改SP寄存器 |
| 恢复新任务上下文 | ~70 | 和保存对称 |
| 总计 | ~240周期 | 约3μs @ 80MHz |
避坑指南：我曾经在一个项目中，任务切换频率高达10kHz（每100μs切一次）。结果上下文切换开销占了CPU的30%！后来我把任务合并，切换频率降到1kHz，CPU利用率直接降到3%。
3.4 知识体系总览
下面这张图，是我自己总结的调度器核心逻辑。你看一眼，基本就明白调度器是怎么工作的了。
3.5 总结与思考
调度器这东西，看着简单，但坑不少。我总结几个要点：
- 调度时机要精准：不是所有地方都能调度的，中断里尤其要小心。
- 上下文切换开销要量化：别光看代码，拿示波器量一下实际耗时。
- 任务数量要控制：任务越多，调度开销越大。我一般建议不超过32个任务。
一个小技巧：如果你用的是FreeRTOS，可以打开 configUSE_TRACE_FACILITY 和 configUSE_STATS_FORMATTING_FUNCTIONS，用 vTaskGetRunTimeStats() 看看每个任务占了多少CPU。这招我屡试不爽。
好了，调度器的核心原理就聊到这儿。记住一句话：调度器不是越快越好，而是越准越好。下一节咱们聊聊具体的调度算法，看看FIFO、RR、优先级调度到底怎么选。
公众号:蓝海资料掘金营，微信deep3321