加 -g 和 -O0 编译，运行时用 --track-origins=yes（对未初始化值）、--leak-check=full --show-leak-kinds=all（对泄漏）、--trace-children=yes（对子进程）、--tool=helgrind（对线程），并避免 strip 和递归锁。
valgrind 报 Invalid read 或 Use of uninitialised value 怎么定位到具体行？
这类错误不是“有没有泄漏”，而是访问了不该访问的内存，比如读已释放的指针、用未初始化的栈变量当数组下标。valgrind 默认不显示行号，因为没带调试信息。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 编译时必须加
-g（哪怕只是g++ -g -O0 main.cpp），否则 valgrind 只能报到汇编层级 - 禁用优化（
-O0），否则变量被优化掉、行号映射错乱，Invalid read会指向完全无关的代码行 - 运行时加
--track-origins=yes，它能追查未初始化值的源头，对Use of uninitialised value特别有用 - 如果用了 C++ 标准库容器（如
std::vector），记得链接时不要 strip 符号——某些发行版默认 strip，会导致std::vector::operator[]的检查失效
检测内存泄漏必须用 --leak-check=full 吗？
不是必须，但不用就等于白跑。默认 --leak-check=summary 只告诉你“漏了 3 个块”，不告诉你在哪申请的。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 固定搭配是
--leak-check=full --show-leak-kinds=all，后者确保连still reachable（比如全局 vector 持有的内存）也列出来 - 加
--undef-value-errors=no可以关掉未初始化值检查，避免干扰泄漏主线——尤其在你只关心definitely lost时 - 如果程序 fork 了子进程，valgrind 默认只跟踪主进程；要检查子进程，得加
--trace-children=yes，否则泄漏可能藏在子进程中不显示 - 注意
still reachable不一定是 bug，比如全局std::string在 main 返回后还没析构，但它是可接受的；重点盯definitely lost和possibly lost
检测线程竞争用 helgrind 还是 drd？
优先用 helgrind，它是 valgrind 官方维护、支持最广的线程检查器；drd 更轻量但对 C++11 std::thread / std::mutex 支持不稳定，容易漏报。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 必须用
valgrind --tool=helgrind启动，不能直接跑可执行文件——否则所有线程同步操作都绕过检查 - 避免在代码里用
pthread_mutexattr_settype设置递归锁（PTHREAD_MUTEX_RECURSIVE），helgrind 对它的建模有缺陷，会误报“lock order inversion” - 如果你用了
std::atomic做无锁编程，helgrind 默认不分析原子操作间的依赖，可能漏掉 ABA 类问题；此时需配合--freelist-vol=1000000加大内存追踪深度 - helgrind 本身会显著拖慢程序（10–20 倍常见），别在压测环境开，只在功能测试或单测里启用
为什么 valgrind 说没泄漏，但 RSS 内存持续上涨？
valgrind 只管堆（malloc/new），不管 mmap 分配的大块内存、mmap 的匿名页、或者第三方库内部缓存（比如 glibc 的 malloc arena 扩张）。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 先用
pstack+/proc/PID/maps看进程地址空间里哪些区域在涨，再对应到代码——比如日志库用mmap(MAP_ANONYMOUS)做环形缓冲区，valgrind 就看不见 - 检查是否频繁调用
std::string::reserve()或std::vector::reserve()，它们背后是mmap，不属于堆分配 - glibc 的 malloc 默认启用
MMAP_THRESHOLD（通常 128KB），超过这个大小的malloc会走 mmap，valgrind 能跟踪，但不会合并统计进“heap”类别，得看报告末尾的mmaped区域 - 如果用了 jemalloc/tcmalloc，valgrind 无法穿透其内部结构，得换用它们自带的
mallctl或malloc_stats_print查内存分布
真正难的不是跑出报告，而是分清哪一行是真问题、哪一行是工具假阳性、哪一行根本不在 valgrind 视野里——尤其当泄漏混着 mmap、线程混着原子操作、还有优化器悄悄重排指令的时候。
