第六章：动态内存管理——堆区的艺术与陷阱
动态内存管理，说白了就是程序在运行时向操作系统“要内存”。
我刚开始学C语言时，觉得静态数组够用了。直到有一次做嵌入式项目，需要处理不定长的传感器数据流——数组开大了浪费RAM，开小了又怕溢出。嗯，那时候我才真正理解动态内存的价值。
6.1 堆区与栈区的区别
先搞清楚这两个区域，后面的坑才能避开。
| 对比项 | 栈区（Stack） | 堆区（Heap） |
|---|---|---|
| 分配方式 | 自动分配、自动释放 | 手动分配、手动释放 |
| 大小限制 | 较小（通常几KB~几MB） | 较大（受限于系统内存） |
| 速度 | 快（寄存器操作） | 慢（系统调用+链表管理） |
| 生命周期 | 函数结束即销毁 | 直到free()才释放 |
| 典型问题 | 栈溢出 | 内存泄漏、野指针 |
你想想看，栈就像酒店房间——入住退房都自动搞定。堆就像自己买地盖房——盖了得自己拆，不拆就成烂尾楼。
核心原则：栈用于局部变量和函数调用，堆用于需要动态控制生命周期的数据。
6.2 malloc：最基础的内存分配
malloc 是动态内存的起点。原型很简单：
void* malloc(size_t size);它从堆区申请 size 字节的连续空间，返回首地址。注意——返回的是 void*，需要强制类型转换。
我个人习惯这样写：
int* p = (int*)malloc(10 * sizeof(int));
if (p == NULL) {
// 处理分配失败
return -1;
}为什么一定要检查 NULL？我在项目中遇到过，某次产品在低温环境下内存碎片严重，malloc 突然返回 NULL。如果不检查，程序直接崩溃。从那以后，我每条 malloc 后面必跟 NULL 判断。
避坑指南：malloc 不会初始化内存！里面的数据是随机的“脏数据”。我曾经接手过一个项目，同事用 malloc 后直接当零初始化用，结果跑出来的数据全是乱码。
6.3 calloc：带清零的分配
calloc 比 malloc 多做了两件事：
- 自动计算总大小（参数分开传）
- 把分配的内存全部清零
void* calloc(size_t num, size_t size);示例：
int* arr = (int*)calloc(10, sizeof(int));
// arr 中所有元素初始化为 0什么时候用 calloc？我个人建议：如果你需要零初始化的数组，或者分配后马上要 memset 清零，直接用 calloc 更省事。但注意，calloc 比 malloc 慢一点——因为多了一次清零操作。
6.4 realloc：动态调整大小
realloc 是动态内存的“伸缩器”。原型：
void* realloc(void* ptr, size_t new_size);它有两种行为：
- 如果当前块后面有足够空间，直接扩展，返回原地址
- 如果后面空间不够，重新找一块更大的空间，拷贝旧数据，释放旧块
这里有个经典陷阱：
// 错误写法
int* p = (int*)malloc(10 * sizeof(int));
p = (int*)realloc(p, 20 * sizeof(int)); // 如果realloc失败，p变成NULL，原内存泄漏！正确的做法：
int* p = (int*)malloc(10 * sizeof(int));
int* tmp = (int*)realloc(p, 20 * sizeof(int));
if (tmp != NULL) {
p = tmp; // 只有成功才赋值
} else {
// 处理失败，p仍然有效
}我曾经在通信协议栈里吃过这个亏——realloc 失败后原指针丢了，那段内存再也找不回来。嗯，从那以后我再也不敢直接赋值了。
6.5 free：释放的艺术
有借有还，再借不难。free 就是还内存的操作：
void free(void* ptr);几个关键点：
- 只能 free 堆区内存，不能 free 栈区变量
- free 后必须把指针置 NULL，否则就是悬空指针
- 不能重复 free 同一块内存
个人习惯：每次 free 后立刻写 ptr = NULL;。这行代码救过我很多次——尤其在大型项目中，一个指针被多处引用时。
6.6 内存泄漏的检测与预防
内存泄漏是 C 程序员的“慢性病”。它不会立刻崩溃，但会慢慢吃掉系统内存。
常见的泄漏场景：
- malloc 后忘记 free
- 函数提前 return 忘了释放
- 结构体嵌套时只释放外层
检测方法：
- 静态分析：用 splint、cppcheck 等工具扫描代码
- 动态检测：Valgrind 是 Linux 下的神器
- 代码审查：每个 malloc 必须对应一个 free
预防策略：
- 写函数时先写好释放逻辑，再写分配逻辑
- 使用“谁分配谁释放”原则
- 复杂结构体写专门的销毁函数
经验之谈：我维护过一个运行了半年的嵌入式设备，突然内存不足。用 Valgrind 一查，发现某个回调函数里每次调用都 malloc 了 64 字节，但释放条件写错了——半年下来泄漏了 200MB+。
6.7 野指针与悬空指针
这两个概念容易混淆，我简单区分一下：
- 野指针：指针变量未初始化，指向随机地址
- 悬空指针：指针指向的内存已被释放，但指针值还在
野指针的典型场景：
int* p; // 未初始化，野指针
*p = 10; // 危险！悬空指针的典型场景：
int* p = (int*)malloc(sizeof(int));
free(p);
*p = 10; // 悬空指针！内存已归还系统预防方法：
- 声明指针时立即初始化：
int* p = NULL; - free 后立即置 NULL
- 不要返回局部变量的地址
血的教训：我曾经在 RTOS 项目中，一个任务释放了共享内存但没置 NULL，另一个任务通过这个悬空指针写数据——结果写到了其他任务的控制块上，系统直接死机。查了三天才找到原因。
6.8 知识体系总览
下面这张图总结了本章的核心脉络：
6.9 本章小结
动态内存管理是 C 语言中最容易出问题的地方，但也是嵌入式系统灵活性的关键。记住几个要点：
- 堆区灵活但需要手动管理，栈区自动但空间有限
- malloc/calloc/realloc 各有适用场景，选对工具事半功倍
- free 后置 NULL 是成本最低的防御性编程
- 内存泄漏和野指针是“定时炸弹”，工具+习惯才能根治
嗯，这一章的内容就到这里。动态内存管理没有捷径，只有靠良好的编码习惯和严格的审查流程。我见过太多项目因为一个 free 漏掉而翻车——希望你不要成为下一个。