3. 动态内存分配：堆（Heap）管理机制、malloc/free实现原理、内存碎片问题分析

动态内存分配，说白了就是程序在运行过程中，随时跟系统「要」一块内存来用。这在嵌入式实时系统里，是个让人又爱又恨的东西。爱的是它灵活，恨的是它不可控。我做了这么多年嵌入式，见过太多因为动态内存分配翻车的案例了。

3.1 堆（Heap）管理机制

堆，就是一块预留出来的大内存区域。它不像栈那样由编译器自动管理，而是由程序员手动控制。你想想看，这就像你租了个大仓库，每次需要空间就进去划一块出来，用完再还回去。

在嵌入式系统里，堆的实现方式主要有这么几种：

• 固定大小块分配：把堆切成固定大小的块，比如16字节、32字节、64字节。每次申请就给你一个最接近的块。我在一个物联网项目里用过这种方式，简单粗暴，但浪费空间。
• 可变大小块分配：按需分配，要多少给多少。这就是标准的malloc实现方式，但容易产生碎片。
• 伙伴系统（Buddy System）：把内存按2的幂次分成块，分配和释放时合并相邻的空闲块。嗯，这个在Linux内核里用得比较多。

我个人习惯在实时性要求高的场景下，优先考虑固定大小块分配。为什么？因为它的执行时间是确定的，不会出现「这次分配很快，下次分配很慢」的情况。

3.2 malloc/free实现原理

malloc和free，是C标准库提供的动态内存分配函数。但它们的实现，在不同平台上差别很大。我当年在移植uC/OS-II时，就自己手写过一套malloc/free，那叫一个酸爽。

一个典型的malloc实现，内部维护着一个空闲链表。每个空闲块的开头都藏着一个小结构体，记录着块的大小和下一个空闲块的地址：

typedef struct free_block {
    size_t          size;           // 块大小（包括头部）
    struct free_block *next;        // 指向下一个空闲块
} free_block_t;

malloc的工作流程是这样的：

1. 遍历空闲链表，找一块足够大的空闲块。
2. 如果找到了，把这块从空闲链表里摘下来。
3. 如果这块比申请的大很多，就把它切成两块：一块给用户，另一块放回空闲链表。
4. 返回给用户的那块，地址要跳过头部结构体。

free的流程刚好相反：

1. 根据用户传进来的指针，往前偏移找到头部结构体。
2. 把这块重新挂回空闲链表。
3. 检查相邻的块是否也是空闲的，如果是，就合并它们。

3.3 内存碎片问题分析

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

• 外部碎片：空闲块分散在堆的各个角落，每个都不大，但加起来总量不少。你申请一块大的，就是找不到连续的空间。
• 内部碎片：分配给你的块比你实际需要的大，多出来的那部分就浪费了。比如你申请了10字节，系统给了你一个16字节的块，那6字节就是内部碎片。

为什么会这样？你想想看，程序运行过程中，不断地malloc和free，就像在堆上挖坑填坑。挖的坑大小不一，填的坑也不一样大。时间一长，堆就变得千疮百孔。

我遇到过最严重的一次，是在一个医疗设备项目里。设备运行了72小时后，突然无法分配内存了。一查，堆里还有30%的空闲空间，但最大的连续块只有64字节。这就是典型的外部碎片问题。

碎片类型	产生原因	影响	缓解方法
外部碎片	频繁分配/释放不同大小的块	无法分配大块内存	使用内存池、伙伴系统
内部碎片	分配粒度大于请求大小	内存利用率降低	调整分配粒度、使用精确分配

3.4 实战建议

说了这么多问题，那到底该怎么办？我给出几条实战建议：

• 尽量用静态分配：能提前算好最大用量的，就用全局数组或静态变量。这是最安全的方式。
• 使用内存池：如果必须动态分配，就预先创建几个固定大小的内存池。比如一个池子专门放16字节的块，另一个放64字节的块。这样既避免了碎片，又保证了分配时间确定。
• 定期检查堆状态：写一个堆状态打印函数，定期输出空闲块的数量和大小分布。这样能提前发现碎片问题。
• 避免在中断里malloc：中断服务程序应该尽量短小精悍，不要在里边做动态内存分配。malloc可能触发任务切换，这在中断里是致命的。

嗯，说到底，动态内存分配就像一把双刃剑。用好了，能让你的系统更灵活；用不好，就是一颗定时炸弹。我个人建议，在嵌入式实时系统里，能不用就不用，实在要用，也得用最保守的方式。