📚 课程目录第4章内存性能分析工具介绍

内存性能分析工具介绍

做SDK接入，最怕什么？我猜八成的人会说是“内存问题”。

内存泄漏、野指针、缓冲区溢出……这些东西在客户现场蹦出来，你就等着崩溃吧。我个人习惯是：在代码合入主干前，先用工具扫一遍。不过很多人只听说过工具名，真要用起来却一头雾水。

嗯，今天我就带你把常用工具捋一捋。说白了，就四款最趁手：Valgrind、perf、heaptrack、AddressSanitizer。

常用工具概览

你想想看，每个工具都有自己的脾气。有的慢但准，有的快但信息碎。我简单列个表，心里有个底。

工具	核心能力	运行时开销	适合场景
Valgrind（memcheck）	检测内存泄漏、非法访问、未初始化读取	10x~50x 变慢	开发期精细调试
perf	硬件性能计数、缓存 miss、页错误	极低（<5%）	线上/准线上性能瓶颈定位
heaptrack	堆内存分配轨迹、调用栈聚合	2x~5x 变慢	定位高内存分配热点
AddressSanitizer（ASan）	编译插桩，检测堆/栈/全局越界	2x~3x 变慢	持续集成 / 单元测试

我在项目中遇到过，有人拿着 Valgrind 去压线上环境，结果服务直接超时。其实 Valgrind 只适合小流量 mock 验证。线上问题，交给 perf 或 heaptrack 更实在。

Valgrind 实战：找到那个泄漏点

记得有一次我接入一个第三方面部识别SDK，跑测试时内存只升不降。直觉告诉我有泄漏。于是我用了这行命令：

valgrind --tool=memcheck --leak-check=full \
         --show-leak-kinds=all --track-origins=yes \
         ./sdk_sample --test-count=100

刚开始跑特别慢，一杯咖啡还没喝完，结果就出来了。它告诉我face_recognition_init()里分配的模型缓冲区没有释放。我改完后再跑一遍，内存曲线就平了。

注意：Valgrind 会使程序变慢 10 倍以上，千万不要在生产环境直接跑。建议在干净容器里用最小测试用例验证。

perf 与 heaptrack 配合定位缓存热点

SDK 接入后 CPU 居高不下？很可能跟缓存 miss 有关。我曾经排查过一个图像预处理SDK，CPU 占用 80% 但似乎没在做有用的计算。用 perf stat 一看：

perf stat -e cache-misses,cache-references,page-faults \
         -p $(pidof sdk_demo)
# 输出：cache-misses 占比极高，超过 45%

这说明内存访问模式有问题。我又用 heaptrack 抓了一下分配热点：

heaptrack ./sdk_demo
# 用 heaptrack_print 看结果
heaptrack_print heaptrack.sdk_demo.1234.gz

结果发现，每次处理一帧图像都重新 malloc 了一大块临时缓冲区。改成线程局部复用后，cache miss 降到 12%，CPU 占用降到 30%。

  核心思路：先粗筛（perf），再精定位（heaptrack / Valgrind），最后优化，每一步用的工具不同，别混着来。

AddressSanitizer 接入 CI 流水线

我建议，每个 SDK 单元测试都开启 ASan 编译。说白了就是 CMake 里加一行：

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address -fno-omit-frame-pointer")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fsanitize=address")

然后跑测试。一旦有越界或 use-after-free，它会直接 crash 并打印调用栈。比事后分析快得多。

小技巧：ASan 在 debug 模式下开销不大，但 release 下最好关闭。另外注意动态库也要用 ASan 编译，否则可能误报。

上面这张流程图画的就是我平时排查内存问题的标准打法。从启动应用 → 监控内存 → 检测异常 → 定位泄漏/热点 → 修复优化 → 验证通过，中间可能有多个来回。

刚开始用工具时，你会觉得麻烦。但用习惯后，你会发现：80%的内存问题在工具第一遍扫完就能暴露。剩下20%才需要靠经验和动态追踪。

好了，这一章就聊这么多。工具只是辅助，顺手就好，别为了用而用。