聊到Linux下的C++内存泄漏排查，很多人第一反应就是Valgrind，跑一把拿到个报告，然后对着“definitely lost”发愁。可实际项目里哪有这么简单，部署环境、长稳测试、多线程、第三方库，每一个都能让排查过程变成一场持久战。我这些年经手过不少内存问题，从几分钟定位的小泄漏，到折腾一周才找到根因的隐蔽增长，积累下来的套路和工具链基本稳定了，所以想把这些东西整理成一份能照着用的排查手册，看看怎么一步步缩小范围、锁定证据、最终把泄漏点揪出来。
这份手册适合谁？刚接手C++服务端维护的开发者、准备做内存专项治理的团队，以及那些已经被线上内存缓慢上升折腾到头疼的人。我会从原理讲起，把Valgrind、AddressSanitizer、GDB这类工具怎么搭配、什么时候用哪个、报告怎么读一次说清楚。
1. 先搞清楚内存泄漏的本质：从现象到根因
1.1 你以为的“泄漏”和真正的“泄漏”
排查之前得先统一认知。很多人看到进程RSS一路上涨就喊内存泄漏，其实“内存占用高”和“内存泄漏”是两个概念。真正的泄漏是程序动态分配的内存失去了所有引用，既无法释放也无法访问，这块内存彻底“丢”了。而RSS上涨可能只是缓存、线程栈、内存池的正常扩张，甚至可能是业务流量增长带来的合理水位抬高。
C++里的泄漏常见有几种形态。第一种是裸指针丢失，new出来的对象没有delete，指针变量出了作用域就再也找不到那块内存。第二种是容器无界增长，比如往全局map里塞数据但从不删除，哪怕每个对象都不大，量变引发质变后内存照样被打满。第三种是异常路径泄漏，正常逻辑里释放了，但某个分支提前return或抛异常，把释放动作跳过了。第四种比较隐蔽，是第三方库内部缓存或线程局部存储导致的“假泄漏”，严格来说是库自身的行为，不算你代码的bug，但现实里也归你头疼。
先分辨清楚问题属于哪一类，后续用工具时才不会浪费一整天。
1.2 为什么进程起来后内存不回落？先排除这几个“干扰项”
在跑重型工具之前，我建议先看几个基础指标，很多时候根本不需要Valgrind出场。
首先是glibc的arena机制。多线程程序在glibc下malloc会创建多个arena，每个arena会预分配一大块内存，这个内存不会因为线程空闲就马上归还操作系统。如果程序是200个线程，光arena的虚存占用就可能很惊人，但这不算泄漏。
其次要看内存池。很多框架和自研组件会预分配内存池，比如连接池、对象池，启动后一次性申请大块内存反复复用。此时RSS看起来稳定在高位，其实内部没有持续增长，只要没有单调递增就不是泄漏。
然后是线程栈。每开一个线程默认栈大小可能8MB，如果线程频繁创建销毁，底层虽然做了缓存，但短期看RSS也会有起伏。服务端程序如果有动态伸缩线程的机制，千万别把线程波动当成泄漏。
判断泄漏与否最靠谱的方法是监控“趋势”：采样RSS或者RSS中的匿名页部分，观察24小时、48小时的变化。如果增长是台阶式（涨到某水位就稳定）那是正常扩容；如果是持续线性增长、重启后回落，那基本跑不掉是泄漏。
2. 排查工具选型：Valgrind、ASan、GDB、Perf怎么搭配
2.1 四个主流工具的特性和适用边界
工欲善其事，必先利其器。我把日常用到的内存排查工具放在一起做了个对比，方便你根据场景选择：
| 工具 | 原理 | 适用场景 | 主要瓶颈 |
|---|---|---|---|
| Valgrind Memcheck | 动态二进制插桩，模拟CPU执行并跟踪每次内存访问 | 小规模程序、单元测试、明确怀疑某模块泄漏 | 比正常慢10~50倍，内存占用翻数倍 |
| AddressSanitizer | 编译期插桩，配合shadow memory检测越界和泄漏 | 开发期自测、CI回归、单测覆盖 | 需要重新编译，无法直接对线上二进制使用 |
| GDB + pmap | 查看进程内存映射、attach调试、手动调用函数 | 线上问题初步定位，查看堆内存分布 | 静态分析为主，动态分配过程难跟踪 |
| Perf + Heaptrack | 采样分析、记录每次malloc/free调用栈 | Coredump分析、堆分配热点、泄漏调用栈获取 | 数据量大，需要做聚合分析 |
先别急着想“哪个最强”，工具之间是互补关系。Valgrind适合在测试环境重现问题，AddressSanitizer适合从源头拦截，GDB适合线上快照取证，Perf和Heaptrack负责回答“谁在分配内存”。
2.2 选型的一个核心原则：先复现，再套工具
没有复现路径就盲目跑Valgrind，等于让一个慢10倍的程序在压力下跑几十分钟，收益率极低。我的经验是先做最小复现：把可疑模块摘出来，写一个能循环触发路径的小测试程序，确认能稳定复现内存增长后，再上重型工具。这一步省下的时间远比想象中多。
如果问题只在线上偶发，优先用GDB抓现场，比如用gdb -p PID看进程状态，配合pmap -x PID观察不同地址段的增长特征。等到能确定是可复现的堆内存泄漏时，直接上ASan或者Valgrind才是正解。
3. Valgrind泄漏排查实操：从安装到定位
3.1 安装和基本参数解析
Valgrind在绝大多数发行版里都有现成包，Debian/Ubuntu系用apt，CentOS/RHEL系用yum。装完别急着直接上，建议先跑一个小程序确认Memcheck工具可用：
valgrind --tool=memcheck --leak-check=full ./你的测试程序如果程序正常，输出末尾会出现HEAP SUMMARY和LEAK SUMMARY。这几个参数建议固定搭配：
--leak-check=full：输出每个泄漏点的详细堆栈。--show-leak-kinds=all：把definite、indirect、possible、reachable全部展示。默认只显示definite，但实际排查时“still reachable”也可能是问题。--error-limit=no：关闭错误数量上限，避免大程序报告被截断。--num-callers=20：增加调用栈深度，否则嵌套一深就看不到真正源头。
3.2 一个小栗子：从堆栈到代码行
下面这段代码模拟了最常见的“new了忘删”问题：
#include <cstdlib> #include <vector> void leak_once() { int* p = new int[1024]; if (rand() % 2 == 0) { return; } delete[] p; } int main() { for (int i = 0; i < 10; i++) { leak_once(); } return 0; }用g++ -g test.cc -o test编译后，再跑Valgrind：
valgrind --leak-check=full --show-leak-kinds=all ./test输出里会有一段类似：
==12345== 40,960 bytes in 10 blocks are definitely lost in loss record 1 of 1 ==12345== at 0x4C2C19F: operator new[](unsigned long) (vg_replace_malloc.c:423) ==12345== by 0x10875A: leak_once() (test.cc:5) ==12345== by 0x10877B: main (test.cc:12)看到没有，程序已经是调试符号打开状态，直接从main推断到leak_once里的第5行。这就是Valgrind的核心价值：明确的分配点栈。对于这种最常见的definite lost类型，照着栈去改代码就好。
3.3 Valgrind的限制和误报处理
Valgrind不适用于大程序和高并发压测，因为插桩开销太大。有些第三方库会把一些单例对象保留到进程退出，这会被标记成still reachable，如果业务逻辑合理，这种情况是正常的。还有一种“possible lost”，指向未初始化的指针丢失，多数时候是库内部实现，不用太紧张。
我在实际项目里最头疼的是“动态加载.so”场景。插件系统通过dlopen加载模块，模块内部分配的内存保存在全局静态变量中，即使插件卸载也不会释放。这未必是开发者的错，可能是插件设计本来就要常驻。这时候Valgrind能告诉你对象归属哪个.so，你需要结合业务判断是否属于“必须常驻”的设计。
提示：如果程序里有大量自写内存池，Valgrind几乎必然会把池内未归还的块标记为still reachable，因为内存池技术上讲没有“释放”，只是复用了。遇到内存池要先把池日志打开，或临时禁用池让Valgrind看到真实分配。
4. AddressSanitizer快速上手，以及生产环境替代方案
4.1 ASan比Valgrind快在哪
Valgrind动辄让程序慢几十倍，ASan虽然也不便宜，通常在1.5~3倍左右，但已经能让多数测试程序承受。ASan能做到这个性能，靠的是编译期插桩和shadow memory设计，它在程序访问每个地址时通过影子内存检查合法性，检测越界、UAF等问题的同时，也集成了LeakSanitizer来检测泄漏。
用法非常简单，用GCC或Clang编译时加：
g++ -fsanitize=address -fno-omit-frame-pointer -g test.cc -o test_asan跑测试程序时，如果出现泄漏，LeakSanitizer会在退出阶段打印报告。它和Valgrind报告格式类似，同样有调用栈，但栈可读性有时更差一点，因为某些中间帧来自编译器生成的check代码。
ASan最强的场景是接进CI里的回归测试。你不需要每次都人为分析，只要测试覆盖够，跑一次就能看到是否新增泄漏。我习惯在测试镜像里同时保留普通版本和ASan版本，普通版本跑性能测试，ASan版本跑内存安全扫描。
4.2 ASan的误报和“压不住”的问题
ASan也不是万能。第一，它要求代码可重新编译，线上不允许你也办法。第二，它自带的内存分配器不允许某些极端对齐分配，碰到用自定义new的第三方库时候会出现奇怪的崩溃，通常是shadow memory不匹配，解决方式是给那个库关掉ASan插桩。第三，ASan对fork之后的多进程程序支持不完美，尤其使用system()或者daemon化场景要格外小心。
生产环境替代方案主要有两个思路。一个是GWP-ASan，这是LLVM社区在做的一种采样型检测器，可以部署到生产环境对部分分配做腐败检测，但泄漏检测能力弱于完整ASan。另一个是用Heaptrack记录分配栈和释放栈，即使程序已经在线上跑，也能拿到完整的堆分配火焰图，对定位“谁在持续分配内存”非常有用。
5. 复杂泄漏场景定位与深度排查
5.1 shared_ptr循环引用：工具很难扫出来
Valgrind和ASan只能检测对象是否丢失，但如果对象是被shared_ptr循环引用锁死的，这些对象永远不会被释放，也不算“丢失”，因为引用计数还指来指去。这类泄漏的工具报告往往干干净净。
我常用的办法是看对象计数。如果怀疑某类对象泄漏，就给它加一个静态原子计数器，构造加一、析构减一，周期性输出当前存活数。跑长稳测试时观察计数是否单调上涨，上涨就说明实例只增不减。然后再结合weak_ptr检测，或者打断某个循环引用修复。
这个“打点”手法对业务级泄漏特别有效，比任何工具都直接。因为工具只看内存，不知道“一个业务对象”应该什么时候销毁，只有代码作者清楚对象生命周期。
5.2 多线程环境下栈不准，怎么结合GDB捞现场
Valgrind和ASan在跟踪分配时会记录调用栈，但多线程程序里，一个线程可能从全局队列取任务，任务对象在另一个线程里分配，实际执行逻辑栈完全对不上。这时候报告虽然指向“某线程在xxx位置new”，但那个位置只是个通用入口，根本没有业务语义。
我的做法是三层联动：先按ASan报告确定对象大小和频率，再看pmap观察增长集中在哪个内存区间，最后用GDB attach到进程，调用thread apply all bt看所有线程栈，找到谁在不断累积对象。如果怀疑某个容器在膨胀，GDB里可以用p map.size()直接看长度，如果长度异常增长就顺藤摸瓜找到插入点。
还有一种情况是对象真的泄漏但分配栈极其高频，每毫秒调用几十次，导致抽样工具缓存溢出。这时候降低采样率，或者在入口增加批量分配接口，让栈更有辨识度，能显著提升定位效率。
5.3 判断“缓慢增长”是缓存还是泄漏的实践方法
服务端进程内存缓慢上升，是最费神的场景。比如每24小时涨1%，不看一星期根本发现不了。我梳理过一套判断流程：
| 现象 | 候选原因 | 验证方法 |
|---|---|---|
| 涨到某水位停止 | 缓存、连接池、线程池扩容 | 观察是否收敛，收敛即正常 |
| 与请求量正相关、下降时回落 | 每个请求产生的临时对象没及时释放 | 用malloc统计或Heaptrack对比召回 |
| 与请求量无关、持续爬升 | 全局对象泄漏、日志缓冲膨胀、线程漏销毁 | 打点计数，重启后看是否从头开始涨 |
| 只在特定操作后跳涨 | 某种业务操作一次性分配大量常驻对象 | 复现该操作并对比操作前后堆快照 |
对“缓慢增长”场景最忌讳的是直接在压力机上跑Valgrind，因为压力机看的是磁盘和网络，Valgrind一开，吞吐塌缩，根本复现不出线上形态。我倾向于用Heaptrack在测试环境复现业务流量，跑30分钟就导出堆差异，通常能找到泄漏点。
6. 常见的误区和值得坚持的工程化手段
6.1 “内存泄漏”背锅名单里，哪些其实是冤枉的
排除过很多“假泄漏”之后，我把最常见的冤枉场景列出来。第一是日志框架的内存缓冲，比如异步日志内部维护一大块缓冲池，崩溃时或者某个瞬间看起来占用很高，但它不是泄漏。第二是线程局部缓存，TLS里保存的对象只有在线程退出时才释放，如果线程池复用线程，这些缓存永不消失，但它有界。第三是全局单例的懒加载，比如某个单例内部包含了一个巨大缓存，首次使用后就常驻，这在长稳测试早期会表现为台阶式上涨。
真正的泄漏一定要符合“单调不减”特性。哪怕是几乎零增长的缓慢上升，只要在足够长的时间窗口内持续上升，就应该当成泄漏处理。反过来，稳定在高位不回落，那只是合理使用边界的问题，不是泄漏。
6.2 把排查能力前置到日常开发流程里
这些经验总结到最后，最值钱的其实是预防体系。我现在的做法：
- 所有新增模块在MR阶段跑一遍ASan单测，至少保证主要路径无泄漏。
- 内存专项测试纳入每周回归，用
valgrind --leak-check=full跑核心流程。 - 线上服务内置内存统计模块，周期性输出RSS、VMSize、堆分配总量以及关键业务对象存活数。
- 保留一份Heaptrack的“堆快照基线”，版本发布后如果监测到堆增长趋势异常，直接对比基线和当前快照。
最后分享一个小经验。很多人以为排查内存泄漏是事后补救，其实最优解是“让泄漏在代码评审阶段就暴露”。在code review里多问一句“这个对象生命周期归属谁”，比什么工具都顶用。我见过太多人花一晚上用工具分析一个几分钟能通过code review发现的问题。工具能帮你验证假设，但替代不了一个清晰的资源所有权设计。排查资料的尽头，往往是写代码时的那份谨慎。
