valgrind确认无内存泄漏需满足：程序clean exit，且final summary显示“all heap blocks were freed -- no leaks are possible”；若definitely lost非零、或未执行完退出流程（如崩溃、kill -9），则无法可靠判定。
看 --leak-check=full 的 final summary 是否为 “definitely lost: 0 bytes in 0 blocks”
Valgrind 不会自动“判断”内存是否干净，它只报告它能追踪到的未释放堆内存。关键看 Memcheck 在程序退出后输出的最终汇总（final leak summary），而不是中间某条警告。
这个 summary 通常出现在输出末尾，形如：
==12345== HEAP SUMMARY: ==12345== in use at exit: 0 bytes in 0 blocks ==12345== total heap usage: 12 allocs, 12 frees, 1,248 bytes allocated ==12345== ==12345== All heap blocks were freed -- no leaks are possible
只有出现 All heap blocks were freed -- no leaks are possible 这句，才表示 Valgrind 确认所有 malloc/new 分配的堆内存都被对应释放了。如果看到 definitely lost 或 indirectly lost 非零，就说明有泄漏。
注意：still reachable 不等于泄漏，它指那些指针还有效、理论上能访问到但没主动 free 的内存（比如全局缓存、单例对象内部持有的内存）。这类需人工判断是否合理，Valgrind 不把它计入“leak”范畴。
--show-leak-kinds=all 要和 --leak-check=full 一起用
默认情况下，Valgrind 只报告 definitely lost 和 possibly lost，而忽略 still reachable 和 suppressed。如果你漏掉 --show-leak-kinds=all，可能误以为“没报错=没泄漏”，其实只是被过滤掉了。
正确命令示例：
valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all ./myapp
-
--leak-check=full提供完整调用栈，定位到malloc行号 -
--show-leak-kinds=all强制显示全部四类状态，避免漏判 - 不加
--show-leak-kinds=all时，still reachable完全不出现，容易误信“已清空”
程序必须正常退出，不能被 kill -9 或崩溃中断
Valgrind 的泄漏检查只在目标进程 clean exit（即从 main 返回或调用 exit()）后触发。如果程序因段错误、abort()、被信号强制终止（如 kill -9），Memcheck 来不及做 final summary，输出里就没有 HEAP SUMMARY，也就无法确认是否释放干净。
常见陷阱：
- 调试时加断点后手动
kill -9，结果没看到 summary —— 这不是 Valgrind 失效，是它根本没机会运行收尾逻辑 - 程序中有未捕获的
SIGSEGV，直接 crash，summary 被截断 - 多线程程序中主线程退出但子线程还在跑，
main返回了，但部分内存被子线程持有未释放 —— 此时 Valgrind 仍会报告still reachable或definitely lost，取决于指针是否还可达
静态/全局对象析构顺序可能导致假阳性
C++ 中，全局或 static 对象的析构函数执行时机晚于 main 返回，但早于进程彻底销毁。如果这些对象内部持有堆内存，并在析构中释放，Valgrind 有时会把这部分内存记为 still reachable，甚至极少数情况下误标为 definitely lost（尤其在使用 atexit 或自定义清理函数时）。
这时要结合调用栈判断：
- 如果泄露报告指向
__static_initialization_and_destruction_0或类似符号，基本可判定是静态对象生命周期问题 - 确保所有全局对象析构函数中确实调用了
delete或free，且没有异常中途退出 - 避免在静态对象析构期间调用尚未初始化或已析构的其他静态对象
真正难排查的，往往不是 malloc 没 free，而是析构顺序打乱导致释放逻辑被跳过或重复调用 —— 这种问题 Valgrind 能暴露现象，但原因得靠代码逻辑反推。
