massif输出文件名必须含%p以确保唯一性，否则多进程混杂导致解析错误；需统一开启--pages-as-heap=yes、编译参数及libc版本才能可靠对比。
Massif 输出文件名必须带 %p 才能区分多次运行
不加 --massif-out-file 时，Massif 默认生成 massif.out.<pid></pid>；但如果你连续跑两次程序，进程 ID 不同，文件自然不同——看似“自动区分”，实则埋雷：一旦程序 fork 子进程，多个 massif.out.* 文件混在一起，ms_print 无法识别归属，直接报错或解析错乱。
真正可靠的做法是显式指定输出路径，并强制嵌入 %p：
valgrind --tool=massif --massif-out-file=massif-run1-%p.out ./myappvalgrind --tool=massif --massif-out-file=massif-run2-%p.out ./myapp --config=heavy
这样每次运行都生成唯一文件（如 massif-run1-12345.out），避免覆盖，也方便后续按命名归档。
对比不能靠肉眼扫 ms_print 文本，得用工具提取关键字段
ms_print 输出是纯文本+ ASCII 图，不适合 diff。真正可比的是峰值堆大小（heap allocation）、快照数、最大单次分配量，以及顶部调用栈的累计占比。手动翻找效率极低，容易漏掉细微增长趋势。
推荐用 shell 快速提取核心指标：
- 查峰值（单位字节）：
grep "max heap" massif-run1-*.out | awk '{print $4}' - 查总快照数：
grep -c "snapshot=" massif-run1-*.out - 抽前 3 个高开销调用栈：
ms_print massif-run1-*.out | sed -n '/->1/,/->2/{/->2/q;p;}'
把两组结果导出为 CSV 或简单表格，一眼看出哪次分配更多、哪次释放更彻底。
多线程场景下不加 --pages-as-heap=yes 就别想比准
Massif 默认只跟踪主线程的堆分配。如果实际业务中大量 malloc 发生在 worker 线程（比如线程池处理网络请求），那么你看到的 massif.out 峰值可能只有真实值的 1/5 —— 这种情况下拿两次结果对比，等于拿苹果和橙子比甜度。
要让 Massif 覆盖所有线程堆行为，必须加参数：
-
--pages-as-heap=yes：把整个内存页映射视为堆空间，代价是性能下降 10 倍以上，但数据全 -
--stacks=yes：如需同时看栈增长（比如递归深度变化），再加这个，但会进一步拖慢
注意：这两个选项必须在**所有对比实验中保持一致开启或关闭**，否则数值不可比。
编译参数不统一，对比结果就失去意义
Massif 报告中的行号、函数名、调用栈深度，高度依赖编译时是否带 -g 和是否关优化。比如：
- 用
-O2编译 → 内联函数消失，调用栈变浅，ms_print显示分配点在main，实际来自parse_json - 没加
-g→ 所有文件名变成??，根本无法定位到具体源码行
所以对比前务必确认：两次运行的二进制是同一份 gcc -g -O0 -fno-omit-frame-pointer 编译出来的。哪怕只是改了一个配置开关，也要重新编译，否则栈帧偏移、行号错位会让对比完全失效。
真正难的不是跑两次 Massif，而是确保两次的采集环境、线程行为、编译符号、甚至 libc 版本都一致。稍有偏差，数字看着像在下降，其实只是报告变“薄”了。
