企业官网建设流程全解析

1. 三个工具不是在同一个维度上比：先搞清楚各自的观测面

perf、Valgrind、Heap Profiler这三个名字经常被并列写在同一篇内存泄漏检测工具的对比文章里，但我踩过几次坑之后发现，把它们放进同一张对比表其实是一种误导——它们解决的问题层次完全不同。Valgrind是一位事后审计员，它会告诉你"这个块从第几行分配出去之后再也没人回收"；Heap Profiler是一位记账员，它每隔一段分配量记一笔账，告诉你"这个时间段内堆上多了多少、是谁贡献的增量"；perf更接近一位巡逻警，它按固定频率采样，告诉你"这个进程的 CPU 时间和内存写入集中在哪些符号上"。你拿审计员的标准去要求巡逻警做 malloc/free 配对，注定得不到答案。

真正让这组工具需要被放在一起讨论的原因，是它们在开销、观测粒度、是否允许在近似生产的环境里跑这三个约束下形成了互补。我在排查某个常驻服务内存缓慢上涨的问题时，第一反应是起Valgrind memcheck做全量检查，结果程序在 20 多倍的时间膨胀下根本跑不到泄漏累积的临界点，--leak-check结束时只报了几处启动期的一次性分配；换Heap Profiler挂上跑了六个小时，inuse_space曲线才呈现出爬升的趋势；最后用perf采样一堆异常增长的分配相关符号，才把嫌疑缩小到某个模块的缓冲区序列化路径。

这里有个容易混淆的概念要先厘清：泄漏在工程上有两种完全不同的含义。一种是"逻辑泄漏"，即程序彻底丢失了对一块已分配内存的引用，永远无法回收，这是Valgrind传统意义上的 lost；另一种是"增长失控"，即内存仍然有引用、仍然可回收，只是在稳态运行时它只增不减，从外部看表现为 RSS 单调上升，这是Heap Profiler和perf更擅长的战场。前者是 bug，后者往往是设计问题，比如缓存没有上限。混淆这两件事，会让你拿着错误的工具反复空跑。

1.1 为什么很多人用 Valgrind 抓不到线上那个泄漏

原因通常不是工具不行，而是场景不匹配。Valgrind走的是动态二进制翻译路线，被测程序在它的虚拟 CPU 上执行，每一次内存访问都被插桩检查。这套机制决定了几个硬约束：程序运行速度会掉一个数量级以上；被翻译后的进程对信号、时序、系统调用的行为和原生执行存在差异；部分内联汇编、SIMD 优化路径、自实现的分配器会让它产生误报或漏报。一个跑了三天才涨到 2G 的服务，你如果没法把它压缩成几分钟的可复现输入，就等于没有用Valgrind的窗口。

我一般的做法是：先把线上现象翻译成一个可复现的最小循环，把"三天涨 2G"压缩成"循环十万次涨 200M"，让泄漏速率肉眼可见。这一步做完，三个工具才有共同的输入。压缩不下来的，老老实实走Heap Profiler的长时间采样加perf的热点归因，不要指望Valgrind一步到位。

1.2 精度、开销与观测视角的三维权衡

把这三个工具放到同一坐标系里，可以拉出三个明显的坐标轴：精度（能否做到逐次分配的因果闭环）、开销（引入多大的时间与内存放大）、可观测面（只看用户态堆，还是能顺带看 mmap/brk 等系统调用与内核侧行为）。三者的分布大致是这样：

看清楚这张表，很多决策就不用再纠结了：如果你怀疑的是"某处少写了一个 free"，那是Valgrind的活；如果你怀疑的是"某个缓存或者队列在特定输入下只进不出"，那是Heap Profiler的活；如果你只知道"这个进程内存涨了，但不知道是哪段代码"，先用perf做归因，把搜索范围从整个二进制收敛到几个模块，再决定上哪个重武器。

2. 底层机制拆解：影子内存、采样探针与分配钩子的三种记账方式

2.1 Valgrind memcheck 的 V 位与 A 位

memcheck的核心是影子内存。它给进程的每一个字节都维护两份元数据：一份叫 V 位（validity，标记这个字节是否已初始化），一份叫 A 位（addressability，标记这个字节是否属于已分配的合法区域）。你的程序读一个字节，memcheck会同步检查对应的两位；你的程序把一个指针往下传，它会检查这个指针指向的块是否还活着。正是这两份元数据让越界写、读未初始化、use-after-free、重复 free 这些经典错误有了被逐次捕获的可能。

泄漏检测是这个机制的副产品。程序退出时（或者你用VALGRIND_DO_LEAK_CHECK客户端请求主动触发时），memcheck会扫描全部堆块，对每个块做一次可达性分析：从根集合（全局变量、栈、寄存器中残留的值）出发，看能否走指针链抵达这个块的首地址。根据结果把块分成几类，这是读Valgrind输出最需要先背下来的表：

still reachable是误判的重灾区。一个进程里所有"故意不释放、靠操作系统在退出时统一回收"的全局结构都会落进这一类，比如常量表、连接池、单例。你如果拿--show-leak-kinds=all看，很容易被几十个still reachable条目带偏方向，然后花两小时去"修复"一个设计上本来就该存在的静态缓存。

2.2 perf 的采样与 uprobe 探针是怎么"看到"内存的

perf完全不理解 malloc 和 free 的语义。它能提供的原材料只有两类：硬件/软件计数器，以及内核 tracepoint、kprobe、uprobe 这些埋点。所以用perf查内存问题，思路必须是"把内存问题转化成它可以观测的代理指标"。

第一条路是热点归因。内存增长几乎总伴随大量的写入操作，malloc之后紧跟着memset、memcpy，这些函数会消耗可观的 CPU 时间。用perf record -F 499 -g采样一段时间的调用栈，再按符号聚合，经常能直接看到某个序列化函数或某个缓冲区填充函数排在前面。它不告诉你"这里泄漏了"，但告诉你"这里在疯狂吃内存带宽"。

第二条路是系统调用归因。大块分配最终会落到brk或者mmap上，perf可以直接挂在这两个 tracepoint 上：

perf record -e syscalls:sys_enter_mmap -e syscalls:sys_enter_brk \ -g -o mm.data -- ./leak 200000 perf report --stdio -i mm.data --sort dso,symbol

第三条路是uprobe 计数。用perf probe在malloc的入口打点，统计调用次数与调用者分布，再和free侧的计数做差，就能粗略得到"净分配次数"。这条路在真实 glibc 上会被符号版本干扰（malloc实际是__libc_malloc加符号冲突处理），实操中不如直接用基于 BPF 的上层封装顺手，但原理是同一套。

关键认知是：perf给出的是概率性证据，你要用统计学的态度对待它。采样频率 499Hz 意味着短命线程上的一次性分配大概率采不到，你看到的分布永远是偏向"活得久、跑得多"的路径。

2.3 Heap Profiler 的采样式 malloc 记账与它的盲区

gperftools里的 heap profiler 走的是第三条完全不同的路：替换分配器。它把malloc/free/realloc全部接管，每次分配时记录下调用栈和大小。为了不把性能压垮，它做的是采样而不是全量记录——分配量大到一定程度才落一个样本，样本里带上当时的栈和这次分配的权重。dump 出来的.heap文件本质上是一张"调用栈 → 字节数"的映射表，pprof的工作就是把它聚合、排序、符号化。

因为采样存在，它天然看不见"每次 100 字节、调用几万次"的小泄漏，除非你把采样间隔调细。默认的 dump 触发条件也和累计量挂钩，通常是累计分配达到一个较大阈值、或者 in-use 内存增长达到一个较大阈值才落一次快照。这意味着你短跑几分钟可能一个.heap文件都拿不到，误以为工具没生效。

它的另一个盲区更隐蔽：接管分配器这件事本身会改变程序行为。程序原来的分配器如果是 glibc 的 ptmalloc，换到 tcmalloc 之后，小块合并策略、arena 划分、向操作系统归还内存的阈值全变了。原来那个"看起来在泄漏"的现象可能直接消失，也可能被放大成另一种形态。这一点我在第 6 节会展开讲，因为它是实际工作中最容易把结论带偏的地方。

3. 造一个能同时喂饱三个工具的泄漏样本

对比工具最忌讳拿别人的截图说事。自己写一个能覆盖多种泄漏形态的样本，才能把三个工具的输出差异看得真切。下面这份代码我用了很久，它同时包含了三类问题：彻底丢失指针、只有块内地址存活、以及一个"看起来像缓存、实际上没有上限"的全局增长。

/* leak.c —— 编译: gcc -g -O1 -fno-omit-frame-pointer -o leak leak.c */ #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #define CACHE_MAX 4096 static char *g_offset[512]; /* 只保存块内偏移地址 */ static int g_offset_slot; static char *g_cache[CACHE_MAX]; /* 无上限的全局缓存 */ static int g_cache_slot; /* 类型一：指针彻底丢失 */ static void leak_definitely(int iter) { char *p = malloc(4096); if (!p) return; memset(p, 0, 4096); snprintf(p, 64, "iter=%d", iter); /* 写完就丢，从不 free */ } /* 类型二：只有块内部地址存活 */ static void leak_possibly(void) { char *p = malloc(256); if (!p) return; memcpy(p, "payload", 8); g_offset[g_offset_slot++ % 512] = p + 32; } /* 类型三：全局缓存无上限增长，进程结束仍可达 */ static void cache_grow(void) { if (g_cache_slot < CACHE_MAX) { g_cache[g_cache_slot] = malloc(1024); if (g_cache[g_cache_slot]) memset(g_cache[g_cache_slot], 0x5a, 1024); g_cache_slot++; } } int main(int argc, char **argv) { int rounds = argc > 1 ? atoi(argv[1]) : 200; int paced = argc > 2 ? atoi(argv[2]) : 1; for (int i = 0; i < rounds; i++) { leak_definitely(i); leak_possibly(); cache_grow(); if (paced) usleep(1000); /* 放慢节奏，便于观察曲线 */ } printf("done: rounds=%d cache_slot=%d\n", rounds, g_cache_slot); return 0; }

3.1 编译参数为什么这么选

-g是硬要求，没有调试信息三个工具都只能给你一串地址，pprof更是完全没法出图。-O1而不是-O2是一个取舍：-O2下大量小函数被内联，Valgrind报出来的调用栈会坍缩成一两个大函数，你根本分不清是哪一层的分配；但-O0又会让代码慢到Valgrind更跑不动。-O1是我试过比较平衡的一档。

-fno-omit-frame-pointer是给perf准备的。x86-64 上默认的帧指针省略会让基于帧指针的调用栈展开失效，perf record -g采出来的栈会断成几截，--call-graph dwarf虽然有更完整的栈但需要保留.eh_frame且开销更大。加上这个编译选项，用最省事的--call-graph fp就能拿到可读的栈。

rounds和paced两个参数是刻意留的：跑Valgrind时用./leak 500 0（不 sleep，轮次小），跑长时间观察时用./leak 200000 1（带节奏，让曲线平滑）。同一个二进制喂不同的参数，能覆盖"精确复现"和"长时间观察"两种场景，省得你维护两份代码。

3.2 三类泄漏在设计上对应三种不同的验证目标

leak_definitely用来验证Valgrind的 definitely lost 报告，同时验证Heap Profiler能否把增量归到这个调用栈上。它的分配大小 4096 字节是个精心选的数字：超过阈值意味着大概率走mmap而不是从小块 arena 里切，在/proc/<pid>/smaps里能看到独立的匿名映射段，方便做交叉验证。

leak_possibly用来验证 possibly lost 的判定逻辑。块内部地址存活和块首地址存活在可达性分析里是两回事，很多人第一次看到这一类报告会懵，以为是工具误报，其实是自己的指针运算写错了。

cache_grow用来制造still reachable。它在进程退出时会被完整报出来，但它在语义上不是 bug——这正是我想让读者亲自体会的地方：相同的工具输出，对应完全不同的处理策略。

4. 三条命令的实际输出与读法

4.1 Valgrind：从 lost 分类到调用栈归属

最小可用的命令是这样：

valgrind --leak-check=full \ --show-leak-kinds=definite,indirect,possible \ --errors-for-leak-kinds=definite \ --num-callers=30 \ --track-origins=yes \ --log-file=vg.log \ ./leak 200 0

--leak-check=full才会在退出时做完整可达性分析并打印每条记录的调用栈，=summary只给你一个汇总数字，没什么用。--show-leak-kinds我一般只放前三类，把still reachable从报告里摘掉，避免噪音淹没关键信息；确实需要看的时候再单独加。--errors-for-leak-kinds=definite决定了哪些类别会导致进程返回非零退出码，这个在 CI 里做门禁很关键——只把 definite 设为阻断项，避免still reachable把流水线搞红。

报告读法上，先看末尾的汇总：

LEAK SUMMARY: definitely lost: 819,200 bytes in 200 blocks indirectly lost: 0 bytes in 0 blocks possibly lost: 51,200 bytes in 200 blocks still reachable: 200,704 bytes in 196 blocks

然后往上翻，每一条definitely lost都会带一个at 0x...: malloc (vg_replace_malloc.c:...)加上若干层by 0x...: 函数名 (源文件:行号)。定位的关键是找到第一帧属于你自己代码的那一行，vg_replace_malloc.c和libc里的帧统统跳过。上面的样本会精确指到leak.c里malloc(4096)那一行，不带任何含糊。

有一个细节值得单独说：--num-callers=30不是越大越好。栈深了之后Valgrind自身的开销会上升，而且超过实际栈深的层数会显示成一串???，反而干扰阅读。20 到 30 是我试过比较舒服的区间。

4.2 Heap Profiler：pprof 的 inuse_space 与 alloc_space 增量

先起一个带采样输出的运行：

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libtcmalloc.so \ HEAPPROFILE=/tmp/heap/leak \ HEAP_PROFILE_ALLOCATION_INTERVAL=67108864 \ HEAP_PROFILE_INUSE_INTERVAL=16777216 \ ./leak 200000 1

这里三个环境变量各管一件事：HEAPPROFILE是输出路径前缀，HEAP_PROFILE_ALLOCATION_INTERVAL控制"累计分配多少字节落一次快照"，HEAP_PROFILE_INUSE_INTERVAL控制"in-use 内存增长多少字节落一次快照"。默认值偏大，跑短任务可能一个文件都不出，所以验证阶段一定要调小，比如 64MB / 16MB 这一档。

拿到一串leak.0001.heap、leak.0002.heap之后，用pprof分析：

pprof --text ./leak /tmp/heap/leak.0002.heap | head -30 pprof --base=/tmp/heap/leak.0001.heap --text ./leak /tmp/heap/leak.0002.heap

第一条命令看的是某一时刻的存量，也就是inuse_space，它回答"现在堆上这 800M 是谁分配的"。第二条命令加--base，看的是两个快照之间的增量，它回答"这段时间新增的 200M 是谁分配的"。这两个视角差别很大：存量视角会被启动期的一次性大分配主导，增量视角才暴露真正的泄漏源。实际排查里我基本只用增量视角，因为稳态服务启动完成后，堆的构成理应趋于稳定，任何持续为正的增量都值得怀疑。

输出里最容易看混的是inuse_space和alloc_space两个指标。前者是"分配了但还没释放的总字节数"，后者是"历史上分配过的总字节数"。一个函数如果alloc_space极高但inuse_space很低，说明它是高频短生命周期分配，是性能问题不是泄漏问题；反过来inuse_space持续走高才是泄漏信号。这条区分我见过太多人搞错，值得单独记一笔。

4.3 perf：把"谁在分配"变成一张火焰图

perf侧我一般先跑两条命令。第一条看资源画像：

perf stat -e page-faults,minor-faults,major-faults,cycles,instructions \ ./leak 200000 0

minor-faults的绝对值能快速告诉你这个进程向内核要了多少新页。对同一个程序跑不同轮次，看 faults 是不是线性增长——线性增长本身就说明有东西在只进不出。第二条做热点采样：

perf record -F 499 --call-graph fp -g -o leak.data -- ./leak 200000 0 perf report --stdio -i leak.data --sort dso,symbol | head -40

注意perf report默认按comm,dso聚合，对定位代码没什么帮助，一定要加--sort dso,symbol，或者直接perf report --stdio -g看调用图模式，把memset、memcpy这类叶子函数的父调用链展开。

如果机器上有硬件 PEBS 支持，还可以试perf mem record，它能把数据地址一并进行采样，配合perf mem report能看到"哪些地址被反复写"。不过这条路对虚拟化环境、部分云主机的内核配置不太友好，跑不出来别死磕，退回用户态采样完全够用。

真实场景里，perf最有价值的输出其实不是某一行代码，而是一张收敛了搜索范围的清单。我上一个案例里，采样结果里memset相关调用占了 40% 以上的样本，全部来自一个第三方 JSON 序列化模块，顺着这个线索去查它的缓存层，五分钟就找到了没有淘汰策略的 map。换成Valgrind从头跑，估计得折腾一晚上。

5. 开销、参数与"敢不敢上灰度"的实测权衡

5.1 Valgrind 的几个必调参数

--fair-sched=yes是我在多线程程序里最先加的开关。Valgrind默认的线程调度策略倾向于让单个线程连续跑，这会让锁竞争类的问题消失，也会让竞态相关的泄漏不再出现。打开后它会用更接近真实的轮转调度，虽然更慢，但结果更可信。

--trace-children=yes用于有 fork/exec 的程序。默认情况下Valgrind只跟踪主进程，子进程是脱离它运行的，如果泄漏发生在 worker 里，你会得到一个"什么都没有"的干净报告，然后陷入深深的自我怀疑。这个开关会让所有子进程都被翻译执行，开销进一步上升，只在你确认有子进程时打开。

--gen-suppressions=all配合--suppressions=是做误报治理的标配。第三方库、底层图形栈、某些语言的运行时经常会产生你知道是噪音的报告项。把它们生成抑制规则固化到仓库里，下次跑就是干净的输出。这条路走顺了，Valgrind完全可以在 CI 里作为一个不阻断但持续记录的门禁项。

5.2 Heap Profiler 的采样间隔与 dump 时机

采样间隔是整个Heap Profiler用法的核心旋钮。间隔太粗，小泄漏全被漏掉；间隔太细，采样表本身膨胀，性能掉得厉害，还可能因为锁竞争改变程序行为。我的经验是：先粗后细。第一次跑用默认或更大的间隔，确认整体趋势和数量级；锁定嫌疑模块之后，把间隔调细一个数量级，专门盯那个模块。

dump 时机也可以用信号控制。较新版本支持通过环境变量指定一个触发信号，程序收到该信号时立即落一份快照，这对长时间运行的服务极其有用——你不需要重启它，也不需要等到某个累计量阈值，随时可以在观察到 RSS 异常时手动打一枪。具体变量名和是否支持要看所用版本的文档，老版本可能没有这个能力，那就只能靠间隔触发。

还有一个实操细节：HEAPPROFILE指定的目录要提前建好，且路径要在进程的写权限范围内。很多容器环境下/tmp是只读的或者挂的是很小的 tmpfs，几份快照就把空间写满了，程序于是莫名其妙地开始报错。我吃过这个亏，现在一律写到独立挂载的数据目录下，并加一个大小监控。

5.3 perf 的采样频率与符号化配置

采样频率-F 499是个刻意选的奇数。用 1000 这类整数容易和程序里某些周期性任务的频率产生共振，采出来的样本会系统性偏向某几个时间片。奇数频率能打散这种相关性，这是采样剖析里的通用经验。

符号化失败的排查顺序是这样的：先确认/proc/sys/kernel/perf_event_paranoid的取值，很多发行版默认是 2 甚至更严格，非特权用户采集内核事件会被直接拒绝，表现就是perf record报 permission denied；再确认内核符号表是否装了对应的 debug 包，否则内核侧的帧全是[unknown]；最后确认被测二进制没被 strip，file ./leak的输出里应该能看到with debug_info, not stripped。

容器里跑perf还要多一层：容器的perf_event_paranoid继承宿主，--privileged或者加上相应的 capability 才能采到完整事件。这一点在没有权限的环境里没有绕过办法，只能换用用户态采样，或者退回到Heap Profiler那条路。

6. 误判排查：RSS 不回落、still reachable 与 LD_PRELOAD 的行为漂移

6.1 分配器缓存不是泄漏

这是我见过最多的一类误判。程序跑完一轮任务，堆上的对象全释放了，但 RSS 纹丝不动。很多人据此断定"泄漏了"。实际原因是分配器把释放的内存还给了自己的空闲链表，没有调用brk收缩堆顶，也没有munmap归还大块。glibc 的 ptmalloc 还有动态的 mmap 阈值调整机制，一次大块释放之后阈值会被抬高，后续中等大小的分配就都走堆内 arena 而不是独立 mmap，表现出来就是"再也不会还给操作系统了"。

区分方法不难：看smaps里匿名映射的分布，如果那些增长的区域一直是同一批地址段，且堆上的inuse_space增量是零甚至为负，那就不是泄漏。更直接的办法是用Heap Profiler在两个时间点各 dump 一次，做--base对比，如果增量接近零而 RSS 在涨，基本可以断定是分配器缓存或者页缓存的手法。这类"增长"该做的是调分配器参数或者定期调用malloc_trim，而不是去翻代码找 free。

6.2 LD_PRELOAD 替换分配器带来的行为漂移

用LD_PRELOAD挂 tcmalloc 采样的做法很方便，但它有一个必须警惕的副作用：它换掉的不只是记录器，是整套分配策略。原来那个在 ptmalloc 下表现为缓慢泄漏的程序，换到 tcmalloc 之后可能因为更激进的小块合并而不复现；反过来，一个原来没有问题的程序也可能因为 arena 划分不同而出现新的增长曲线。更麻烦的是，某些程序自己实现了内存池并且假定malloc的行为特征，被替换后会走进完全不同的代码路径。

我现在的做法是：LD_PRELOAD只用于诊断，结论一定要回到原生分配器上验证一遍。如果原生环境下现象消失，那说明之前的结论是分配器差异导致的假象，得重新找线索。另外，Valgrind和 tcmalloc 绝对不能一起用——Valgrind自己需要接管整套内存管理，两者叠加会产生海量误报，memcheck会抱怨大量"未初始化"和"非法写"，全是噪音。

6.3 容器与权限相关的隐性失败

容器环境里三个工具都可能"静默失效"。Valgrind需要ptrace类能力，某些安全策略严格的运行时会直接拒绝，表现是进程起不来或者立刻退出，日志里只有一行含糊的错误。perf受perf_event_paranoid与 capability 双重限制。Heap Profiler的问题则出在写路径和LD_PRELOAD的路径解析上——libtcmalloc.so在基础镜像里可能压根没装，LD_PRELOAD找不到文件时会静默忽略，你以为在采样，其实什么都没发生。

我的检查清单是这样的：ldd确认动态库能被解析；用一个只做分配的小程序冒烟测试，确认快照文件真的被写出来了；确认perf record返回码为 0 且perf report里有非[unknown]的符号。这三步任何一步失败，后面所有的分析都是空中楼阁。

7. 选型决策与工程化组合

7.1 按场景而不是按"哪个更强"来选

我总结下来，选型判断应该从三个问题出发：这个现象能不能在几分钟内复现？进程允不允许重启？你手上有没有可疑模块的范围？三问的答案基本决定了工具。

有一个反直觉的结论值得强调：不要按"精度"排序去选工具，要按"能不能拿到有效输入"排序。精度再高的工具，如果跑不完你的复现场景，产出的就是零信息。

7.2 一条从告警到修复的流水线

我在实际项目里固化下来的流程大致分四步，每步都有明确的退出条件。

第一步是收敛范围。内存告警触发后，先看/proc/<pid>/smaps和/proc/<pid>/status，确认增长来自匿名映射还是堆、是不是集中在某个大的地址段。同时用perf record -p <pid> -F 99 -g挂上去采十分钟，按符号聚合看哪些函数在分配路径上高频出现。这一步的目标不是找到 bug，是把候选模块从几十个压缩到两三个。

第二步是验证增长。把可疑模块的关键路径加上计数埋点，或者用Heap Profiler在灰度实例上开采样，间隔调到一个能出文件的值，跑够时间拿到至少三份快照。用--base两两对比，确认inuse_space的增量确实落在第一步锁定的模块上。这一步的退出条件是：增量归属明确，且能用一条曲线证明它是单调的。

第三步是构造最小复现。从线上日志里抽一段输入，压缩成一个能在本地几秒内跑完的循环，把泄漏速率放大到肉眼可见。有了它，Valgrind才有用武之地，--leak-check=full一把梭，直接拿到分配行。这一步是整个流程里最花时间也最值钱的部分，它对定位精度的贡献远超任何一个工具的参数调优。

第四步是回归防线。把最小复现改造成一个带断言的测试用例，在 CI 里用Valgrind跑，--errors-for-leak-kinds=definite保证 definite lost 一旦出现就让流水线红掉；同时在灰度环境保留一个低频率的Heap Profiler采样开关，作为长期观察。这两道防线一快一慢，覆盖了"改坏了立即发现"和"慢速退化被捕捉"两个时间尺度。

这套流程走顺之后，我很少再纠结"哪个工具更好"这个问题。三个工具各自负责一个环节，缺一环就会出现"明明有工具却查不出问题"的尴尬。真正需要花心思的是复现构造和增量归因这两件事，工具的用法反而是最容易上手的那部分。

7.3 一个容易被忽略的交叉验证手段

最后补一个我常用的技巧：别只信工具的输出，用操作系统层面的数据做交叉验证。/proc/<pid>/smaps_rollup给出的是聚合后的 PSS 与 RSS，/proc/<pid>/statm给的是极简的页数统计，cat /proc/meminfo里的SReclaimable和Slab能告诉你内核侧有没有在涨。这三个数据源和工具的结论对不上时，通常是工具的观测面不全，比如Heap Profiler只能看malloc，程序如果直接走mmap分配大块（很多框架的缓冲区就是这么干的），它就完全看不见。gperftools 有个开关可以让 profiler 也统计mmap分配，但它默认是关闭的，很多人不知道要去打开，结果对着一个"堆上一切正常"的报告发愁，而实际上泄漏全在mmap那侧。

我自己在这上面栽过一次，一个图像处理的模块用mmap直接映射大缓冲区，堆采样里干干净净，Valgrind也只报了几处启动期的 still reachable。折腾半天才想起来去看smaps，发现是一串几百兆的匿名映射在缓慢增加。从那之后，我养成了一个习惯：先看smaps再上工具，让操作系统先把"钱花在哪儿"这件事讲清楚，工具负责回答"是谁花的"。