手写内存检测工具：Hook malloc/free 定位线上泄漏

做服务端开发这些年，内存问题一直是最让人头疼的疑难杂症。线上服务跑着跑着内存一路爬升，或者偶发崩溃，core dump 一拉发现栈早就被踩烂了，这种场景我猜不少人都经历过。排查这类问题，大家第一反应就是 Valgrind 或者 AddressSanitizer，但真到用的时候你会发现，这些工具要么慢得让人没法在测试环境跑全量用例，要么就是只能本地复现，到了线上完全使不上劲。后来我索性自己写了一个自定义内存检测工具，用轻量级的 hook 方案把 malloc/free 的调用都拦截下来，专门解决这些场景下的内存问题。这篇文章就把这套工具的完整设计思路、核心实现和实操过程拆开讲清楚，想自己动手折腾一套的可以参考着来。

1. 为什么非要自己写一个内存检测工具

1.1 现有工具的真实痛点

先聊聊大家常用的几个工具。Valgrind 的 memcheck 确实强大，能检测越界、使用未初始化内存、泄漏，但它有个致命的短板：慢。我实测过一个中等规模的服务，在 Valgrind 底下跑，性能直接下降 20 到 50 倍，原本 3 秒能跑完的用例要等一两分钟。这在单测场景下还能忍，想做压测或者长稳测试，基本不可能。

AddressSanitizer（ASAN）速度上好了很多，大概只有 2 到 3 倍的开销，但它要求整个项目重新编译，而且对编译器版本、链接方式有要求。更麻烦的是，ASAN 编译出来的版本行为有时和线上版本有差异，特别是涉及自定义内存池、第三方闭源库的时候，经常遇到 "unpoison" 报错或者误报，排查起来又是一堆额外的工作。

这些工具都解决不了另外一个非常实际的问题：线上问题怎么办？服务在线上跑了两周，内存持续增长但是很缓慢，每天涨 1%，这种"温和泄漏"用 Valgrind 因为太慢根本没法长时间挂载，ASAN 又不能直接上生产环境。最后我在实践中发现，与其被这些通用工具的各种限制卡住，不如针对自己的业务形态写一个只采集核心数据、开销可控的自定义内存检测工具。

1.2 自定义工具解决的三个现实场景

我复盘了一下，真正推动我去做这件事的需求主要有三个。

• 长稳测试场景的内存趋势观测：服务连续跑 48 小时甚至 7 天，需要每分钟记录一次进程的内存分配总量和各类分配占比，观测是否存在缓慢增长。
• 定制定位需求：比如我想知道某个模块内部的内存分配来源分布，或者想统计某个业务高峰期临时对象到底创建了多少个，这些通用工具都给不了。
• 线上轻量观测：在线上环境只开一个极低开销的统计模式，不打断业务，持续记录分配次数和字节数的粗粒度数据，配合监控系统做趋势告警。

1.3 明确目标：工具要能做什么

动手之前，我先把需求列成了一个清单，避免写着写着就跑偏。

2. 核心设计思路：技术方案选型与数据组织

2.1 三种 hook 方案怎么选

要实现对 malloc/free 的拦截，市面上主流有三种方案：宏替换、dlsym 符号拦截、LD_PRELOAD 预加载。我三种都折腾过，各自的优缺点比较清楚。

宏替换是最简单粗暴的方式，在编译期通过 #define malloc(size) my_malloc(size, __FILE__, __LINE__) 把所有调用替换成自己的函数，好处是能拿到文件名和行号，坏处是只能替换你自己的代码，第三方静态库和系统库调用的 malloc 还是走原来的路径，而且只要有一个文件忘记包含头文件，那个文件的分配就漏统计了。

dlsym 符号拦截是运行时方案，在自己的 so 里定义 malloc 函数，通过 dlsym(RTLD_NEXT, "malloc") 找到真实的 malloc 地址，然后做一层包装。好处是能覆盖整个进程的所有分配调用，包括第三方库；坏处是实现相对复杂，要处理递归调用、线程安全、重入等问题。

LD_PRELOAD 本质上和 dlsym 是配合使用的，通过环境变量把你的 so 预加载到进程里，实现开箱即用。但因为是全局生效，写不好非常容易崩，也容易被安全软件拦截。

我在工具里采用了 dlsym + LD_PRELOAD 为主、宏替换为辅的混合策略。主程序里需要精确源码位置的场景用宏替换，全局内存观测走 LD_PRELOAD 模式。两套逻辑可以共存，互不干扰。

2.2 需要采集哪些核心数据

设计数据结构的时候，我本着"够用就好"的原则，没有一上来就堆一堆字段。真正验证下来，核心的字段就这么多：

c复制typedef struct mem_record {
    void *ptr;              // 分配的内存地址
    size_t size;            // 分配的大小
    uint64_t timestamp;     // 分配时间，用单调时钟，避免墙钟被修改
    uint32_t thread_id;     // 分配线程 ID
    int caller_count;       // 回溯到的调用栈深度
    void *caller_stack[16]; // 调用栈地址，最多回溯 16 层
    struct mem_record *next;
} mem_record_t;

这个结构体每条记录大概占 200 字节左右。一开始我担心这个开销会不会太大，实测下来，单条记录 200 字节的成本和分配本身的开销相比完全可以接受，因为一次 malloc 内部本身就有不少元数据开销。

有个细节值得单独说：时间戳我用的是 clock_gettime(CLOCK_MONOTONIC) 而不是 time()，因为 time() 返回的是墙钟时间，NTP 同步或者人工改时间都会导致趋势图出现诡异的跳变，排查问题的时候容易被误导。

2.3 数据组织与输出格式设计

数据组织上，我用了一个全局哈希表来管理所有未释放的内存记录，key 是指针地址，value 是记录结构体。分配时插入，释放时删除。哈希表的好处是存取都是 O(1)，不会因为分配次数增多导致查找变慢。

同时为了支持"按调用点聚合"的统计需求，我维护了一个全局统