第4章动态内存分配

4. 动态内存分配：堆内存管理、malloc/free的实现原理、内存碎片问题

动态内存分配，说白了就是程序在运行过程中，随时向操作系统“要”一块内存来用，用完了再“还”回去。这个“要”和“还”的过程，在C语言里就是 malloc 和 free。在运动控制系统中，这个操作非常敏感，搞不好就会出大问题。

我刚开始做嵌入式运动控制时，觉得动态分配挺方便的。需要缓冲区就 malloc 一个，用完就 free 掉。直到有一次，一个伺服驱动项目跑了三天三夜，突然卡死了。查了整整两天，才发现是内存碎片导致 malloc 返回了 NULL。嗯，从那以后，我对堆内存管理就格外小心了。

4.1 堆内存管理的基本概念

堆（Heap）是进程地址空间中的一块区域，专门用来存放动态分配的内存。它不像栈那样自动管理，而是由程序员手动控制。

在RTOS环境下，堆通常是一个大数组，由内存管理器来切分。你想想看，一个运动控制任务可能同时需要多个缓冲区：轨迹规划缓冲区、插补数据缓冲区、PID参数临时存储区……这些大小不一、生命周期不同的内存需求，全靠堆来满足。

堆 vs 栈的核心区别：

栈：自动分配、自动释放，速度快，但大小固定（通常几KB）
堆：手动分配、手动释放，速度慢，但容量大（可达MB级别）

我个人习惯在运动控制系统中，把堆的起始地址和大小在链接脚本里就定死。这样内存布局是确定的，调试起来心里有底。

4.2 malloc/free 的实现原理

很多人以为 malloc 和 free 是操作系统提供的。其实在嵌入式领域，它们通常由C标准库实现，底层依赖一个叫做“内存堆管理器”的东西。

最常见的实现方式是 空闲链表（Free List）。原理很简单：

初始化时，整个堆是一个大空闲块
malloc 时，遍历空闲链表，找到一块足够大的内存
切出一块给用户，剩下的放回链表
free 时，把内存块重新挂回链表，并尝试合并相邻的空闲块

来看一个简化版的实现思路：

// 内存块头部结构
typedef struct mem_block {
    size_t       size;      // 块大小（包含头部）
    int          free;      // 是否空闲
    struct mem_block *next; // 指向下一个块
} mem_block_t;

// 空闲链表头
static mem_block_t *free_list = NULL;

void *malloc(size_t size) {
    mem_block_t *curr = free_list;
    while (curr) {
        if (curr->free && curr->size >= size + sizeof(mem_block_t)) {
            // 找到了！切分块
            curr->free = 0;
            return (void*)(curr + 1); // 返回头部之后的数据区
        }
        curr = curr->next;
    }
    return NULL; // 没有足够内存
}

void free(void *ptr) {
    if (!ptr) return;
    mem_block_t *block = (mem_block_t*)ptr - 1;
    block->free = 1;
    // 尝试合并相邻空闲块（代码略）
}

我在项目中遇到过一个问题：某个 free 操作后，相邻的空闲块没有合并，导致一个大请求无法满足。后来我加了一个“合并检查”逻辑，每次 free 后都尝试合并前后块，问题就解决了。

小技巧： 在运动控制系统中，建议使用 pvPortMalloc 和 vPortFree（FreeRTOS 提供）而不是标准库的 malloc/free。因为 RTOS 版本通常做了线程安全处理，而且性能更优。

4.3 内存碎片问题

内存碎片是动态内存分配的头号杀手。它分为两种：

外部碎片：空闲块不连续，总空闲空间够，但无法满足一个大块请求
内部碎片：分配的内存块比实际需要的大，浪费了空间

为什么会这样？你想想看，如果程序反复分配和释放不同大小的内存块，空闲链表就会变得支离破碎。就像一块蛋糕被切来切去，最后全是小碎块，拼不成一大块。

我曾经在一个多轴插补项目中，因为频繁分配和释放轨迹点缓冲区，导致系统运行2小时后 malloc 失败。排查后发现，堆里最大的连续空闲块只有 128 字节，而我们需要 256 字节的缓冲区。

避坑指南： 我曾经在运动控制系统中使用 malloc/free 来管理实时数据缓冲区，结果系统运行一段时间后出现随机卡顿。后来改用静态分配 + 内存池，问题彻底消失。记住：实时系统里，动态分配要慎之又慎！

4.4 如何应对内存碎片

既然碎片这么讨厌，那怎么解决？这里有几种常用策略：

策略	原理	适用场景	缺点
内存池	预分配固定大小的块	频繁分配/释放固定大小对象	浪费空间（内部碎片）
伙伴算法	按2的幂次切分内存	需要快速分配/合并	内部碎片较多
垃圾回收	自动整理碎片	非实时系统	暂停时间不可控
静态分配	编译时确定所有内存需求	运动控制核心任务	灵活性差

我个人最推荐的是 内存池 + 静态分配 的组合方案。对于运动控制中的关键数据（如轨迹点、PID参数），用静态数组；对于临时缓冲区，用固定大小的内存池。

下面是一个简单的内存池实现：

#define POOL_SIZE 10
#define BLOCK_SIZE 64

static uint8_t pool[POOL_SIZE][BLOCK_SIZE];
static uint8_t used[POOL_SIZE] = {0};

void* pool_alloc(void) {
    for (int i = 0; i < POOL_SIZE; i++) {
        if (!used[i]) {
            used[i] = 1;
            return pool[i];
        }
    }
    return NULL; // 池已满
}

void pool_free(void *ptr) {
    for (int i = 0; i < POOL_SIZE; i++) {
        if (pool[i] == ptr) {
            used[i] = 0;
            return;
        }
    }
}

你看，这个内存池没有碎片问题，分配和释放都是 O(1) 时间复杂度。代价就是每个块大小固定，如果实际数据小于 64 字节，就会产生内部碎片。但在运动控制中，这个代价完全可以接受。

4.5 运动控制中的最佳实践

基于我多年的经验，总结几条铁律：

能不动态分配，就别动态分配。运动控制是硬实时系统，确定性比灵活性重要
如果必须用，就用内存池。提前规划好所有可能的内存需求
不要在中断服务函数里调用 malloc/free。我曾经因为这个导致系统死锁，教训深刻
监控堆使用情况。定期检查剩余空间和最大空闲块大小

核心原则： 运动控制系统的内存管理，追求的是“确定性”而非“灵活性”。一个可预测的、不会失败的内存分配方案，远胜于一个灵活但可能崩溃的方案。

嗯，关于动态内存分配，今天就聊到这里。记住：在运动控制的世界里，内存管理不是锦上添花，而是生死攸关。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

4. 动态内存分配：堆内存管理、malloc/free的实现原理、内存碎片问题

4.1 堆内存管理的基本概念

4.2 malloc/free 的实现原理

4.3 内存碎片问题

4.4 如何应对内存碎片

4.5 运动控制中的最佳实践