4、消息队列调试：检查队列满/空状态，定位数据丢失与阻塞问题

消息队列，说白了就是RTOS里任务之间传话的“信箱”。

我刚开始用STM32做多任务时，总觉得队列这玩意儿挺简单——不就是放数据、取数据嘛。结果呢？项目跑到一半，某个任务死活收不到消息，另一个任务卡死不动。查了两天，最后发现是队列满了，数据丢了，任务还傻等着。

嗯，今天咱们就聊聊怎么把消息队列调试明白。

4.1 队列满/空状态——你踩过哪些坑？

先看一个典型场景：

你有一个采集任务，一个处理任务。采集任务拼命往队列里塞数据，处理任务慢慢吞吞地取。突然有一天，采集任务发现队列塞不进去了——队列满了。

这时候会发生什么？

• 数据丢失：如果你用的是osMessageQueuePut()且没设超时，函数直接返回错误，数据就丢了。
• 任务阻塞：如果你设了超时等待，采集任务就会卡在那里，直到队列有空位或者超时。
• 优先级反转：高优先级任务因为队列满被阻塞，低优先级任务反而跑得欢——这问题我遇到过，查得我头秃。

4.2 怎么检查队列状态？

我个人习惯在调试阶段，每隔一段时间打印队列的当前消息数、空闲槽位数。

以FreeRTOS为例，API是这样的：

// 获取队列中当前消息数量
UBaseType_t uxQueueMessagesWaiting(QueueHandle_t xQueue);

// 获取队列中空闲空间数量
UBaseType_t uxQueueSpacesAvailable(QueueHandle_t xQueue);

我一般会在一个低优先级的监控任务里，定时调用这两个函数，把结果通过串口打出来：

void vMonitorTask(void *pvParameters) {
    QueueHandle_t xQueue = (QueueHandle_t)pvParameters;
    UBaseType_t uxMsgs, uxSpaces;
    
    for(;;) {
        uxMsgs = uxQueueMessagesWaiting(xQueue);
        uxSpaces = uxQueueSpacesAvailable(xQueue);
        
        printf("[MON] 队列: %d/%d 条消息, 空闲: %d\r\n", 
               uxMsgs, uxMsgs + uxSpaces, uxSpaces);
        
        // 如果队列快满了，报警
        if(uxSpaces < 5) {
            printf("[WARN] 队列即将满！\r\n");
        }
        
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

你看，这样一跑，队列的“水位”一目了然。如果发现队列经常接近满，说明要么队列太小，要么消费者太慢。

4.3 数据丢失——到底丢在哪了？

数据丢失是最头疼的问题。我曾经在一个电机控制项目里，采集任务每1ms发一次数据，处理任务却要花5ms处理一条。队列只有10个槽位，结果呢？每5ms就丢3条数据。

怎么定位？我总结了三个步骤：

1. 检查返回值：每次调用osMessageQueuePut()或xQueueSend()，一定要检查返回值。很多人图省事不检查，丢数据了都不知道。
2. 加计数器：在发送端和接收端分别加一个计数器。发送端每发一次加1，接收端每收一次加1。如果两个计数器对不上，说明中间有丢失。
3. 用事件记录：把每次队列操作的关键信息（时间戳、队列状态、返回值）记录到环形缓冲区里，出问题时导出分析。

举个例子，我常用的调试代码：

// 发送端
static uint32_t ulSendCount = 0;
BaseType_t xResult = xQueueSend(xQueue, &data, 0);
ulSendCount++;
if(xResult != pdPASS) {
    printf("[ERR] 发送失败! 已发送: %lu, 失败次数: %lu\r\n", 
           ulSendCount, ulSendFailCount++);
}

// 接收端
static uint32_t ulRecvCount = 0;
if(xQueueReceive(xQueue, &data, 0) == pdPASS) {
    ulRecvCount++;
    printf("[OK] 收到第 %lu 条消息\r\n", ulRecvCount);
}

跑一段时间后，对比ulSendCount和ulRecvCount，差值就是丢失的数据量。

4.4 阻塞问题——任务卡住了怎么办？

任务阻塞在队列操作上，说白了就是“等不到想要的东西”。

分两种情况：

• 发送阻塞：队列满了，发送任务在等空位。如果一直等不到，任务就永远卡在那。
• 接收阻塞：队列空了，接收任务在等数据。如果一直没人发，任务就永远醒不来。

怎么查？我一般用这招：

方法一：看任务状态

在FreeRTOS里，用vTaskList()或uxTaskGetSystemState()可以查看所有任务的状态。如果某个任务长时间处于“Blocked”状态，而且阻塞在队列上，那就有问题了。

// 打印所有任务状态
void vPrintTaskList(void) {
    char pcBuffer[512];
    vTaskList(pcBuffer);
    printf("任务名\t状态\t优先级\t栈剩余\t任务号\r\n");
    printf("%s\r\n", pcBuffer);
}

输出里，状态为“B”的就是阻塞态。如果某个任务一直“B”，而且你确定它应该频繁运行，那八成是队列操作卡住了。

方法二：设置超时

我强烈建议，除了极少数情况，队列操作都要设超时。哪怕超时时间设得很长，也比无限等待强。这样至少不会死锁。

// 发送超时100ms
if(xQueueSend(xQueue, &data, pdMS_TO_TICKS(100)) != pdPASS) {
    printf("[WARN] 发送超时! 队列可能已满\r\n");
    // 这里可以做错误处理，比如丢弃数据或重启任务
}

// 接收超时50ms
if(xQueueReceive(xQueue, &data, pdMS_TO_TICKS(50)) != pdPASS) {
    printf("[WARN] 接收超时! 队列可能为空\r\n");
    // 做其他事情，别死等
}

4.5 知识体系图

下面这张图，是我自己总结的消息队列调试思路，你一看就明白：

4.6 实战建议

最后，给你几个我踩过坑之后总结的建议：

• 队列大小别拍脑袋：根据生产者和消费者的速率差来算。比如生产者每1ms发1条，消费者每5ms处理1条，那队列至少要有5个槽位，再留点余量，我一般取10-20。
• 调试信息要分级：正常运行时只打印错误，调试时再打印详细信息。用#ifdef DEBUG控制，别一股脑全打出来。
• 别在中断里等队列：中断服务函数里调用xQueueSendFromISR()没问题，但千万别在中断里等队列空出来——中断里不能阻塞。
• 我曾经犯过一个错：在中断里用了xQueueSend()（带阻塞的版本），结果中断一触发，系统直接死机。后来查资料才知道，中断里只能用FromISR后缀的API。

---