第4章任务创建与删除

4、任务创建与删除：动态创建 vs 静态创建，任务堆栈大小估算，任务删除的陷阱

各位同学，咱们今天聊点实在的。任务创建与删除，这几乎是每个RTOS开发者入门就要碰到的操作。但说实话，我见过太多人在这一步栽跟头了。不是堆栈爆了，就是任务删了系统崩了。今天我就把这里面的门道，掰开了揉碎了讲给你听。

4.1 动态创建 vs 静态创建：到底选哪个？

先说说这两种创建方式。动态创建，就是用 xTaskCreate() 这类API，让系统在运行时从堆里给你分配任务控制块（TCB）和堆栈。静态创建呢，你得自己提前准备好这些内存，然后通过 xTaskCreateStatic() 把地址传进去。

我个人习惯，在项目初期或者原型验证阶段，喜欢用动态创建。为啥？省事啊！你想想看，我只需要关心任务函数和优先级，内存分配的事交给RTOS去操心。但到了产品定型阶段，我几乎全换成静态创建。

这里有个真实案例。我之前做的一个车载网关项目，MCU是瑞萨的RH850。初期用动态创建跑得挺好，结果一上EMC测试，偶尔会出现任务创建失败。查了半天，原来是堆碎片化导致的。你想想看，在车载这种高可靠性场景下，这种不确定性是不能接受的。

  核心区别总结：
  动态创建：灵活，但存在运行时分配失败的风险，适合原型验证
静态创建：确定性高，所有内存编译时已分配，适合量产产品

代码上怎么区分？看下面：

// 动态创建 - 系统自动分配TCB和堆栈
TaskHandle_t xTaskHandle = NULL;
xTaskCreate(vTaskFunction, "Task1", 256, NULL, 1, &xTaskHandle);

// 静态创建 - 用户自己提供内存
StaticTask_t xTaskBuffer;
StackType_t xTaskStack[256];
TaskHandle_t xTaskHandle = xTaskCreateStatic(
    vTaskFunction, "Task1", 256, NULL, 1, 
    xTaskStack, &xTaskBuffer
);

看到了吗？静态创建多出来的两个参数，就是你要提供的堆栈和TCB内存。嗯，这里要注意，StaticTask_t 这个结构体的大小，不同RTOS可能不一样，千万别想当然。

4.2 任务堆栈大小估算：别靠猜

说到堆栈大小，我见过太多人拍脑袋定个数。256？512？1024？问为什么，答不上来。这不行。

堆栈大小估算，说白了就是算清楚你的任务函数调用链上，所有局部变量、函数参数、返回地址、中断嵌套，加起来一共要占多少字节。

我一般用两种方法配合着来：

静态分析法：手动计算任务函数里所有局部变量的大小，加上函数调用深度。比如一个任务里调了3层函数，每层有4个参数和返回地址，再加上可能的中断嵌套，算个大概。
运行时监控法：让RTOS提供堆栈使用峰值。FreeRTOS里可以用 uxTaskGetStackHighWaterMark()，这个API会告诉你堆栈还剩多少没用。我习惯在任务里定期打印这个值，跑一段时间看看峰值。

我的经验公式：

估算值 × 1.5 = 最终配置值。为什么留50%余量？因为中断嵌套、浮点运算、调试信息打印这些，都会额外消耗堆栈。我曾经在某个项目里，就因为没留够余量，导致任务在特定中断组合下栈溢出，查了整整两天。

举个例子，一个简单的CAN报文收发任务：

void vCAN_Task(void *pvParameters) {
    uint8_t ucData[8];          // 8字节
    uint32_t ulMsgID;           // 4字节
    CAN_Message_t xMsg;         // 假设结构体32字节
    // 调用CAN驱动函数，内部可能还有局部变量
    // 加上函数调用返回地址，约20字节
    // 总估算：8+4+32+20 = 64字节
    // 留余量：64 × 1.5 = 96字节，取整128
}

你看，这样算出来是128，而不是随便写个256。虽然最终可能还是256，但至少你知道为什么是256。

4.3 任务删除的陷阱：删了不等于没了

任务删除，看似简单，一个 vTaskDelete() 就完事了。但这里面的坑，我踩过不止一次。

陷阱一：删除后资源没释放

动态创建的任务，调用 vTaskDelete() 后，TCB和堆栈内存并不会立即归还给系统。FreeRTOS里，这些内存要等到空闲任务（Idle Task）运行时才会被回收。如果你连续创建删除任务，而空闲任务优先级太低没机会跑，内存就泄漏了。

我曾经在一个项目里，需要动态创建临时任务处理数据，处理完就删掉。结果跑了几个小时，系统突然创建任务失败。一查，堆被吃光了。解决办法？要么提高空闲任务优先级，要么在删除后主动调用 taskYIELD() 让空闲任务有机会运行。

陷阱二：任务删除时的临界资源

如果一个任务正拿着互斥锁，或者正操作某个共享缓冲区，你把它删了。嗯，后果很严重。那个互斥锁永远没人释放了，其他任务会永久阻塞。我建议的做法是：给任务发一个退出信号，让任务自己清理完资源再调用 vTaskDelete(NULL) 删除自己。

陷阱三：删除自己 vs 删除别人

任务可以删除自己，也可以删除其他任务。删除自己时，参数传NULL就行。但删除别人时，你得确保那个任务确实存在，而且不会引起死锁。我一般只在任务自己退出时用自删除，跨任务删除能不用就不用。

看一个安全的删除模式：

void vTaskFunction(void *pvParameters) {
    // 等待退出信号
    while(1) {
        if(xTaskNotifyWait(0, 0, NULL, portMAX_DELAY) == pdTRUE) {
            // 收到退出信号，先释放资源
            vReleaseMutex(xMutex);
            vReleaseBuffer(xBuffer);
            // 然后删除自己
            vTaskDelete(NULL);
        }
        // 正常任务处理...
    }
}

这种模式，任务收到通知后，自己清理、自己退出，干净利落。

4.4 实战建议：什么时候用什么方式

最后，我给大家一个参考表格，是我多年项目经验的总结：

场景	推荐方式	理由
系统初始化时创建的核心任务	静态创建	确定性高，不会因堆碎片失败
运行时按需创建的临时任务	动态创建	灵活，用完即删，节省内存
中断中创建任务	动态创建	静态创建需要提前分配，中断中不适合
安全关键功能（如刹车控制）	静态创建	必须保证创建成功，不能有运行时失败
调试阶段	动态创建	方便调整任务数量和堆栈大小

好了，关于任务创建与删除，核心就是这些。记住一句话：创建时多算算堆栈，删除时多想想资源。这两个地方不出问题，你的RTOS系统就稳了一大半。