valgrind和addresssanitizer是linux下主流内存泄漏检测工具，前者开箱即用适合c/c++程序，后者编译期介入、运行时开销低；sysak memleak仅用于内核态泄漏诊断。
Valgrind 是目前 Linux 下最可靠、开箱即用的内存泄漏定位工具，尤其适合 C/C++ 程序；AddressSanitizer（ASan）编译期介入、运行时开销低，更适合开发阶段高频检测。
valgrind --leak-check=full 能查到哪些泄漏
Memcheck 工具默认只报告“definitely lost”和“possibly lost”，加 --leak-check=full 后会额外显示 still reachable 和 suppressed 四类状态。其中：
-
definitely lost：指针已丢失，且内存未被释放 —— 这是真正要修复的泄漏 -
possibly lost：可能因指针偏移导致无法追踪，需人工确认是否误报 -
still reachable：程序退出前仍存在有效指针指向该内存 —— 多数是全局/静态分配，不一定是 bug -
suppressed：匹配了 suppress 文件中定义的已知第三方库泄漏，可忽略
常见误判点：still reachable 容易被当成泄漏，但 Qt、glib 等库初始化时分配的缓存常属此类；若你没写全局 new，却看到大量 still reachable，建议先检查是否漏传 -g 编译选项导致堆栈不可读。
AddressSanitizer 编译时必须加 -fsanitize=address -g
ASan 不是运行时注入工具，它靠重写内存访问指令实现检测，所以必须在编译阶段介入：
- gcc/clang 需同时加
-fsanitize=address和-g，否则报错或无法定位文件行号 - 链接时不能带
-Wl,--no-as-needed类选项，否则 ASan 运行时库（libasan.so）可能被丢弃 - 程序崩溃时会直接打印泄漏点调用栈，格式类似：
Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7f... in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10cfa0) #1 0x55... in foo() (test.c:12) - ASan 默认不检测
mmap或brk分配的内存，只管malloc/new系列 —— 如果你的泄漏来自自定义内存池，它会完全沉默
sysak memleak 只适用于内核态泄漏诊断
这个工具来自阿里开源的 SysAK，专为排查内核内存泄漏设计，和用户态程序无关：
-
sysak memleak -t slab可抓取kmem_cache_alloc分配后未kmem_cache_free的 slab 对象 -
sysak mmaptrace -p $PID才能监控用户态进程的malloc/mmap调用栈，但它依赖perf_event_open接口，普通容器环境常因权限被禁用 - 它输出的是内核符号（如
ext4_writepages+0x2a），不是你的源码文件名和行号 —— 没有 vmlinux 符号表就只能看到十六进制地址 - 如果你在跑一个用户态服务并怀疑泄漏，先别急着用
sysak memleak，它大概率返回空结果或误导信息
不要跳过 -g 编译和 LD_PRELOAD 干扰检查
所有基于运行时插桩的工具（Valgrind、ASan、mtrace）都严重依赖调试符号和干净的动态链接环境：
- 没加
-g编译，Valgrind 报告里只有??:?，ASan 堆栈停在libc层，等于白跑 - 某些环境预设了
LD_PRELOAD（比如某些安全加固系统会 preload 自定义 malloc），会导致 Valgrind 报Invalid read of size 8在__libc_start_main，此时需临时清空：LD_PRELOAD= valgrind --leak-check=full ./a.out - ASan 和 Valgrind 互斥 —— 不能同时启用，否则直接 abort；也别在 Docker 中对 ASan 程序再套一层 Valgrind
- 静态链接的二进制（
-static）会让 ASan 失效，Valgrind 则仍可工作，但部分系统调用拦截可能不准
真正难定位的泄漏，往往卡在符号缺失、环境污染或分配路径绕过标准 malloc（比如 jemalloc + huge page 映射），这时候得回代码里翻 malloc_hook 或 mallopt 的使用痕迹。
