3、FreeRTOS栈溢出检测：configCHECK_FOR_STACK_OVERFLOW钩子函数、uxTaskGetStackHighWaterMark() API
栈溢出，说白了就是任务用完了系统给它分配的栈空间。我刚开始用FreeRTOS那会儿，总觉得栈空间给大点就万事大吉。直到有一次，一个任务在特定条件下递归调用，直接把栈底踩穿了——系统死得悄无声息，连个错误日志都没留下。
从那以后，我养成了一个习惯：每个项目必开栈溢出检测。今天我们就聊聊FreeRTOS提供的两种检测手段。
3.1 栈溢出是怎么发生的？
每个任务都有自己的栈空间。函数调用、局部变量、中断嵌套，都会消耗栈空间。当任务实际使用的栈超过了系统分配的大小，就会发生溢出。
溢出的后果很严重：
- 覆盖相邻任务的TCB（任务控制块）
- 破坏堆空间的数据结构
- 系统随机崩溃，行为完全不可预测
你想想看，一个栈溢出可能让整个系统陷入混乱。所以，提前检测比事后排查要高效得多。
3.2 方法一：configCHECK_FOR_STACK_OVERFLOW 钩子函数
这是FreeRTOS内置的栈溢出检测机制。你需要在FreeRTOSConfig.h中配置这个宏。
配置方法很简单：
/* 在 FreeRTOSConfig.h 中 */
#define configCHECK_FOR_STACK_OVERFLOW 2 /* 可选 1 或 2 */这里有两个检测级别：
| 级别 | 检测方法 | 可靠性 |
|---|---|---|
| 1 | 任务切换时检查栈指针是否越界 | 一般，可能漏检 |
| 2 | 在级别1基础上，额外检查栈空间末尾的标记值是否被破坏 | 较高，推荐使用 |
然后你需要实现一个钩子函数：
void vApplicationStackOverflowHook( TaskHandle_t xTask, char *pcTaskName )
{
/* 栈溢出发生了！这里可以做： */
/* 1. 记录错误信息 */
/* 2. 点亮错误指示灯 */
/* 3. 保存关键数据后复位系统 */
for( ;; ); /* 或者直接调用 configASSERT() */
}级别2的原理是这样的：任务创建时，FreeRTOS会在栈空间的末尾填充一个特殊标记值（通常为0xa5a5a5a5）。每次任务切换时，系统检查这个标记是否被破坏。如果变了，说明栈溢出了。
我在项目中遇到过这种情况：一个任务平时只用了200字节栈，但某个极端情况下突然需要800字节。级别1没检测到，因为栈指针没越界，但标记值已经被覆盖了。换成级别2后，问题立刻暴露出来。
3.3 方法二：uxTaskGetStackHighWaterMark() API
这个API更温和一些。它不会触发钩子函数，而是告诉你任务栈还剩多少空间。我习惯叫它「水位线检测」。
用法如下：
UBaseType_t uxHighWaterMark;
/* 获取当前任务的栈剩余空间 */
uxHighWaterMark = uxTaskGetStackHighWaterMark( NULL );
/* 或者获取指定任务的栈剩余空间 */
uxHighWaterMark = uxTaskGetStackHighWaterMark( xTaskHandle );
/* 返回值单位：栈空间的字数（不是字节数） */这个API返回的是任务运行以来，栈剩余空间的最小值。说白了，就是历史上栈用得最狠的时候，还剩多少空间。
举个例子：
void vTaskFunction( void *pvParameters )
{
UBaseType_t uxInitialStack;
UBaseType_t uxCurrentStack;
/* 记录初始水位 */
uxInitialStack = uxTaskGetStackHighWaterMark( NULL );
for( ;; )
{
/* 任务主体逻辑 */
vTaskDelay( pdMS_TO_TICKS( 1000 ) );
/* 定期检查水位 */
uxCurrentStack = uxTaskGetStackHighWaterMark( NULL );
/* 如果水位下降超过20%，发出警告 */
if( uxCurrentStack < ( uxInitialStack * 80 / 100 ) )
{
/* 记录日志或触发告警 */
}
}
}3.4 两种方法怎么选？
我个人建议这样搭配使用：
- 开发调试阶段：同时开启两种检测。钩子函数负责捕获严重溢出，水位线API负责监控趋势。
- 产品发布阶段：如果性能敏感，可以关闭钩子函数（它每次任务切换都有开销），但保留水位线API做定期巡检。
核心要点：
- configCHECK_FOR_STACK_OVERFLOW 设置为2，检测更可靠
- 钩子函数中不要做复杂操作
- 水位线API返回的是历史最小值，不是当前值
- 定期巡检比被动等待溢出更主动
嗯，这里要注意一点：水位线API的返回值单位是「字」，不是字节。在32位系统上，1个字等于4字节。所以如果你看到返回值是50，实际剩余空间是200字节。
我曾经在一个项目中犯过这个错误：把返回值直接当字节数用，结果栈空间明明还剩200字节，我误以为只剩50字节，白白浪费了调试时间。
3.5 知识体系总览
下面这张图帮你理清两种检测方法的关系：
说白了，栈溢出检测不是锦上添花，而是保命手段。我见过太多项目因为栈溢出导致偶发死机，查了几个月都找不到原因。与其事后痛苦，不如一开始就把检测机制加上去。
记住一句话：栈空间给得再大，也不如一个可靠的检测机制来得安心。