第四章 任务创建与销毁：任务栈分配策略、任务入口函数设计、任务删除与资源回收
好，我们接着聊任务创建与销毁。这部分内容，说白了就是RTOS里最基础、但也最容易踩坑的地方。我刚开始做车载项目时，就因为在任务栈分配上偷了个懒，结果系统跑着跑着就莫名其妙地挂了。嗯，从那以后，我对这块就格外上心。
4.1 任务栈分配策略：给每个任务一个合适的“家”
任务栈，就是任务运行时用来存放局部变量、函数调用信息的地方。你想想看，每个任务都是一个独立的执行流，它得有自己的栈空间，不然一调用函数就把别人的数据给覆盖了。
栈分配的核心问题就一个：给多大才合适？
给大了，浪费内存。车载系统里，内存可是稀缺资源，尤其是那些跑在MCU上的RTOS，总共就几百KB的RAM。给小了，栈溢出，系统直接崩溃。我在项目中遇到过，一个任务在正常路径下跑得好好的，但某个异常分支里递归调用了两次，栈就爆了。查这种bug，真的让人头大。
4.1.1 静态分配 vs 动态分配
RTOS里，栈分配通常有两种方式：
- 静态分配：编译时就确定栈大小和位置。比如在FreeRTOS里，你可以定义一个静态数组作为栈：
StackType_t xTaskStack[ configMINIMAL_STACK_SIZE ];。这种方式确定性高，没有运行时开销，我个人的习惯是，在车载安全相关的任务上，一律用静态分配。 - 动态分配：任务创建时从堆里分配栈空间。优点是灵活，缺点是可能分配失败，而且会有碎片问题。你想想看，如果系统跑了几天后，堆碎片化严重，一个新任务创建时分配不到连续的栈空间，那可就麻烦了。
核心原则：在车载领域，我建议安全等级高的任务（比如ASIL-B及以上）使用静态栈分配。普通任务可以用动态分配，但一定要检查返回值。
4.1.2 栈大小估算：别靠猜，要算
很多新手喜欢拍脑袋定栈大小，比如“这个任务简单，给256字节就够了”。嗯，这是大忌。我曾经见过一个项目，就因为这种“拍脑袋”行为，导致产品在客户现场频繁死机。
正确的做法是：
- 分析任务的最大调用深度：画出任务的函数调用树，找出最深的那条路径。
- 计算每个函数的栈帧大小：局部变量、参数、返回地址等。可以用编译器生成的map文件来辅助分析。
- 加上中断嵌套的栈开销：如果任务执行中可能被中断打断，中断服务程序也会使用当前任务的栈。
- 留出安全余量：我一般会多给20%-30%的余量，用于应对一些极端情况。
举个例子，一个简单的CAN报文接收任务：
// 任务入口函数
void vCANReceiveTask(void *pvParameters) {
CANMessage_t xMsg;
while(1) {
// 从硬件FIFO读取报文
if( xCANReceive(&xMsg) == pdTRUE ) {
// 处理报文，可能调用一个深度为3的函数链
vProcessCANMessage(&xMsg);
}
// 阻塞等待下一个报文
vTaskDelay(pdMS_TO_TICKS(10));
}
}这个任务里，xMsg结构体可能占几十字节，加上函数调用链，我估算下来大概需要200字节的栈。再加上中断嵌套（假设最大嵌套3层，每层50字节），再留30%余量，最终我给的是512字节。嗯，这个数字看起来比200大不少，但安全。
小技巧：很多RTOS都提供了栈使用率检测功能。比如FreeRTOS的uxTaskGetStackHighWaterMark()，可以在任务运行一段时间后查看栈实际使用了多少。我习惯在开发阶段把这个信息打印出来，用来验证我的估算是否准确。
4.2 任务入口函数设计：一个永不返回的函数
任务入口函数，说白了就是任务被调度执行时，第一个调用的函数。它有一个非常重要的特点：永远不能返回。为什么？因为一旦返回，RTOS就不知道这个任务该干什么了，系统会进入一个未定义状态。
我见过有人把任务入口函数写成普通函数的样子，最后加了个return。结果呢？任务执行一次就“消失”了，系统资源泄漏，调度器也乱了套。
4.2.1 入口函数的典型结构
一个标准的任务入口函数，通常是一个无限循环：
void vTaskFunction(void *pvParameters) {
// 1. 初始化部分：只执行一次
vHardwareInit();
vCreateLocalResources();
// 2. 无限循环：任务的主体
for( ;; ) {
// 等待某个事件或信号量
ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
// 处理事件
vProcessEvent();
// 或者周期性执行
vTaskDelay(pdMS_TO_TICKS(100));
}
}这里要注意几点：
- 初始化放在循环外面：只执行一次，避免重复初始化浪费资源。
- 循环体内要有阻塞点：比如
vTaskDelay、等待队列、信号量等。如果没有阻塞点，这个任务会一直占着CPU，其他任务就没法运行了。你想想看，一个高优先级的任务如果一直跑，低优先级任务就饿死了。 - 参数传递：
pvParameters是一个void指针，可以指向任意类型的数据。我习惯用它传递任务编号、配置参数等。
4.2.2 一次性任务的特殊处理
有些任务只需要执行一次，比如系统初始化任务。对于这种任务，入口函数执行完后，应该主动把自己删除：
void vInitTask(void *pvParameters) {
// 执行初始化工作
vInitSystemClocks();
vInitPeripherals();
vCreateOtherTasks();
// 任务完成，删除自己
vTaskDelete(NULL); // NULL表示删除当前任务
}嗯，这里要注意，vTaskDelete(NULL)调用后，任务并不会立即被销毁。RTOS会在合适的时机（比如下一次调度点）回收资源。所以，在vTaskDelete之后，不要再执行任何代码了，因为上下文可能已经无效。
避坑指南：我曾经在vTaskDelete后面加了一行打印语句，结果打印出来的数据全是乱的。因为任务栈已经被回收了，局部变量都不存在了。记住，vTaskDelete之后，就当这个任务已经死了，别再做任何操作。
4.3 任务删除与资源回收：善始善终
任务删除，听起来简单，但里面门道不少。你想想看，一个任务在运行过程中可能申请了动态内存、打开了文件、获取了互斥锁。如果直接把它删了，这些资源就没人释放了，系统就会慢慢泄漏。
4.3.1 删除任务的正确姿势
RTOS提供的vTaskDelete函数，只会回收任务控制块（TCB）和栈空间。至于任务自己申请的其他资源，它不管。所以，在删除任务之前，你得自己做好清理工作。
我建议的做法是：
- 任务内部自行清理：在任务退出循环前，释放所有资源。
- 通知其他任务：如果这个任务和其他任务有协作关系，删除前要通知它们，避免出现“野指针”或“悬空信号量”。
- 调用vTaskDelete：最后再删除自己。
看一个例子：
void vDataLoggerTask(void *pvParameters) {
FILE *fp = fopen("log.txt", "w");
void *buffer = pvPortMalloc(1024);
while(1) {
// 处理数据...
if( xShouldExit() ) {
break; // 收到退出信号
}
}
// 清理资源
if(fp) fclose(fp);
if(buffer) vPortFree(buffer);
// 通知监控任务
xTaskNotifyGive(xMonitorTaskHandle);
// 删除自己
vTaskDelete(NULL);
}4.3.2 资源回收的常见陷阱
我总结了几种常见的资源泄漏场景：
| 资源类型 | 泄漏原因 | 解决方案 |
|---|---|---|
| 动态内存 | 任务退出前未调用vPortFree |
在退出路径上统一释放 |
| 互斥锁 | 任务持有锁时被删除 | 确保退出前释放所有锁 |
| 信号量/队列 | 其他任务在等待该任务释放资源 | 删除前发送“终止”信号 |
| 硬件外设 | 任务独占的外设未关闭 | 在清理函数中关闭外设 |
嗯，这里要特别提一下互斥锁。如果一个任务持有了互斥锁，然后被强制删除了，这个锁就永远无法释放了。其他等待这个锁的任务会永远阻塞。我曾经在一个项目中遇到过这种情况，系统跑着跑着就“卡死”了，查了两天才发现是一个任务被异常删除时没释放锁。
核心原则：任务删除，本质上是“协商退出”，而不是“暴力终止”。让任务自己决定什么时候退出、怎么退出，才是最安全的方式。
4.3.3 内核层面的资源回收机制
好的RTOS内核，会在任务删除时自动回收TCB和栈。但其他资源，它真的管不了。为什么？因为内核不知道你申请了哪些资源。你想想看，内核只负责调度和同步，它不可能知道你用pvPortMalloc申请了多少块内存。
所以，资源回收的责任，最终还是落在开发者身上。我个人的习惯是，在每个任务入口函数的设计阶段，就规划好退出路径和清理逻辑。这样，即使任务因为异常被删除，也能保证资源被正确释放。
小技巧：可以使用钩子函数（Hook）来监控任务删除。比如FreeRTOS的vApplicationTaskDeleteHook，可以在任务被删除时执行一些额外的清理工作。我常用它来打印任务删除日志，方便调试。
好了，任务创建与销毁的核心内容就这些。说白了，栈分配要算清楚，入口函数要设计成永不返回的循环，删除时要做好资源回收。这三件事做好了，你的RTOS系统就稳了一大半。下一章，我们会聊任务调度与优先级反转，那又是一个容易踩坑的地方。