2、heap_1实现分析：最简单的分配策略，只分配不释放，适用场景与源码解析。

好，咱们今天来聊聊 FreeRTOS 里最“单纯”的内存分配方案——heap_1。

为什么说它单纯？因为它只做一件事：分配内存，而且分配完了就再也不回收了。你想想看，这在嵌入式世界里是不是有点“霸道”？但别急着否定它，我做了这么多年嵌入式开发，发现很多时候，这种“简单粗暴”的方案反而是最稳的。

2.1 heap_1 的核心思想

说白了，heap_1 就是把一块预先定义好的大数组，当成一个“内存池”。你需要内存，我就从池子里切一块给你。你用完不还？没关系，我压根没指望你还。

它的实现逻辑，用一句话就能概括：维护一个指针，指向下一个可用的内存地址。每次分配，就把这个指针往后挪动需要的字节数。

嗯，就是这么简单。没有链表，没有碎片整理，没有释放回调。我刚开始接触 FreeRTOS 时，看到 heap_1 的源码，第一反应是：“就这？” 但后来在项目中吃过亏，才明白这种设计的精妙之处。

2.2 适用场景：什么时候该用它？

我个人习惯把 heap_1 用在那些“一次初始化，终身使用”的场景里。比如：

  • 任务栈的分配：任务创建后，栈空间大小就固定了，直到系统关机。
  • 信号量、队列等内核对象的创建：这些对象一旦创建，通常不会删除。
  • 静态配置的传感器驱动：比如初始化时分配一个缓冲区，之后一直用。

我在项目中遇到过这样一个案例：一个工业控制器，需要创建 20 多个任务，每个任务栈大小不同。如果用动态分配+释放的方案，反而会因为频繁的内存操作引入不确定性。最后我直接用了 heap_1，所有任务在启动时一次性分配完毕，系统跑了一年多，没出过一次内存问题。

核心优势：

  • 确定性：分配时间固定，没有碎片问题
  • 简单性：代码量极少，几乎不会出 bug
  • 安全性：不存在内存泄漏风险（因为根本没法释放）

注意：如果你需要频繁创建和删除任务，或者你的应用有动态内存回收的需求，千万别用 heap_1。我曾经见过一个同事，在需要动态删除任务的系统里用了 heap_1，结果跑了三天，内存耗尽，系统直接挂掉。嗯，那场面挺尴尬的。

2.3 源码解析：看看它到底怎么干的

好，咱们直接看源码。FreeRTOS 的 heap_1 实现，核心代码其实就几十行。我挑重点讲。

首先，它定义了一个大数组作为内存池：

/* 定义内存池大小，通常在 FreeRTOSConfig.h 中配置 */
#define configTOTAL_HEAP_SIZE    ( ( size_t ) ( 10 * 1024 ) )

/* 静态数组，所有分配都从这里切 */
static uint8_t ucHeap[ configTOTAL_HEAP_SIZE ];

然后，它维护一个指针，指向下一个可用的地址：

/* 下一个可用的内存地址 */
static size_t xNextFreeByte = 0;

分配函数的核心逻辑是这样的：

void *pvPortMalloc( size_t xWantedSize )
{
    void *pvReturn = NULL;

    /* 1. 内存对齐处理 */
    if( xWantedSize & portBYTE_ALIGNMENT_MASK )
    {
        /* 向上对齐到对齐字节的倍数 */
        xWantedSize += ( portBYTE_ALIGNMENT - ( xWantedSize & portBYTE_ALIGNMENT_MASK ) );
    }

    /* 2. 检查是否有足够空间 */
    if( ( xNextFreeByte + xWantedSize ) <= configTOTAL_HEAP_SIZE )
    {
        /* 3. 返回当前指针位置，然后移动指针 */
        pvReturn = &ucHeap[ xNextFreeByte ];
        xNextFreeByte += xWantedSize;
    }

    /* 4. 跟踪分配情况（调试用） */
    traceMALLOC( pvReturn, xWantedSize );

    return pvReturn;
}

你看，就这么几行。没有链表遍历，没有内存合并，没有释放逻辑。分配失败的唯一原因就是：空间不够了。

这里有个细节我想强调一下：内存对齐。为什么需要对齐？因为很多 MCU 的硬件要求数据访问必须对齐到特定地址（比如 4 字节或 8 字节），否则会触发异常。我刚开始做嵌入式时，就因为忽略了内存对齐，导致一个结构体指针访问时系统硬 fault，查了两天才找到原因。嗯，从那以后，我对齐这件事再也不敢马虎了。

2.4 释放函数：为什么是空的？

heap_1 的释放函数 vPortFree 是空的：

void vPortFree( void *pv )
{
    /* 什么也不做 */
    ( void ) pv;
}

为什么会这样？因为 heap_1 的设计哲学就是“不释放”。它把内存管理简化到了极致。你想想看，如果允许释放，那就需要记录哪些块是空闲的，哪些是占用的，这就引入了链表、碎片等问题。而 heap_1 直接砍掉了这些复杂性。

我的建议：如果你不确定该用哪种 heap 方案，先从 heap_1 开始。等系统跑起来，确认确实需要动态释放时，再切换到 heap_4 或 heap_5。我见过太多人一开始就上 heap_4，结果被内存碎片搞得焦头烂额。

2.5 性能分析：快，是真的快

咱们用数据说话。假设一个 100MHz 的 Cortex-M4 内核：

操作 heap_1 耗时 heap_4 耗时（典型值）
分配 128 字节 ~0.5 μs ~2-5 μs
分配 1024 字节 ~0.5 μs ~3-8 μs
释放操作 不支持 ~1-3 μs
最坏情况耗时 固定 随碎片增加而增加

看到了吗？heap_1 的分配时间是恒定的，不管你要多大内存，都是 O(1) 的复杂度。这在实时系统中是个巨大的优势。

2.6 避坑指南：我曾经踩过的坑

最后，分享几个我实际项目中遇到的坑：

  • 坑一：总堆大小估算不足。 我曾经在一个项目里，把 configTOTAL_HEAP_SIZE 设成了 4KB，结果任务创建到第 8 个时，系统直接断言失败。后来我仔细算了算，每个任务栈至少 512 字节，加上内核对象，至少需要 12KB。嗯，这个教训让我养成了一个习惯：先算再配，留 20% 余量。
  • 坑二：误以为 heap_1 可以释放。 有个同事在代码里调用了 vPortFree，然后发现内存占用只增不减。查了半天，才发现 heap_1 根本不支持释放。所以，用 heap_1 时，千万别写释放代码，写了也没用。
  • 坑三：对齐问题导致硬 fault。 这个前面提过了，但值得再说一次。如果你的 MCU 要求 8 字节对齐，但 heap_1 默认只做了 4 字节对齐，那就需要修改 portBYTE_ALIGNMENT 宏定义。

好了，关于 heap_1 的内容就讲到这里。它虽然简单，但在合适的场景下，它就是最优雅的解决方案。下一章，咱们聊聊 heap_2——那个支持释放，但容易产生碎片的方案。

← 上一章 📖 返回目录 下一章 →