4. 任务管理：任务状态机、任务创建/删除/挂起/恢复、任务优先级与调度策略
任务（Task）是RTOS中竞争CPU资源的基本执行单元，也是整个系统并发行为的载体。与裸机编程中“一个主循环+若干中断”的模型不同，RTOS将应用拆解为多个独立的任务，每个任务拥有自己的栈空间、优先级和状态。理解任务状态机的迁移条件、掌握任务生命周期管理API的语义，并正确配置优先级与调度策略，是构建稳定、可预测嵌入式系统的核心前提。本章将围绕任务状态机、任务管理API、优先级机制与调度策略四个维度展开，并结合实际工程案例说明常见的设计误区和调优方法。
上图展示了RTOS中任务的核心状态及迁移路径。一个任务从创建到销毁，始终在“运行态、就绪态、阻塞态、挂起态”之间流转。其中“就绪挂起”和“阻塞挂起”是组合状态，表示任务在挂起的同时原本所处的调度状态被冻结。理解这张图是掌握任务管理API的前提——每个API调用本质上都是触发一次状态迁移。
4.1 核心原理：任务状态机的设计逻辑
任务状态机是RTOS内核调度的基础模型。在单核CPU上，任意时刻只有一个任务真正占用处理器，该任务处于运行态。其他可被调度但未获得CPU的任务处于就绪态。当任务因等待某个事件（如信号量、消息队列、延时到期）而无法继续执行时，进入阻塞态。而挂起态则是一种人为的暂停——任务被显式地禁止调度，即使其等待的事件已经满足，也不会进入就绪态。
状态迁移的触发源分为三类：任务自身调用（如vTaskDelay()进入阻塞，vTaskSuspend()进入挂起）、其他任务或中断调用（如vTaskResume()恢复挂起任务，xSemaphoreGive()唤醒阻塞任务）、内核调度行为（如时间片轮转导致运行态→就绪态）。理解触发源有助于判断任务卡死的原因——例如一个任务既没有阻塞也没有挂起，却长期不运行，问题往往出在优先级配置或调度策略上。
4.2 任务创建、删除、挂起与恢复：API语义与操作流程
任务管理API是RTOS提供的最基础操作接口。以FreeRTOS为例，核心API包括：xTaskCreate()用于动态创建任务，vTaskDelete()用于删除任务，vTaskSuspend()挂起任务，vTaskResume()恢复任务。此外还有xTaskCreateStatic()用于静态创建（需用户提供栈空间），以及vTaskDelay()和vTaskDelayUntil()用于时间阻塞。
创建任务时，必须明确以下参数：任务函数入口、任务名称（仅用于调试）、栈深度（单位通常为字）、传入参数、优先级、任务句柄。栈深度的估算是一个常见难点——过小会导致栈溢出（系统崩溃），过大会浪费RAM。推荐使用内核提供的栈高水位标记功能（如uxTaskGetStackHighWaterMark()）在运行时检测实际使用量。
删除任务时需注意：任务不能删除自己后继续执行后续代码，因此vTaskDelete(NULL)通常放在任务函数的末尾。被删除任务持有的内核对象（如信号量、队列）不会自动释放，需要程序员在删除前手动清理。挂起与恢复操作则相对简单，但需注意在中断服务函数中只能使用xTaskResumeFromISR()，而不能直接调用vTaskResume()。
| API函数 | 功能 | 可调用上下文 | 注意事项 |
|---|---|---|---|
| xTaskCreate() | 动态创建任务 | 任务/初始化代码 | 需堆空间，失败返回errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY |
| vTaskDelete() | 删除任务 | 任务自身或其他任务 | 删除自身时需立即返回，不能访问已释放的栈 |
| vTaskSuspend() | 挂起任务 | 任务自身或其他任务 | 挂起自身后，该任务停止运行直到被恢复 |
| vTaskResume() | 恢复挂起任务 | 任务（非中断） | 不能用于恢复阻塞态任务 |
| xTaskResumeFromISR() | 从中断恢复任务 | 中断服务函数 | 返回pdTRUE表示需要上下文切换 |
| vTaskDelay() | 相对延时阻塞 | 任务自身 | 延时时间从调用时刻起算，受调度影响 |
| vTaskDelayUntil() | 延时阻塞 | 任务自身 | 用于固定周期执行，不受执行时间抖动影响 |
4.3 任务优先级与调度策略：抢占式、时间片与协作式
RTOS的调度策略决定了“就绪态任务中谁先运行”。绝大多数嵌入式RTOS（如FreeRTOS、RT-Thread、uC/OS-III）默认采用基于优先级的抢占式调度：高优先级任务就绪时，立即抢占当前运行的低优先级任务。相同优先级的任务则通过时间片轮转（Round-Robin）共享CPU，每个任务运行一个时间片（通常为1ms~10ms，由内核配置决定）。
优先级数值越小，优先级越低（FreeRTOS约定0为最低优先级）。设计优先级时需遵循以下原则：
- 实时性要求越高的任务，优先级越高。例如电机控制环（1kHz）应高于通信处理任务（10Hz）。
- 事件驱动型任务优先级高于轮询型任务。等待外部中断的任务应尽快响应。
- 避免优先级反转。当高优先级任务等待低优先级任务持有的资源时，需使用优先级继承或优先级天花板协议。
- 任务数量不宜过多。优先级数量有限（FreeRTOS最大255级），且过多的任务会增加调度开销和栈内存消耗。
调度策略的选择直接影响系统的实时性。抢占式调度保证了“最高优先级就绪任务总是运行”，但代价是低优先级任务可能被饿死。时间片轮转则保证了同优先级任务的公平性，但增加了上下文切换次数。协作式调度（非抢占）仅在任务主动让出CPU时切换，适用于对时序确定性要求极高且任务间配合紧密的场景，但现代RTOS中较少使用。
4.4 案例拆解：多传感器数据采集系统的任务设计
以一个典型的工业数据采集器为例，系统需要同时处理：温度传感器（采样率10Hz）、加速度计（采样率1kHz）、CAN总线通信（接收周期5ms）、人机交互按键（事件触发）。硬件平台为Cortex-M4 @ 168MHz，RAM 128KB，使用FreeRTOS。
初始设计：创建4个独立任务，优先级从高到低依次为：加速度计采集（优先级5）、CAN通信（优先级4）、温度采集（优先级2）、按键处理（优先级1）。所有任务均使用vTaskDelayUntil()实现周期执行。
运行现象：系统运行后，CAN通信偶尔出现帧丢失，且按键响应延迟达到200ms以上。通过vTaskGetRunTimeStats()查看CPU占用率，发现加速度计任务占用了约60%的CPU时间，且其实际执行时间波动较大（从0.3ms到1.2ms），原因是加速度计SPI读取时使用了阻塞式等待。
分析过程：加速度计任务优先级最高，且其执行时间不稳定，导致低优先级任务被频繁抢占。CAN通信任务虽然优先级较高，但每次被抢占后需要重新同步CAN控制器状态，造成帧间隔超时。按键任务优先级最低，在加速度计任务长时间占用CPU时被饿死。
优化措施：
- 将加速度计SPI读取改为DMA方式，CPU等待时间从1ms降至0.1ms，且执行时间稳定。
- 调整优先级：CAN通信提升至优先级6（高于加速度计），因为CAN帧丢失的后果比加速度计采样延迟更严重。
- 按键任务改为中断触发+信号量唤醒，不再使用轮询，优先级降至最低（优先级0）。
- 为加速度计任务增加执行时间监控，若单次执行超过1.5ms则记录错误日志。
优化结果：CAN帧丢失率降为0，按键响应时间稳定在10ms以内，CPU总占用率从85%降至45%。
复盘经验：优先级设计不是静态的，需要结合任务的执行时间、资源占用和业务重要性动态调整。高优先级任务必须“短小精悍”，避免长时间占用CPU。使用DMA、中断等硬件机制减少任务阻塞时间，是提升RTOS多任务效率的关键手段。
4.5 常见误区与总结复盘
在任务管理实践中，以下误区值得特别警惕：
- 误区一：任务越多越好。每个任务至少需要独立的栈空间（通常512B~2KB），任务过多会导致RAM耗尽，且调度开销增大。建议将功能相关的操作合并为一个任务，通过状态机管理。
- 误区二：优先级越高越好。过高的优先级会导致低优先级任务饿死，且高优先级任务中的任何阻塞操作（如等待信号量）都会阻塞整个系统。优先级应“够用即可”。
- 误区三：vTaskDelay()用于精确计时。vTaskDelay()是相对延时，实际唤醒时间受任务调度延迟影响。需要固定周期执行时应使用vTaskDelayUntil()或定时器。
- 误区四：在中断中调用非ISR安全API。如vTaskResume()、xQueueSend()（非ISR版本）会导致内核崩溃。必须使用带FromISR后缀的API。
- 误区五：删除任务后不清理资源。任务持有的堆内存、信号量、队列等不会自动释放，需在删除前手动释放，否则造成内存泄漏。
vTaskList()）定期输出任务状态、栈高水位和CPU占用率，便于在开发阶段快速定位问题。同时，为每个任务设置看门狗监控，若任务超过预期时间未运行，则触发复位或错误处理。
任务管理是RTOS应用设计的基石。掌握状态机的迁移逻辑，熟练运用任务生命周期API，合理配置优先级与调度策略，并规避常见的设计陷阱，才能构建出响应及时、运行稳定、资源高效的嵌入式系统。在实际项目中，建议先画出任务状态迁移图，再编写代码，这样能显著减少因任务交互导致的隐性缺陷。