4、内存管理优化：静态内存分配 vs 动态内存分配、内存池设计、内存碎片整理策略

内存管理，说白了就是给机器人系统里的每个任务、每个数据块找个合适的「家」。我做了这么多年嵌入式实时系统，见过太多因为内存管理不当导致的系统崩溃。有的跑着跑着突然卡死，有的响应越来越慢，最后查出来都是内存碎片在作祟。

今天咱们就把这块硬骨头啃下来。我会从最基础的分配方式讲起，再到内存池这种工程利器，最后聊聊碎片整理那些事。

4.1 静态内存分配 vs 动态内存分配

先问个问题：你的机器人系统里，内存是编译时就定死的，还是运行时按需申请的？

这两种方式，各有各的脾气。

对比维度	静态内存分配	动态内存分配
分配时机	编译/链接阶段	运行时
内存位置	栈区或全局数据区	堆区
分配速度	零开销（编译期完成）	有开销（查找空闲块）
碎片问题	无碎片	容易产生碎片
灵活性	低，大小固定	高，按需分配
安全性	高，无内存泄漏风险	低，需手动管理

我个人习惯是：能静态分配就静态分配。尤其是在中断服务程序、高优先级任务这些对确定性要求极高的地方，malloc/free 我基本不用。

举个例子，机器人里的电机控制循环，周期只有 1ms。你想想看，如果在控制循环里做动态内存分配，光是查找空闲链表的时间就够你喝一壶的。我在项目中遇到过，有人把日志缓冲区的分配放在控制循环里，结果系统时不时抖一下，最后定位到就是 malloc 耗时不稳定。

4.2 内存池设计

那如果确实需要动态分配怎么办？别急，内存池就是为这个场景准备的。

内存池的思路很简单：提前从堆里划出一大块内存，切成固定大小的块，用链表串起来。需要内存时，从链表头取一个块；释放时，把块放回链表头。整个过程 O(1) 时间复杂度，没有碎片。

/* 内存池结构定义 */
typedef struct {
    void *pool_start;          /* 池起始地址 */
    size_t block_size;         /* 每个块的大小 */
    uint32_t block_count;      /* 块总数 */
    uint32_t free_count;       /* 空闲块数 */
    void *free_list;           /* 空闲块链表头 */
} mem_pool_t;

/* 初始化内存池 */
void mem_pool_init(mem_pool_t *pool, void *buffer, 
                   size_t block_size, uint32_t block_count) {
    pool->pool_start = buffer;
    pool->block_size = block_size;
    pool->block_count = block_count;
    pool->free_count = block_count;
    pool->free_list = buffer;
    
    /* 构建空闲链表 */
    uint8_t *p = (uint8_t *)buffer;
    for (uint32_t i = 0; i < block_count - 1; i++) {
        *(void **)p = (void *)(p + block_size);
        p += block_size;
    }
    *(void **)p = NULL;  /* 最后一个块指向空 */
}

/* 从内存池分配 */
void *mem_pool_alloc(mem_pool_t *pool) {
    if (pool->free_count == 0) return NULL;
    
    void *block = pool->free_list;
    pool->free_list = *(void **)block;
    pool->free_count--;
    return block;
}

/* 释放回内存池 */
void mem_pool_free(mem_pool_t *pool, void *block) {
    *(void **)block = pool->free_list;
    pool->free_list = block;
    pool->free_count++;
}

这段代码看着简单，但实际工程里有很多讲究。我曾经在一个视觉处理模块里用过内存池，把图像帧缓冲区的分配时间从平均 12μs 降到了 0.2μs，效果立竿见影。

内存池还有个好处——内存泄漏可追溯。因为所有块都来自同一个池，只要在分配时记录任务 ID，释放时检查是否匹配，就能快速定位谁没释放内存。

4.3 内存碎片整理策略

说到碎片，这是动态内存分配最头疼的问题。机器人系统跑久了，堆里就像被狗啃过一样，到处都是小洞。明明总空闲内存还有 50%，但就是分配不出一个 10KB 的连续块。

碎片分两种：

• 外部碎片：空闲块不连续，分散在已分配块之间
• 内部碎片：分配块比实际需求大，块内浪费的空间

怎么处理？我总结了三种策略：

策略一：伙伴算法（Buddy System）

把内存按 2 的幂次分成块。分配时找最小能满足需求的块，如果找不到就分裂更大的块。释放时检查相邻块是否空闲，是的话就合并。这种算法外部碎片少，但内部碎片可能达到 50%。

策略二：紧凑（Compaction）

把已分配的内存块全部挪到一起，空出一整块连续空间。听起来简单，但实现起来坑很多——你得更新所有指针引用。我建议只在系统空闲时做，而且要保证所有任务都处于安全暂停状态。

策略三：分代回收（Generational GC）

把内存对象按存活时间分代。新分配的对象放在「新生代」，存活久的晋升到「老年代」。回收时优先扫描新生代，因为大部分对象都是朝生夕死。这种策略在机器人操作系统（如 ROS 2）的某些实现中能看到影子。

下面这张图展示了三种策略的适用场景：

4.4 实战：如何选择

说了这么多，到底怎么选？我一般按这个流程来：

1. 先看实时性要求——周期小于 5ms 的任务，直接上静态分配或内存池
2. 再看内存大小——如果总内存小于 64KB，用静态分配最省心
3. 然后看分配模式——如果分配/释放频繁且大小固定，内存池是首选
4. 最后看调试需求——开发阶段可以开内存跟踪，发布阶段关掉