1. 内存泄漏的根源：深入理解堆内存管理机制

内存泄漏，说白了就是「申请了内存，忘了还」。但为什么忘了还？这得从堆内存的底层机制说起。我做了十几年嵌入式开发，见过太多因为内存泄漏导致的诡异问题——系统跑着跑着突然卡死、重启、或者功能异常。每次排查到最后，往往就是某个地方少了一个 free 或 delete。

要根治内存泄漏，你得先搞清楚：malloc/free 和 new/delete 到底在底层干了什么？

1.1 堆内存 vs 栈内存：根本区别

先看个简单的对比：

特性	栈内存	堆内存
分配方式	编译器自动分配/释放	程序员手动申请/释放
速度	极快（一条指令）	较慢（需要系统调用）
大小限制	通常几MB（由链接脚本决定）	受限于系统物理内存
生命周期	函数返回即释放	直到手动释放或程序结束
典型问题	栈溢出	内存泄漏、碎片化

栈内存就像临时工位——用完就走，不用操心。堆内存呢？就像租仓库——你得记得什么时候退租，不然租金一直扣（内存一直占着）。

1.2 malloc/free 的底层原理

很多人以为 malloc 就是「从操作系统拿一块内存」。其实没那么简单。我拆开来说：

1.2.1 内存分配器的工作方式

常见的分配器有 ptmalloc（glibc）、jemalloc、tcmalloc。嵌入式里用得最多的是 ptmalloc 的变体。它的核心结构是这样的：

具体流程：

1. 检查空闲链表——有没有大小合适的块？
2. 如果有——切一块出来，返回地址
3. 如果没有——向操作系统申请更多内存（通过 brk 或 mmap）
4. 记录元数据——在分配的内存块头部写入大小、状态等信息

free 的时候呢？分配器根据你传的指针，找到对应的元数据，把这块内存标记为「空闲」，然后尝试合并相邻的空闲块。

1.2.2 元数据开销

每次 malloc 分配的内存，实际比你申请的多。分配器会在每个内存块前面加一个「头」，记录块大小、状态等信息。在 32 位系统上，这个头通常是 8 字节；64 位系统上是 16 字节。

// 你申请 100 字节
void *p = malloc(100);

// 实际分配：100 + 元数据头(8) + 对齐填充(4) = 112 字节
// 这就是为什么频繁小对象分配特别浪费内存

1.3 new/delete 与 malloc/free 的区别

很多人以为 new 就是 malloc 的 C++ 版本。嗯，只说对了一半。

操作	底层行为	额外工作
malloc	分配原始内存	无
free	释放原始内存	无
new	调用 operator new → malloc	调用构造函数
delete	调用析构函数 → operator delete → free	调用析构函数
new[]	分配连续内存 + 记录对象个数	对每个对象调用构造函数
delete[]	对每个对象调用析构函数	释放连续内存

1.4 内存泄漏的三种典型场景

根据我的经验，90% 的内存泄漏逃不出这三种：

• 忘记释放——申请了，但某些分支路径没走到 free/delete
• 释放错误——用 free 释放 new 出来的内存，或者用 delete 释放 malloc 出来的
• 循环引用——C++ 智能指针的 shared_ptr 互相引用，导致引用计数永远不为 0

1.5 知识结构图

下面这张图总结了堆内存管理的核心流程和泄漏点：

1.6 实战建议

我个人习惯在嵌入式项目中做三件事：

• 封装内存操作——写一个内存跟踪模块，每次 malloc/free 都记录地址、大小、文件名和行号
• 定期检查堆状态——用 mallinfo() 或自定义接口，监控堆使用量是否持续增长
• 优先用 RAII——C++ 里用 unique_ptr 代替裸指针，让析构函数自动释放

理解了这些底层机制，你再看内存泄漏问题，就不再是「碰运气式调试」了。你知道分配器怎么工作，知道元数据在哪，知道泄漏点可能出现在哪里。下一步，我们就要用这些知识去定位实际的内存泄漏——但那是后面章节的内容了。