4. 堆空间管理：静态分配 vs 动态分配、避免碎片化、自定义malloc

说到堆空间管理，我得先坦白一件事。刚入行那会儿，我总觉得动态分配是万能的。需要内存？malloc一下就好。多方便啊！直到有一次，一个量产项目在跑了三天后突然死机，查了整整一周才发现是堆碎片化导致的。嗯，从那以后，我对堆管理就再也不敢马虎了。

在车载MCU这种资源受限的环境下，堆空间管理其实是个很微妙的话题。说白了，就是要在灵活性和可靠性之间找个平衡点。你想想看，一个刹车系统或者安全气囊控制器，能允许因为内存分配失败而出问题吗？显然不能。

静态分配 vs 动态分配：不是选择题，是场景题

我个人习惯把这个问题拆成两个维度来看：确定性和灵活性。

特性	静态分配	动态分配
分配时机	编译时/启动时	运行时
内存地址	固定	可变
碎片风险	无	高
灵活性	低	高
适用场景	关键路径、实时任务	配置加载、临时缓冲区

我在项目中遇到过这样一个情况：一个CAN报文解析模块，报文长度是固定的，但数量会变化。一开始我用了动态分配，结果发现每次分配和释放都会产生小碎片。后来改成静态池分配，问题就解决了。

避免碎片化：三个实战技巧

碎片化这东西，说白了就是内存被切成了很多小块，每个块都不大，但加起来不少，而且大块请求就是满足不了。我曾经在一个项目里看到堆碎片率高达40%，那叫一个心疼。

这里分享三个我常用的技巧：

1. 固定大小分配——把所有动态分配请求都对齐到2的幂次大小。比如要35字节，就分配64字节。浪费一点空间，但能大大减少碎片。
2. 分区管理——把堆分成几个区域，每个区域只处理特定大小的请求。小请求去小区域，大请求去大区域，互不干扰。
3. 避免频繁分配释放——能复用就复用。我习惯在初始化阶段一次性分配好所有可能用到的内存，运行期间只复用不释放。

自定义malloc：从零开始写一个轻量级分配器

标准库的malloc在MCU上往往太重了。它要考虑多线程、对齐、调试信息等等，这些在裸机环境下都是累赘。所以我建议自己写一个。

下面这个是我在项目里用过的简化版，核心思想就是首次适应算法：

// 自定义内存池
#define HEAP_SIZE 4096
static uint8_t heap[HEAP_SIZE];

// 空闲块头结构
typedef struct free_block {
    size_t size;
    struct free_block *next;
} free_block_t;

static free_block_t *free_list = (free_block_t *)heap;

// 初始化堆
void heap_init(void) {
    free_list->size = HEAP_SIZE - sizeof(free_block_t);
    free_list->next = NULL;
}

// 自定义malloc
void *my_malloc(size_t size) {
    // 对齐到4字节
    size = (size + 3) & ~3;
    
    free_block_t *prev = NULL;
    free_block_t *curr = free_list;
    
    while (curr != NULL) {
        if (curr->size >= size) {
            // 找到合适的块
            if (curr->size > size + sizeof(free_block_t)) {
                // 分割块
                free_block_t *new_block = (free_block_t *)((uint8_t *)curr + 
                    sizeof(free_block_t) + size);
                new_block->size = curr->size - size - sizeof(free_block_t);
                new_block->next = curr->next;
                curr->size = size;
                curr->next = new_block;
            }
            
            // 从空闲链表中移除
            if (prev == NULL) {
                free_list = curr->next;
            } else {
                prev->next = curr->next;
            }
            
            return (void *)((uint8_t *)curr + sizeof(free_block_t));
        }
        prev = curr;
        curr = curr->next;
    }
    
    return NULL; // 分配失败
}

// 自定义free
void my_free(void *ptr) {
    if (ptr == NULL) return;
    
    free_block_t *block = (free_block_t *)((uint8_t *)ptr - sizeof(free_block_t));
    
    // 插入到空闲链表头部
    block->next = free_list;
    free_list = block;
    
    // 合并相邻空闲块
    free_block_t *curr = free_list;
    while (curr != NULL && curr->next != NULL) {
        uint8_t *curr_end = (uint8_t *)curr + sizeof(free_block_t) + curr->size;
        if (curr_end == (uint8_t *)curr->next) {
            // 合并
            curr->size += sizeof(free_block_t) + curr->next->size;
            curr->next = curr->next->next;
        } else {
            curr = curr->next;
        }
    }
}

实战中的避坑指南

我曾经在一个项目里犯过一个低级错误：自定义malloc的堆大小设成了4096字节，但忘了算上管理结构的开销。结果实际可用内存只有不到3800字节，导致一个关键缓冲区分配失败。嗯，从那以后我每次都会在堆初始化后打印一下实际可用大小。

还有一次，我在一个循环里频繁调用my_malloc和my_free，结果发现性能急剧下降。查了半天才发现是碎片合并导致的。后来我改成了延迟合并策略——只在堆空间不足时才做合并，性能就上来了。

最后说一句：堆管理没有银弹。每个项目都有自己的特点，关键是要理解你的应用场景，然后选择最合适的策略。别盲目追求花哨的算法，简单可靠才是车载MCU的王道。