3、信号量与互斥量调试：跟踪信号量释放与获取流程，排查死锁与资源泄漏

信号量和互斥量，说白了就是RTOS里的交通警察。它们管着资源的分配，谁能用，谁不能用，什么时候能用。但交警也有犯糊涂的时候——死锁了，资源泄漏了，系统就卡死了。

我个人习惯，调试这类问题从来不看运气。得有一套方法，一步步把流程理清楚。今天我就把压箱底的经验掏出来，跟你聊聊怎么跟踪信号量的释放与获取，怎么揪出死锁和资源泄漏的元凶。

3.1 信号量的“生老病死”

信号量本质上是一个计数器。创建时给它一个初始值，任务获取（take）时减1，释放（give）时加1。就这么简单。但问题往往出在“谁拿谁放”的节奏上。

我在项目中遇到过最典型的情况：一个传感器数据采集任务，每次采集完释放信号量，另一个处理任务等着拿。看起来天衣无缝，对吧？结果跑着跑着，处理任务就再也拿不到信号量了。

为什么？因为采集任务在某个异常分支里，忘了释放信号量。一次两次没事，积累多了，信号量的计数值就变成负数了——嗯，这里要注意，FreeRTOS里信号量计数值不会变负，但任务会一直阻塞在等待队列里。

3.2 互斥量的“优先级反转”陷阱

互斥量是信号量的特殊形式，多了个优先级继承机制。你想想看，如果低优先级任务拿着互斥量，高优先级任务等着拿，那低优先级任务就会被临时提升优先级，尽快释放资源。这是理论。

实际调试中呢？我曾经遇到一个诡异现象：一个中等优先级的任务，明明不涉及任何共享资源，却把整个系统拖慢了。排查了半天，才发现是优先级反转的变种——低优先级任务拿了互斥量，被高优先级任务抢占，中优先级任务趁机插队运行，低优先级任务迟迟得不到CPU，互斥量就迟迟不释放。

这就是所谓的“优先级反转+死锁”组合拳。怎么破？

• 检查所有获取互斥量的路径：每个take是否都有对应的give？
• 检查任务优先级：持有互斥量的任务，优先级是否合理？
• 使用递归互斥量：如果同一个任务可能多次获取同一个互斥量，用递归版本。

3.3 跟踪流程：三板斧

调试信号量和互斥量，我总结了三板斧。你照着做，大部分问题都能定位。

第一板斧：打印日志

别小看打印。在关键位置加打印，记录每次take和give的时间戳、任务名、信号量当前值。我习惯这样写：

// 获取信号量时
printf("[%d] Task_%s: take sem, count=%d\n", 
       xTaskGetTickCount(), pcTaskGetName(NULL), 
       uxSemaphoreGetCount(xSemaphore));

// 释放信号量时
printf("[%d] Task_%s: give sem, count=%d\n", 
       xTaskGetTickCount(), pcTaskGetName(NULL), 
       uxSemaphoreGetCount(xSemaphore));

跑一段时间，把日志导出来。用Excel或者Python脚本分析，看看有没有“只take不give”的情况。如果有，顺着任务名和代码行号去找，十有八九能抓到问题。

第二板斧：使用RTOS内核调试功能

FreeRTOS提供了不少调试钩子。比如configUSE_TRACE_FACILITY和configUSE_STATS_FORMATTING_FUNCTIONS，打开后可以用vTaskList()和vTaskGetRunTimeStats()查看任务状态。

我个人习惯再加一个定时器中断，每隔100ms打印一次所有信号量的状态：

void vPrintSemaphoreStats(void)
{
    // 遍历所有信号量，打印名称和计数值
    // 需要自己维护一个信号量列表
    for (int i = 0; i < g_semCount; i++) {
        printf("Sem[%s]: count=%d, blocked tasks=%d\n",
               g_semList[i].name,
               uxSemaphoreGetCount(g_semList[i].handle),
               uxQueueMessagesWaiting(g_semList[i].handle));
    }
}

注意，uxQueueMessagesWaiting对信号量也适用，它返回的是等待该信号量的任务数量。如果这个值一直大于0，说明有任务在死等。

第三板斧：静态代码分析

这是最笨但最有效的方法。把代码打印出来，拿支红笔，画出每个信号量的生命周期。从创建开始，到每次take，到对应的give，一条线画下来。如果发现某个分支只有take没有give，那就是bug。

我记得有一次，一个同事调试了三天没找到问题。我让他用这个方法，十分钟就发现了一个return语句前面忘了give。嗯，这种低级错误，谁都会犯，关键是方法要对。

3.4 死锁的典型场景与排查

死锁有四个必要条件：互斥、持有并等待、不可剥夺、循环等待。在嵌入式系统里，最常见的是两个任务互相等待对方释放资源。

举个例子：

// 任务A
void TaskA(void *pvParameters)
{
    xSemaphoreTake(sem1, portMAX_DELAY);
    // 做一些事
    xSemaphoreTake(sem2, portMAX_DELAY);
    // ...
    xSemaphoreGive(sem2);
    xSemaphoreGive(sem1);
}

// 任务B
void TaskB(void *pvParameters)
{
    xSemaphoreTake(sem2, portMAX_DELAY);
    // 做一些事
    xSemaphoreTake(sem1, portMAX_DELAY);
    // ...
    xSemaphoreGive(sem1);
    xSemaphoreGive(sem2);
}

如果任务A拿了sem1，任务B拿了sem2，然后A等sem2，B等sem1——死锁了。排查方法很简单：

1. 用调试器暂停所有任务，查看每个任务阻塞在哪个信号量上。
2. 如果发现任务A阻塞在sem2，任务B阻塞在sem1，那就是死锁。
3. 修复方法：统一获取顺序，或者使用xSemaphoreTake的超时版本，不要用portMAX_DELAY。

3.5 资源泄漏的排查思路

资源泄漏比死锁更隐蔽。系统跑着跑着，信号量越来越少，最后某个任务再也拿不到资源了。排查思路：

• 检查创建和删除是否匹配：动态创建的信号量，用完后有没有删除？
• 检查give和take是否成对：每个take最终都要有对应的give，包括异常分支。
• 检查中断服务函数：在ISR中give信号量，要使用xSemaphoreGiveFromISR，并且注意不要在中段中take。

我曾经遇到一个奇葩问题：一个信号量，创建时初始值为1，跑了一天之后变成0了。排查发现，有一个中断服务函数里调用了xSemaphoreGive（不是FromISR版本），导致信号量计数值异常增加。嗯，这种问题，不看代码根本想不到。

3.6 知识体系总览

下面这张图，是我自己总结的信号量与互斥量调试知识体系。你照着这个框架去排查，思路会清晰很多。

3.7 实战建议

说了这么多，最后给你几条实战建议：

• 从设计阶段就考虑调试：每个信号量都起个有意义的名字，方便日志输出时识别。
• 建立信号量清单：在代码里维护一个全局的信号量列表，包含名称、句柄、初始值、当前值、创建者等信息。
• 写一个信号量监控任务：定期检查所有信号量的状态，如果发现异常（比如计数值超出预期范围），主动报告。
• 不要迷信“理论上没问题”：代码是人写的，人就会犯错。用工具、用方法、用流程来保证质量，而不是靠记忆力。

好了，信号量和互斥量的调试就聊到这儿。记住那三板斧，遇到问题别慌，一步步来，总能找到根因。

---