内存性能分析：泄漏排查与快照分析

内存泄漏，说白了就是程序吃进去的内存不吐出来。你想想看，一个服务跑几天还好，跑一个月就开始卡顿，再跑久点直接 OOM 挂掉。我遇到过好几次线上事故，最后查出来都是这种“温水煮青蛙”式的问题。

这一章，我们就来聊聊怎么把这些“偷内存的小偷”揪出来。

内存泄漏的本质

在 C/C++ 的世界里，你手动分配的内存，就得手动释放。忘记释放、释放了错误的位置、或者还有指针指向它却提前释放了——这些都算泄漏。

Valgrind：经典的内存泄漏检测器

Valgrind 的用法很粗暴——把你的程序包起来跑。它会拦截每一次内存操作，记录是谁分配了、有没有释放。

# 基本用法
valgrind --leak-check=full ./my_program

跑完你会看到类似这样的输出：

==12345== 40 bytes in 1 blocks are definitely lost in loss record 1 of 2
==12345==    at 0x4C2B0E0: malloc (vg_replace_malloc.c:299)
==12345==    by 0x4005B4: main (example.c:5)

怎么看这些信息？ 重点关注“definitely lost”——这是铁证如山的泄漏。至于“possibly lost”嘛，可能是你数据结构设计得比较复杂，不一定是真泄漏。

AddressSanitizer：编译时的守护者

Valgrind 跑起来太慢了？那就试试 AddressSanitizer（简称 ASan）。它是编译器自带的工具，插入桩代码来检测内存错误。

# GCC/Clang 启用 ASan
gcc -fsanitize=address -g -o my_program main.c

# 运行时环境变量（可选）
ASAN_OPTIONS=detect_leaks=1 ./my_program

ASan 的性能开销通常在 2 倍以内，比 Valgrind 的 10-50 倍好太多了。我在做性能调优时，一般先上 ASan 快速过一遍，确认没有明显问题再考虑上 Valgrind。

特性	Valgrind	AddressSanitizer
运行方式	虚拟化执行	编译时插桩
性能开销	10-50倍	约2倍
检测范围	内存泄漏、越界、未初始化	内存泄漏、越界、使用后释放
推荐场景	深度分析与调试	日常开发与CI集成

堆内存快照：定位内存膨胀

泄漏不是唯一的问题。有时候内存是逐渐涨上去的——比如一个缓存池越积越大，或者某个线程池的内存没有及时回收。这时候就需要堆快照了。

拿 jemalloc 举例，它的 profiler 可以生成堆快照：

# 环境变量启用 profiler
export MALLOC_CONF="prof:true,prof_active:true,lg_prof_sample:17"
./my_program

# 触发快照
kill -SIGUSR2 <pid>  # 生成 heap.prof.<n>.heap 文件

# 分析差异
./jemalloc.sh jeprof --show_bytes --base=heap.prof.0001.heap \
  ./my_program heap.prof.0012.heap

这样就能看到两个时间点之间，哪些调用栈分配了新的内存。

火焰图：可视化内存分配热点

火焰图最初用来分析 CPU 热点，但这招同样适用于内存。说白了，就是把“哪些函数分配了最多的内存”画成一张图。

做法很简单——通过 eBPF 或 perf 采样内存调用事件，或者用 jemalloc/tcmalloc 的 profiler 输出堆栈信息，然后用 FlameGraph 脚本画图：

# 采集数据
perf record -e cycles:u -e mem:u -g -o perf.data ./my_program

# 生成折叠堆栈
perf script -i perf.data | \
  stackcollapse-perf.pl > out.folded

# 生成火焰图
flamegraph.pl out.folded > memory_flame.svg

看火焰图的时候，重点注意两块：一是横向最宽的“平台”，代表占用内存最多的路径；二是顶层的“尖刺”，如果某个函数调用栈特别高，可能意味着热点调用有内存泄漏。

嗯，这些工具用熟了，排查起来就顺手了。下一个内存问题来找你的时候，别慌，按这步来就行。