4、任务管理与调度：任务状态机、优先级抢占、时间片轮转与调度延迟分析

各位同学，大家好。今天我们聊一个非常核心的话题——任务管理与调度。说实话，在自动驾驶系统里，调度器就是整个系统的“交通警察”。如果它指挥不好，任务该跑的时候没跑，不该跑的时候抢了CPU，那后果可能是灾难性的。

我个人习惯把任务调度比作一个繁忙的十字路口。有的车（任务）是救护车，必须优先通过；有的车是普通私家车，可以等一等；还有的车停在路边（挂起），暂时不动。怎么管好这个路口，就是我们今天要讲的。

4.1 任务状态机：从生到死的四个状态

每个任务在它的生命周期里，会经历四种状态。我在项目中遇到过不少新手，搞混了“阻塞”和“挂起”，结果调试了一整天。我们先把这个基础打牢。

状态	含义	典型场景
就绪（Ready）	任务已准备好运行，只等CPU	等待调度器选中它
运行（Running）	任务正在占用CPU执行	正在处理传感器数据
阻塞（Blocked）	任务因等待某事件而暂停	等待CAN总线消息、等待信号量
挂起（Suspended）	任务被强制暂停，不参与调度	调试时手动暂停、低功耗模式

这里有个关键点：阻塞是主动或被动等待资源，挂起是被系统或用户强制停止。你想想看，一个任务在等刹车信号，它处于阻塞态，这是正常的。但如果调试时你把它挂起了，它连等的机会都没有。

4.2 优先级抢占调度：谁急谁先跑

在自动驾驶中，优先级抢占调度是绝对的主流。说白了，就是高优先级的任务可以“抢”低优先级任务的CPU使用权。

我曾经在一个项目中，把CAN报文接收任务的优先级设得比控制任务还高。结果呢？控制任务老是跑不出来，车辆在测试时出现了明显的延迟。嗯，这就是典型的“优先级反转”前兆。

优先级调度的核心规则很简单：

• 就绪队列中，优先级最高的任务先运行
• 如果高优先级任务就绪，立即抢占当前运行的低优先级任务
• 同优先级任务，按时间片轮转或FIFO处理

4.3 时间片轮转：公平但不绝对

当多个任务优先级相同时，就需要时间片轮转（Round-Robin）了。每个任务轮流跑一小段时间，比如10毫秒，然后切换给下一个。

你可能会问：“自动驾驶里需要公平吗？” 说实话，大部分时候不需要。但有一种情况很典型：多个传感器数据采集任务，优先级相同，谁也不比谁更重要。这时候时间片轮转就派上用场了。

我记得有一次调试激光雷达和摄像头的数据同步问题。两个采集任务优先级相同，但时间片设置得太短（2ms），导致频繁切换，缓存老是写不完。后来我把时间片调到20ms，问题就解决了。

4.4 调度延迟分析：看不见的杀手

调度延迟，说白了就是从“任务应该运行”到“任务真正开始运行”之间的时间差。在自动驾驶中，这个延迟可能是致命的。

调度延迟主要由三部分组成：

1. 中断延迟：从硬件中断发生到CPU开始处理中断服务程序
2. 调度决策时间：调度器从当前任务切换到下一个任务所需的时间
3. 上下文切换时间：保存当前任务状态、恢复新任务状态的时间

我给大家一个实际数据：在一个基于Cortex-M7的自动驾驶域控制器上，我测过FreeRTOS的调度延迟。在无中断干扰的情况下，从高优先级任务就绪到开始运行，大约需要3-8微秒。但如果此时正在处理一个长中断，延迟可能飙升到50微秒以上。

4.5 避坑指南：我踩过的三个坑

讲了这么多理论，最后分享几个实战教训。

第一个坑：优先级反转

我曾经在一个项目中，低优先级的任务持有了一个互斥锁，高优先级任务在等这个锁，结果中优先级任务一直运行，导致高优先级任务被“饿死”。解决方案很简单：使用优先级继承协议，或者干脆用无锁队列。

第二个坑：任务栈溢出

调度器本身不会检查栈溢出。有一次我的任务在运行时栈溢出了，覆盖了相邻任务的TCB（任务控制块），结果系统随机崩溃。从那以后，我每个任务都至少留30%的栈余量，并开启栈溢出检测钩子函数。

第三个坑：时间片设置不合理

前面提到了，时间片太短导致切换频繁。还有一个极端情况：时间片太长，低优先级任务被饿死。我建议在系统启动后，用逻辑分析仪抓一下任务切换波形，看看实际调度行为是否符合预期。

4.6 小结

任务管理与调度是RTOS的“心脏”。任务状态机让你知道任务在干什么，优先级抢占保证关键任务及时响应，时间片轮转处理同优先级任务的公平性，而调度延迟分析则是衡量系统实时性的标尺。

在自动驾驶中，我建议你记住一句话：调度器的设计目标不是“快”，而是“可预测”。宁可慢一点，也要保证每个关键任务在最坏情况下都能按时完成。

下一章我们会讲任务间通信与同步，到时候再聊聊信号量、消息队列这些“交通信号灯”怎么用。今天就到这里，有问题随时交流。