内存泄漏的判定关键是看内存增长是否持续且不可逆：如进程rss持续上涨、重启归零，或sunreclaim单向爬升；slab中obj size固定且active持续增加（如dentry_cache）是典型信号。
怎么看是不是内存泄漏，而不是单纯吃内存
内存占用高不等于泄漏，关键看增长是否持续且不可逆。比如 top 里某个进程 RSS 持续上涨、重启后归零，或者系统空闲时 /proc/meminfo 中的 Slab 或 SUnreclaim 单向爬升，这才是泄漏信号。常见假阳性：缓存（SReclaimable 高通常没事）、Buffers、Cached —— 它们会在内存压力下自动回收；而 SUnreclaim 长期不降，基本就是内核态泄漏了。
实操建议：
- 先跑
watch -n 1 'cat /proc/meminfo | grep -E "^(MemFree|Slab|SReclaimable|SUnreclaim)'"，盯 5–10 分钟，看哪项在涨 - 对比
slabtop -o（按c排序），重点关注OBJ SIZE固定、ACTIVE持续增加的 cache，比如dentry_cache、size-4096 - 如果用户进程没几个但
Slab占几 G，基本可以排除应用层，直奔内核模块或驱动
valgrind 能用，但别在生产环境硬上
valgrind --tool=memcheck 是排查 C/C++ 用户态泄漏最直接的工具，但它会拖慢程序 20–30 倍，且无法检测内核内存分配（kmalloc、alloc_page）。更麻烦的是，它依赖符号表和调试信息，strip 过的二进制基本没法用。
实操建议：
- 编译时加
-g -O0（开发/测试环境），避免优化干扰堆栈追踪 - 运行前设
export MALLOC_CHECK_=2，能提前捕获部分free误用 - 重点看日志里
definitely lost和still reachable—— 前者是真泄漏，后者可能是全局指针未清，需结合代码判断 - 别用
valgrind查 systemd 服务或容器 init 进程：它会拦截fork，导致子进程失效
内核泄漏怎么定位到具体函数
用户态工具失灵时，/proc/slabinfo 和 tracepoint 是唯二靠谱路径。比如发现 size-4096 cache 不停涨，说明有内核路径反复调用 kmalloc(4096) 却漏掉 kfree。这时候靠 trace-cmd 抓调用栈比猜快得多。
实操建议：
- 先确认泄漏对象：
grep "size-4096" /proc/slabinfo，看num_objs是否随时间增加 - 开 trace：
trace-cmd record -e kmem:kmalloc -e kmem:kfree -F -C --Filter "bytes == 4096"（-F强制 flush，防丢事件） - 跑几分钟后
trace-cmd report，过滤出只有kmalloc没对应kfree的ptr地址 - 用
crash工具读vmcore或直接cat /proc/kcore | dd skip=$((0xffff880423744000)) count=4096 2>/dev/NULL | strings看那块内存里存的是什么（比如/proc/schedstat字符串就暴露了来源）
curl、NSS、dentry 这类“第三方组件泄漏”最容易被忽略
很多内存泄漏根本不在你的代码里，而在你调用的库中。典型案例如 curl 7.19.7 + NSS 组合，在 https 探测时会不断创建 dentry 对象却不释放，表现为 Slab 高但业务无异常。这类问题不会报错，日志也干净，纯靠内存曲线和 slabtop 对象分布才能揪出来。
实操建议：
- 查版本：用
curl -V、ldd ./your_binary | grep nss、rpm -q nss确认三方组件实际版本 - 搜已知缺陷：关键词组合如
"curl dentry leak"、"nss sdb cache leak"，linux 社区和 curl bugzilla 里常有现成 patch 或绕过方案（如NSS_SDB_USE_CACHE=1） - 临时验证：停掉可疑脚本或服务，观察
SUnreclaim是否停止增长；再用echo 2 > /proc/sys/vm/drop_caches清 slab（仅限测试，生产慎用）
真正难的不是工具怎么用，而是得意识到：泄漏可能藏在你从没看过源码的库里，而且它只在特定路径（比如 HTTPS + 某个 NSS 版本 + 某种证书格式）下触发。盯着自己代码找三天，不如花十分钟查下依赖组件的已知 issue。