要让tcmalloc输出堆内存profile文件，需在启动前设置HEAPPROFILE环境变量指定路径（如HEAPPROFILE=/tmp/myapp.hprof），确保目录存在且有写权限；tcmalloc会自动追加序号生成如.myapp.hprof.0001等文件。
怎么让 tcmalloc 输出堆内存 profile 文件
tcmalloc 默认不生成 profile，必须显式启用并指定输出路径。最直接的方式是在程序启动前设置环境变量 HEAPPROFILE，比如：HEAPPROFILE=/tmp/myapp.hprof ./myapp。注意路径需有写权限，且目录必须存在——/tmp 通常安全，但若写入 /var/log/myapp/ 却没创建目录，profile 就静默失败，连错误提示都没有。
常见错误现象：程序跑完没生成任何 .hprof 文件，或只生成了空文件。这时先检查 ls -l /tmp/ | grep hprof，再确认是否在子进程里执行（tcmalloc 不自动继承 profile 设置，fork 后得重新设）。
-
HEAPPROFILE值只是前缀，tcmalloc 会自动追加 .0001、.0002 等序号，避免覆盖 - 若用
LD_PRELOAD加载 tcmalloc（如LD_PRELOAD="/usr/lib/libtcmalloc.so" HEAPPROFILE=...），顺序不能颠倒，环境变量必须在LD_PRELOAD之前生效 - 多线程程序下，profile 是全进程聚合的，不是每个线程单独一份
gperftools 自带工具怎么解析 .hprof 文件
生成的 .hprof 是二进制格式，不能直接用 cat 或 less 看。必须用 gperftools 提供的 pprof 工具解析，命令形如：pprof --text ./myapp /tmp/myapp.hprof.0001。这里两个参数缺一不可：./myapp 是带调试符号的可执行文件（不是 stripped 版本），否则堆栈全是 ???；/tmp/myapp.hprof.0001 是实际生成的完整文件名。
容易踩的坑是误用 release 构建产物去解析 profile——调试信息缺失后，pprof 只能显示地址，无法映射到函数名。若没保留 debug 版本，可在编译时加 -g 并存档，别依赖线上二进制。
立即学习“C++免费学习笔记（深入）”；
-
--text输出扁平调用统计（按分配字节数排序），适合快速定位大头 -
--web启动本地网页（需 Graphviz），生成调用图，但对 C++ 模板函数可能展开过深，干扰判断 -
--inuse_objects改为按对象数量而非字节数排序，适合排查泄漏型小对象堆积
为什么程序跑着跑着 profile 不再更新
tcmalloc 默认每 1GB 分配才触发一次 profile dump，不是按时间或频率来的。如果程序分配总量长期卡在 900MB 下，就永远不出新文件。解决办法是主动控制采样频率，通过 HEAP_PROFILE_TIME_INTERVAL（单位秒）或 HEAP_PROFILE_ALLOCATION_INTERVAL（单位字节）强制刷新。
典型场景：后台服务长时间运行但单次请求分配不大，靠默认阈值根本捕不到 peak 内存点。此时设 HEAP_PROFILE_TIME_INTERVAL=60 更可靠——每分钟 dump 一次，后续用 pprof --base 做差分分析。
- 设太小（如 1 秒）会导致 I/O 压力和 profile 文件爆炸，慎用
-
HEAP_PROFILE_ALLOCATION_INTERVAL对小对象密集型程序更敏感，但需换算成字节数（例如 10MB = 10485760） - dump 时机受锁保护，极端高并发下可能略延迟，但不会丢数据
C++ 代码里能否手动触发 profile dump
可以，但必须链接 tcmalloc 的符号并调用 HeapProfilerDump 函数。它在 gperftools/heap-profiler.h 中声明，不是标准头，需要确保构建时包含 gperftools 的 include 路径。
使用场景有限：比如想在某个关键函数退出前抓一把快照，或 OOM 前做最后记录。但要注意，HeapProfilerDump 是阻塞调用，且 dump 过程本身也分配内存——在内存极度紧张时可能失败或拖慢程序。
- 调用前最好检查
IsHeapProfilerRunning()，避免在未启用 profile 时白忙活 - dump 文件名由 tcmalloc 自动拼接，你只控制时机，不控制路径
- 不要在信号处理函数（如 SIGSEGV）里调用，因堆状态可能已损坏
profile 文件体积和程序运行时长、分配模式强相关，一个跑 10 分钟的 service 可能产出上百 MB 的 .hprof；而 pprof 解析时若符号表太大，也会卡住几秒——这些都不是 bug，是设计使然。真正难的是把 .hprof 和业务逻辑里的对象生命周期对应起来，比如某段 std::vector 的反复 resize，在 profile 里可能表现为多个零散分配，得靠 --stacks 或结合源码上下文才能串起来。
