📚 课程目录第4章任务创建与删除

4. 任务创建与删除：API函数（如xTaskCreate）、动态与静态创建、内存管理风险

任务（Task）是RTOS中调度的基本单元。任务的创建与删除是嵌入式系统开发中最频繁的操作之一，也是缺陷的高发区。FreeRTOS等主流RTOS提供了xTaskCreate（动态创建）和xTaskCreateStatic（静态创建）两套API，二者在内存管理策略上存在本质差异，选择不当将直接导致内存泄漏、栈溢出或系统崩溃。

4.1 动态创建：xTaskCreate 与内存堆管理

xTaskCreate 是使用最广泛的任务创建函数。它从RTOS管理的堆（Heap）中自动分配任务控制块（TCB）和任务栈空间。其函数原型如下：

BaseType_t xTaskCreate(
    TaskFunction_t pvTaskCode,      // 任务函数指针
    const char * const pcName,      // 任务名称（仅用于调试）
    configSTACK_DEPTH_TYPE usStackDepth, // 栈深度，单位是字（Word）
    void *pvParameters,             // 传递给任务函数的参数
    UBaseType_t uxPriority,         // 任务优先级
    TaskHandle_t *pxCreatedTask     // 返回的任务句柄
);

关键参数说明： usStackDepth 的单位是 字（Word），而非字节。在32位MCU上，1字 = 4字节。若传入1024，实际分配的栈空间为4096字节。这是新手最容易犯的错误——栈深度计算偏差导致栈溢出。

动态创建依赖RTOS的堆管理方案（heap_1.c ~ heap_5.c）。不同方案的内存碎片化风险差异显著：

堆方案	分配策略	释放支持	碎片化风险	典型场景
heap_1	简单数组 + 线性分配	不支持	无（不释放）	系统启动后不再删除任务
heap_2	最佳匹配链表	支持	高（易产生外部碎片）	不推荐在新项目中使用
heap_3	包装标准 malloc/free	支持	取决于编译器实现	需要与标准库共享堆
heap_4	首次匹配 + 相邻空闲块合并	支持	中（合并机制缓解碎片）	推荐默认方案
heap_5	多区域非连续堆	支持	中（同heap_4）	多个物理内存区域

内存管理风险警示： 频繁使用 xTaskCreate 和 vTaskDelete 配对操作时，即使使用heap_4，若任务栈大小差异过大，仍可能产生不可回收的碎片。建议：① 优先使用静态创建；② 若必须动态创建，任务栈大小尽量统一；③ 避免在中断服务函数中创建或删除任务。

4.2 静态创建：xTaskCreateStatic 与确定性内存

xTaskCreateStatic 要求调用者预先分配TCB和栈空间，RTOS不再参与堆管理。这消除了动态内存分配的不确定性，是安全关键系统（如汽车、医疗）的首选方案。

TaskHandle_t xTaskCreateStatic(
    TaskFunction_t pvTaskCode,
    const char * const pcName,
    configSTACK_DEPTH_TYPE usStackDepth,
    void *pvParameters,
    UBaseType_t uxPriority,
    StackType_t *puxStackBuffer,    // 用户提供的栈缓冲区
    StaticTask_t *pxTaskBuffer      // 用户提供的TCB缓冲区
);

  静态创建的优势：
  零碎片： 内存完全由开发者管理，不存在堆碎片问题。
确定性： 创建时间恒定，无内存分配失败风险。
可调试性： 栈和TCB地址在编译期即确定，便于静态分析。
RAM使用透明： 通过链接脚本或全局数组即可统计所有任务的内存占用。

静态创建的典型实现方式：

// 在文件作用域或全局作用域预分配
static StackType_t task1Stack[configMINIMAL_STACK_SIZE];
static StaticTask_t task1TCB;

void AppInit(void)
{
    TaskHandle_t xHandle = NULL;
    xHandle = xTaskCreateStatic(
        vTaskFunction,      // 任务函数
        "Task1",            // 任务名
        configMINIMAL_STACK_SIZE, // 栈深度
        NULL,               // 参数
        1,                  // 优先级
        task1Stack,         // 栈缓冲区
        &task1TCB           // TCB缓冲区
    );
    configASSERT(xHandle != NULL);
}

4.3 动态 vs 静态：选择决策树

以下SVG图展示了在项目设计阶段如何根据约束条件选择任务创建方式：

4.4 任务删除与资源回收陷阱

vTaskDelete 用于删除一个已创建的任务。删除操作本身并不复杂，但其引发的资源回收问题却是RTOS缺陷的重灾区。

void vTaskDelete(TaskHandle_t xTaskToDelete);

删除任务的三大陷阱：

栈内存泄漏： 动态创建的任务被删除后，其TCB和栈空间会归还给堆。但如果堆方案不支持释放（如heap_1），则内存永久泄漏。
资源未释放： 任务持有的互斥量、信号量、队列、动态分配的内存等，在任务删除时不会自动释放。必须由任务在退出前自行清理。
悬空指针： 其他任务或ISR中仍持有被删除任务的句柄，后续使用该句柄将导致未定义行为。

安全删除任务的推荐流程：

通知协作退出： 通过标志位或通知机制，让目标任务自行退出其主循环。
清理持有资源： 任务在退出前释放所有动态分配的内存、关闭文件描述符、归还内核对象。
调用 vTaskDelete(NULL)： 任务在自身上下文中调用 vTaskDelete(NULL) 删除自己。
句柄置空： 所有持有该任务句柄的模块，在收到任务退出通知后将句柄置为NULL。

4.5 内存管理风险全景图

以下SVG图展示了任务创建/删除过程中内存管理风险的完整链路：

4.6 典型缺陷案例：栈溢出与内存泄漏

案例1：栈深度单位误解导致栈溢出

某团队在STM32F4平台上使用xTaskCreate创建任务，传入usStackDepth = 256，期望分配256字节栈空间。实际分配了256×4=1024字节。任务实际栈使用量约800字节，未触发溢出。但当移植到Cortex-M0+平台（32位）时，同样代码仍分配1024字节，但任务栈使用量未变，系统运行正常。然而，当团队将代码移植到16位MCU时，usStackDepth = 256仅分配512字节，任务立即栈溢出崩溃。

案例2：heap_1下动态删除导致永久泄漏

某IoT设备使用heap_1方案，设计时认为所有任务在系统生命周期内都不会被删除。后期需求变更，需要OTA升级后重启部分任务。开发人员直接调用vTaskDelete删除旧任务，再调用xTaskCreate创建新任务。由于heap_1不支持释放，每次OTA升级后可用堆内存减少约2KB，经过10次升级后系统因堆耗尽而无法创建新任务。

  缺陷根因总结：
  栈溢出： 对usStackDepth单位理解错误、未使用uxTaskGetStackHighWaterMark()进行栈使用量监测。
内存泄漏： 堆方案不支持释放、任务内资源未在退出前清理、句柄悬空后无法再释放。
碎片化： 频繁创建/删除不同栈大小的任务，堆管理算法无法合并空闲块。

建议在开发阶段启用configUSE_TRACE_FACILITY和configCHECK_FOR_STACK_OVERFLOW，结合vTaskGetInfo()和uxTaskGetStackHighWaterMark()定期监测每个任务的栈使用峰值，将监测数据通过调试串口输出，作为系统稳定性评估的依据。