第4章 heap_3实现分析

4. heap_3实现分析：包装标准C库malloc/free，依赖编译器，线程安全由调度器保证

好，咱们今天来聊聊 heap_3。说实话，这个方案在 FreeRTOS 的五个内存管理策略里，算是最「偷懒」的一个——但也是最省心的一个。

为什么这么说？因为 heap_3 本质上什么都没做。它就是把标准 C 库的 malloc 和 free 包了一层，加了个临界区保护。嗯，就这么简单。

4.1 heap_3 的核心思想

我个人习惯把 heap_3 叫做「直通方案」。它不自己管理内存池，不搞什么空闲链表，也不做内存合并。它直接把内存申请的活儿甩给了编译器自带的 C 库。

说白了，你在代码里调用 pvPortMalloc，它内部就是调 malloc。你调用 vPortFree，它内部就是调 free。唯一的区别是，它用 FreeRTOS 的调度器锁保证了线程安全。

核心特点：

依赖编译器提供的标准 C 库
线程安全由调度器保证（通过临界区）
不额外管理内存，完全交给底层
代码量极小，实现简单

4.2 源码分析：其实就几行代码

咱们直接看源码。我记得第一次打开 heap_3.c 的时候，我还以为文件没加载全——因为真的太短了。

/* 标准 C 库头文件 */
#include <stdlib.h>

/* 定义内存申请函数 */
void *pvPortMalloc( size_t xWantedSize )
{
    void *pvReturn = NULL;

    /* 进入临界区，关调度器 */
    vTaskSuspendAll();
    {
        /* 调用标准 C 库的 malloc */
        pvReturn = malloc( xWantedSize );
    }
    /* 退出临界区，恢复调度器 */
    xTaskResumeAll();

    return pvReturn;
}

/* 定义内存释放函数 */
void vPortFree( void *pv )
{
    if( pv != NULL )
    {
        /* 进入临界区 */
        vTaskSuspendAll();
        {
            /* 调用标准 C 库的 free */
            free( pv );
        }
        /* 退出临界区 */
        xTaskResumeAll();
    }
}

看到了吗？核心逻辑就这么多。你想想看，这比 heap_4 和 heap_5 那些动辄几百行的代码简单太多了。

4.3 线程安全是怎么保证的？

这里有个关键点：vTaskSuspendAll 和 xTaskResumeAll 这对函数。

它们的作用是暂停所有任务的调度。也就是说，当某个任务正在执行 malloc 的时候，其他任务不会跑，自然就不会出现同时操作内存的情况。

我曾经在项目里遇到过一个问题：有个同事觉得 heap_3 太慢，想自己加锁优化。结果他用了信号量而不是挂起调度器，导致在中断服务程序里调 pvPortMalloc 时直接死锁。嗯，这里要注意——vTaskSuspendAll 可以在中断中使用，但信号量不行。这是 heap_3 设计时就已经考虑好的。

小提示：

如果你在中断里需要动态分配内存，heap_3 是唯一一个原生支持的选择。因为 vTaskSuspendAll 不会阻塞中断，而其他方案用的互斥量会。

4.4 依赖编译器的代价

好，现在说说缺点。heap_3 把内存管理完全交给了标准 C 库，这意味着你失去了控制权。

举个例子：标准 C 库的 malloc 实现通常比较复杂，它要维护自己的空闲链表、做内存碎片整理、甚至可能调用操作系统的系统调用。这些操作的时间是不确定的。你想想看，在实时系统里，一个不确定时间的函数调用有多危险。

我建议你在使用 heap_3 之前，先搞清楚你的编译器用的什么 malloc 实现。比如：

编译器	malloc 实现特点	适用场景
GCC (newlib)	基于 sbrk 系统调用，可能触发内核态切换	有操作系统的环境
ARMCC (MDK)	使用堆区静态数组，速度较快	裸机或 RTOS 环境
IAR	可配置堆大小，支持线程安全选项	需要精细控制堆的场景
Keil	默认使用 MicroLIB，体积小但功能有限	资源受限的 MCU

我曾经在 STM32F4 上用 GCC 编译，结果发现 malloc 偶尔会返回 NULL。查了半天，原来是 newlib 的堆空间没配置够。后来我改用 heap_4，自己管理内存池，问题就解决了。

避坑指南：

我曾经在项目里因为 heap_3 踩过一个坑：标准 C 库的 malloc 在内存不足时不会返回 NULL，而是触发一个硬件异常（取决于实现）。这导致系统直接死机，连错误日志都来不及打印。所以如果你用 heap_3，一定要确保堆空间足够大，或者自己实现一个错误处理钩子。

4.5 什么时候该用 heap_3？

说实话，我在实际项目中很少用 heap_3。但有些场景它确实很合适：

快速原型开发：不想纠结内存管理细节，先跑起来再说
代码移植：从裸机程序迁移到 FreeRTOS，原有代码大量使用 malloc/free
内存需求简单：只偶尔申请释放，不频繁操作
调试阶段：用标准 C 库的内存检测工具（如 Valgrind）来查内存泄漏

但如果你对实时性有要求，或者内存资源紧张，我建议你还是用 heap_4 或 heap_5。它们虽然代码复杂点，但至少时间是可预测的。

4.6 性能对比：heap_3 vs 其他方案

咱们做个简单对比，你就明白为什么我说 heap_3 是「偷懒」方案了：

特性	heap_3	heap_4	heap_5
代码量	约 20 行	约 300 行	约 350 行
执行时间确定性	不确定（依赖 C 库）	确定（O(n) 遍历）	确定（O(n) 遍历）
内存碎片	依赖 C 库实现	可合并相邻空闲块	可合并相邻空闲块
线程安全	调度器挂起	调度器挂起	调度器挂起
多堆支持	不支持	不支持	支持

你看，heap_3 唯一的优势就是简单。但简单也意味着功能弱。我个人习惯是：除非项目特别小，否则我不会用 heap_3。

4.7 总结一下

heap_3 就是 FreeRTOS 给开发者留的一个「后门」。它让你可以用标准 C 库的方式管理内存，同时享受调度器提供的线程安全保护。

但记住，这种「方便」是有代价的。你失去了对内存分配时机的控制，也失去了对碎片的管理能力。如果你只是写个简单的 demo，或者做快速验证，heap_3 完全够用。但如果是产品级的代码，我建议你慎重考虑。

嗯，下一章咱们会讲 heap_4，那才是我真正推荐大家使用的方案。到时候咱们再细聊。