massif不能直接诊断“内存一路上涨”原因，但能精准定位增长位置、时间及调用方；它只记录堆内存快照，不检测泄漏，需配合-g、-o0、--pages-as-heap=yes等参数使用。
massif 能不能直接查“内存一路上涨”
不能直接告诉你“为什么涨”，但能精准标出“涨到哪、什么时候涨、谁干的”。massif 不是泄漏检测器，它不报 definitely lost；它只记录堆内存（malloc/new 分配的）随时间变化的快照。如果你看到 RSS 持续爬升、memcheck 又没报泄漏，massif 就是你该打开的第一个工具。
编译和运行时必须加的三个关键参数
缺一不可，否则调用栈全丢、峰值失真、多进程漏分析：
-
-g：必须带调试符号，否则ms_print里全是??? -
-O0：关优化，-O2会内联std::vector::push_back或提前释放，导致分配点“消失” -
--pages-as-heap=yes：仅当怀疑 worker 线程在分配——比如你用std::thread或pthread启了多个任务，且主线程几乎不分配。不加这个，massif默认只跟踪主线程，worker 的堆增长完全看不见；加了它性能降 10 倍，慎用
怎么看报告里“一路上涨”的证据
打开 ms_print massif.out.xxx > report.txt 后，盯这三处：
- 顶部曲线图里的
heap allocation (bytes)：如果末尾没回落、且随时间单调上升，就是“一路上涨”信号 - 中间 “->1” 节点列表：找
percent高（比如 >20%）、bytes随快照序号持续变大的调用栈，例如MyCache::insert出现在快照 1/3/5/7，每次分配量+1MB，这就是根因线索 - 底部
Detail展开某次快照：确认是不是你代码里的容器没clear()、缓存没purge()、或std::shared_ptr循环引用卡住释放
注意：std::vector 扩容时的瞬时双倍分配、第三方库（如 cv::fastMalloc）的内部缓存，也会拉高峰值，但它们通常会在后续快照回落——真正的问题是“不回落”。
容易被忽略的坑：fork、ASLR 和文件名
这几个细节不处理，两次跑出来的报告根本没法比：
- 程序有
fork()？必须加--trace-children=yes，否则子进程的分配全被忽略 - 不用
setarch $(uname -m) -R ./myapp关 ASLR，同一份代码多次运行，调用栈地址偏移不同，ms_print聚类失效，你看到的“同一函数”其实是不同实例 - 输出文件名别硬写
massif.out，要用--massif-out-file=massif.out.%p，否则父子进程写同一个文件，数据混杂
最麻烦的是多线程 + fork + ASLR 全开着跑，报告里调用栈乱跳、峰值飘忽、父子进程数据交叠——这时先关掉两个再试，别一上来就硬刚。
