3. 内存泄漏检测原理

内存泄漏，说白了就是程序向系统申请了内存，用完之后不还。嵌入式系统资源本来就紧张，泄漏一点可能没事，但日积月累，系统迟早会崩。我见过不少产品，刚启动时跑得挺欢，运行几天后越来越慢，最后直接死机——十有八九就是内存泄漏在作祟。

3.1 内存泄漏的定义与分类

先给个准确定义：内存泄漏是指动态分配的内存对象，在程序失去对其所有引用后，无法被回收，导致该内存块永久占用。

根据泄漏的表现形式，我习惯把它们分成四类：

类型 描述 典型场景
堆内存泄漏 malloc/new 分配的内存，没有 free/delete 忘记释放局部指针
资源泄漏 文件句柄、socket、锁等系统资源未释放 open 后没 close
逻辑泄漏 对象仍被引用，但业务上已不再需要 全局容器不断添加元素
隐式泄漏 内存碎片化或内部碎片导致可用内存减少 频繁分配小对象

重点：嵌入式开发中，逻辑泄漏最隐蔽。我曾经排查过一个网络协议栈，每次收到特定报文就往链表尾部追加节点，但没有任何删除逻辑。表面上看指针都在，内存却一直在涨——这就是典型的逻辑泄漏。

3.2 引用计数与垃圾回收机制

有些语言自带内存回收能力，比如 Java 的 GC、Python 的引用计数。但在 C/C++ 的嵌入式世界里，这些机制要么没有，要么需要自己实现。

引用计数的原理很简单：每个对象维护一个计数器，记录有多少指针指向它。新增引用时计数加一，释放引用时计数减一。计数归零时，立即释放对象。

// 一个简单的引用计数结构
typedef struct {
    void *data;
    int ref_count;
} RefCountedObj;

void retain(RefCountedObj *obj) {
    if (obj) obj->ref_count++;
}

void release(RefCountedObj *obj) {
    if (obj && --obj->ref_count == 0) {
        free(obj->data);
        free(obj);
    }
}

我的经验：引用计数在裸机或 RTOS 环境下很实用，但要注意循环引用问题——两个对象互相持有对方的引用，计数永远不为零。我一般会在设计阶段就画出引用关系图，提前规避循环。

垃圾回收（GC）则更自动化。它从根集合（全局变量、栈变量）出发，遍历所有可达对象，标记为"存活"，然后回收未被标记的内存。常见的 GC 算法有标记-清除、标记-整理、分代回收等。

但在嵌入式 C/C++ 项目中，我很少用完整的 GC。原因很简单：GC 的暂停时间不可控，实时性要求高的场景根本扛不住。你想想看，一个电机控制程序突然卡顿几百毫秒去回收内存，那还得了？

3.3 Valgrind Memcheck 工作原理

Valgrind 是 Linux 平台上最常用的内存调试工具。它的核心组件 Memcheck，能检测出内存泄漏、越界访问、使用未初始化内存等问题。

Memcheck 的工作原理可以概括为三步：

  1. 插桩执行：Valgrind 将目标程序的每条指令翻译成中间表示（IR），然后插入检查代码。程序实际运行在 Valgrind 提供的虚拟 CPU 上。
  2. 影子内存：每分配一块内存，Valgrind 就创建对应的"影子位"，记录该内存的状态（已分配/已释放/可访问/不可访问）。
  3. 泄漏检测：程序退出时，遍历所有堆块，检查哪些仍处于"已分配"状态且无指针指向，报告为泄漏。

注意：Valgrind 会让程序运行速度降低 10-20 倍，内存占用增加 2-3 倍。所以它适合开发阶段的调试，不适合生产环境。我在做性能调优时，会先用 Valgrind 扫一遍，确认无泄漏后再上真机。

使用方式很简单：

# 检测内存泄漏
valgrind --leak-check=full ./my_embedded_app

# 显示详细信息
valgrind --leak-check=full --show-leak-kinds=all ./my_embedded_app

输出结果会告诉你：哪行代码分配的内存没释放，泄漏了多少字节，是"definitely lost"还是"possibly lost"。我个人习惯先修"definitely lost"，这些是板上钉钉的泄漏。

3.4 Hook 技术拦截 malloc/free

Valgrind 虽好，但在某些嵌入式环境（比如没有 MMU 的 MCU）上跑不了。这时候就需要我们自己动手——用 Hook 技术拦截 malloc/free，实现轻量级的内存泄漏检测。

Hook 的核心思路：替换标准库的 malloc/free，在分配和释放时记录日志。我常用的方法有两种：

  • LD_PRELOAD 方式：在 Linux 动态链接环境下，通过设置环境变量 LD_PRELOAD，让自定义的 malloc/free 优先于 libc 中的版本被加载。
  • 宏替换方式：在编译时通过宏定义，将 malloc/free 替换为自定义函数。
// 宏替换示例
#define malloc(size)  my_malloc(size, __FILE__, __LINE__)
#define free(ptr)     my_free(ptr, __FILE__, __LINE__)

void *my_malloc(size_t size, const char *file, int line) {
    void *ptr = malloc(size);  // 调用真正的 malloc
    // 记录分配信息：地址、大小、文件名、行号
    log_allocation(ptr, size, file, line);
    return ptr;
}

void my_free(void *ptr, const char *file, int line) {
    // 记录释放信息
    log_deallocation(ptr, file, line);
    free(ptr);  // 调用真正的 free
}

避坑指南：我曾经在替换 malloc 时，不小心在 my_malloc 里又调用了 malloc，导致无限递归。解决办法是使用 dlsym(RTLD_NEXT, "malloc") 获取真正的 malloc 地址，或者用静态链接的方式绕过。

有了 Hook 日志，我们就可以在程序退出时，遍历所有已分配但未释放的内存块，生成泄漏报告。配合哈希表或红黑树，查找效率能做到 O(1) 或 O(log n)。

内存泄漏检测原理知识体系 内存泄漏检测 泄漏定义与分类 引用计数与GC Valgrind Memcheck Hook技术拦截 堆内存泄漏 资源泄漏 逻辑泄漏 隐式泄漏 标记-清除/整理 插桩→影子内存→检测 LD_PRELOAD/宏替换 核心原则 嵌入式环境优先使用Hook技术，资源充足时可用Valgrind 引用计数适合裸机/RTOS，GC适合资源充裕的Linux系统

这张图把本章的知识体系串起来了。从内存泄漏的定义出发，到引用计数和 GC 两种回收机制，再到 Valgrind 和 Hook 两种检测手段。我个人建议，在资源受限的嵌入式平台上，优先实现 Hook 方案；在开发阶段的 Linux 模拟环境中，用 Valgrind 做全面扫描。两者配合，基本能覆盖 90% 以上的内存泄漏问题。

← 上一章 📖 返回目录 下一章 →