内存泄漏指C++中new/malloc后未delete/free，致堆内存持续增长、长期运行引发OOM；Valgrind需-g编译后运行检测，重点关注“definitely lost”类泄漏。
内存泄漏在 C++ 中到底意味着什么
内存泄漏不是程序崩溃，而是程序反复 new 或 malloc 但没配对调用 delete 或 free，导致堆内存持续增长、无法回收。它不会立刻报错，但长期运行会耗尽系统内存，引发卡顿、OOM 或被系统 kill。
典型场景包括：类中手动管理指针成员、异常路径遗漏 delete、容器存储裸指针后未清理、回调注册后忘记注销等。
注意：std::unique_ptr 和 std::shared_ptr 能大幅降低风险，但不等于免疫——比如循环引用、shared_ptr 持有裸指针再 new 出新对象却未交由智能指针接管，照样泄漏。
Valgrind 怎么跑出有效内存泄漏报告
Valgrind 不是编译器插件，而是一个运行时检测工具，必须用它启动你的可执行文件，且程序需用 -g 编译（保留调试符号），否则报告里只有地址，看不到源码行号。
立即学习“C++免费学习笔记（深入）”；
基础命令：
valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes ./your_program
关键参数说明：
-
--leak-check=full：启用完整泄漏分析（默认是 summary） -
--show-leak-kinds=all：显示 definitely lost / indirectly lost / possibly lost / still reachable 四类 -
--track-origins=yes：定位未初始化内存的来源（对“use of uninitialised value”类问题极有用）
常见误操作：直接对二进制加 valgrind 却忘了重新编译带 -g；或在 CI 环境中未安装 valgrind 导致命令静默失败；还有人把 valgrind 当成静态分析工具，试图扫描源码——它只作用于运行过程。
看懂 Valgrind 报告里的 “definitely lost” 是关键
Valgrind 将泄漏分四类，真正要优先处理的是 definitely lost：指指针已丢失（栈/堆上都找不到指向该内存的有效地址），这块内存彻底不可达，100% 泄漏。
示例片段：
==12345== 40 bytes in 1 blocks are definitely lost in loss record 1 of 2 ==12345== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==12345== by 0x4005D9: main (test.cpp:8)
这表示 test.cpp 第 8 行调用了 malloc，但后续没 free，且无任何变量持有该地址。
其他三类含义：
-
indirectly lost：因父块泄漏导致的子指针泄漏（如结构体中指针成员指向的内存） -
possibly lost：指针可能还在栈上，但 Valgrind 不确定是否还能访问（比如存在指针运算或 cast） -
still reachable：程序退出前仍有指针指向它（如全局缓存、单例内部指针），不一定算 bug，但得人工确认是否合理
C++ 项目中 Valgrind 的实际使用限制
Valgrind 在 Linux 上工作良好，但 macOS 和 Windows 原生不支持；macOS 用户只能靠 AddressSanitizer（Clang/GCC 都支持）替代。
它不能检测所有内存问题：
- 不捕获栈溢出或越界读（要用
AddressSanitizer） - 对多线程竞争检测弱（
Helgrind模块可用但开销大、误报多） - 无法识别逻辑泄漏（比如缓存不断
insert却从不erase，内存一直涨但每个指针都“活着”） - 若程序用
mmap或自定义分配器绕过malloc，默认模式下 Valgrind 会漏检
真实项目建议：CI 中固定跑 Valgrind + ASan 组合；本地开发时，对核心模块写带 teardown 的单元测试，再用 Valgrind 包裹单测执行；别等上线后 OOM 才想起查泄漏——那时堆栈早已被冲掉。
