手动内存管理：malloc/free 的核心机制与陷阱

聊到 C/C++ 的手动内存管理，我脑子里第一个蹦出来的画面，就是当年调试一个服务器程序时，堆内存被搞得千疮百孔的样子。说实话，malloc 和 free 这对搭档，用好了是利器，用砸了就是噩梦。这一章咱们就把它们的底层机制和常见坑位彻底捋一遍。

malloc/free 到底干了啥？

其实 malloc 并不是直接从操作系统要内存。它背后是一个堆分配器（比如 glibc 的 ptmalloc），维护着一片叫“堆”的连续虚拟内存区域。当你调用 malloc(n)，分配器会从空闲链表中找一块大小 >= n 的内存块，返回它的起始地址。如果链表里没有合适的，它就用 brk 或 mmap 向 OS 扩展堆空间。

free 则把这块内存还给分配器，插回空闲链表。注意——它并不会把内存还给操作系统（除非满足某些阈值），所以堆的大小只增不减是常见现象。

我个人习惯把 malloc 返回的地址想象成“借条”：你拿着它就能用，还回去之后借条就作废了。但操作系统并不知道你已经还了，所以 free 之后的指针仍然指向原来的地址——这就是很多 Bug 的源头。

提示：分配器为了管理内存块，会在每个块的前后附加元数据（比如块大小、状态标志）。这些元数据通常位于返回地址的前几个字节，所以越界写很容易把它们破坏，导致下次 malloc/free 崩掉。

五大常见陷阱，我几乎全踩过

下面这几个坑，每个都出自真实血泪史。我按出现频率排了序，你最好记在显眼的地方。

陷阱一：忘记 free → 内存泄漏

这应该是新手的“标配”错误。函数里 malloc 了一片缓冲区，中间 return 了就容易漏掉 free。我有个项目曾因为循环中反复 malloc 但不释放，48 小时后进程直接 OOM 被杀——那叫一个惨。

void bad_func() {
    char *buf = (char*)malloc(1024);
    // ... 中途遇到错误直接 return
    if (error) return;  // 泄漏！
    free(buf);
}
陷阱二：free 后继续使用（悬挂指针 / Use-After-Free）

你释放了内存，但还留着那个指针。后来分配器可能把这快内存又给了别人，你再通过旧指针读写，就会破坏别的数据，甚至被攻击者利用。我曾经在离职交接时看到前同事的代码里，free 之后没置 NULL，结果两个不同的模块都在用同一块内存——查了整整三天。

void dangling() {
    int *p = (int*)malloc(sizeof(int));
    *p = 42;
    free(p);
    *p = 99; // 未定义行为！可能正常，也可能崩
}
陷阱三：重复 free（Double Free）

同一个地址调两次 free，第一次释放后元数据已被分配器修改，第二次尝试释放野指针，堆结构立刻被破坏。就算不崩，后续的 malloc 也可能返回异常地址。解决办法很简单：free 后立刻把指针赋为 NULL。

陷阱四：分配大小错误

最常见的是忘记乘以元素个数，或者类型大小写错。比如 malloc(sizeof(int) * n) 写成 malloc(n)。还有算偏移时搞混 sizeof 和 strlen。加一字节的 \0 也很容易被忽略。

// 错误：只分配了一个 int 的大小
int *arr = (int*)malloc(10);
// 正确：要为 10 个 int 分配空间
int *arr = (int*)malloc(10 * sizeof(int));
陷阱五：未检查 malloc 返回值

你觉得内存不会耗尽？现实是残酷的。尤其在嵌入式或长期运行的服务里，malloc 返回 NULL 是常事。不检查就直接解引用，段错误没跑。我早期写的一个图像处理模块就因为这个，在低内存设备上崩了无数回。

char *buf = (char*)malloc(1024*1024*100); // 可能失败
if (!buf) {
    // 处理错误
    return -1;
}

一张图看清 malloc/free 流程与常见陷阱

下面这张图把整个生命周期和陷阱位置标了出来。你可以把它打印出来贴在工位上。

malloc/free 生命周期与常见陷阱 调用 malloc(n) 检查空闲链表是否有合适块 成功：返回指针 p 失败：返回 NULL 使用内存（读写 p） ⚠ 越界写入 调用 free(p) 正确：p = NULL 常见陷阱 • 忘记 free（泄漏） • 重复 free • 释放后继续使用 说明：绿色节点表示正确做法，红色/橙色节点表示常见错误或陷阱。 每次 free 后务必置 NULL，每次 malloc 后务必检查返回值。

避坑指南：我这些年总结的实战技巧

光知道陷阱还不够，得有具体对策。下面这几个是我一直在用的，分享给你。

问题 解决方案 说明
忘记 free 封装 RAII 或统一释放点 C++ 用 unique_ptr，C 里用 goto cleanup 模式
悬挂指针 free 后立即置 NULL 养成肌肉记忆
重复 free NULL 指针 free 是安全的 if (p) { free(p); p=NULL; }
大小错误 使用 sizeof(*p)*n 而非类型 类型变化时自动适配
未检查返回值 判断 NULL 并处理 拒绝裸 malloc

我曾经在一个网络库里用“函数出口统一释放”的模式：函数开始 malloc 后，全部资源指针挂在局部结构体里，函数末尾统一遍历释放。这样即使中间有多个 return 也不会漏。说白了，就是手动搞了个乞丐版 RAII。

总结一下我的核心理念：
  • 谁分配谁释放，明确所有权。
  • malloc 和 free 最好出现在同一函数，或者成对封装。
  • 每次 free 后置 NULL，每次使用前判 NULL。
  • 调试阶段开 AddressSanitizer 或 Valgrind，别偷懒。
← 上一章 📖 返回目录 下一章 →