Linux内存泄漏排查需先用free和vmstat观察available持续下降与buff/cache单向上涨、sr/si/so异常等表层信号，再结合ps、/proc/meminfo、slabtop、perf等工具定位进程或内核泄漏源。
Linux内存泄漏排查核心在于识别“持续增长且不释放”的内存占用，free 和 vmstat 是两个轻量、实时、无需安装的诊断入口工具，但它们只反映表层状态，需结合逻辑判断和进一步追踪才能定位真实泄漏点。
free 命令：看内存总量与缓存/可用性变化趋势
free -h（或 free -m）输出中重点关注三列：
-
available：内核估算的当前可立即分配给新进程的内存（含可回收的 page cache、slab 等），比
free列更真实反映系统余量； -
buff/cache：包含页缓存（page cache）、目录项/索引节点缓存（dentries/inodes）、slab 分配器对象（如 kmalloc 缓存）等，正常会随 I/O 波动，但若长期单向上涨且
available持续下降，需警惕 slab 或内核模块泄漏； - used 不等于“真实应用占用”——它 = total − free − buff/cache，而 buff/cache 中大量内容可被快速回收，所以不能单看 used 增长就断定泄漏。
建议每 5–10 秒运行一次观察：watch -n 5 'free -h'。若 available 持续走低、buff/cache 却未同步回落，说明有内存被“钉住”无法回收，可能是内核驱动、BPF 程序、或未正确释放的内核内存（如 kmalloc/kmem_cache_alloc 后未 kfree）。
vmstat：抓取内存压力与换页行为信号
vmstat 1 每秒输出一行，重点看以下字段：
- si/so（swap in/out）：非零且持续出现，说明物理内存严重不足，已开始换页——这是内存紧张的强信号，但不直接等于泄漏（可能是配置过小或突发负载）；
- bi/bo（block in/out）高 + cache 高 → 可能是缓存堆积，未必泄漏；
- in（interrupts）和 cs（context switches）异常升高，配合内存下降，可能指向高频内核分配路径（如网络收包、定时器回调反复 malloc）；
-
sr（scan rate，旧版 vmstat 显示为 re）> 0 且持续存在 → 内核 kswapd 正在积极回收内存，说明 LRU 链表压力大，常伴随
available走低。
注意：vmstat 本身不显示谁占了内存，但它能告诉你“系统是否在挣扎”。如果 free 显示 available 快见底，而 vmstat 的 sr 居高不下、si/so 开始跳动，基本可确认存在未释放资源，下一步必须深入进程或内核层面。
定位泄漏源的实用组合动作
仅靠 free/vmstat 无法定位到具体进程或代码行，但可快速缩小范围：
- 用
ps aux --sort=-%mem | head -10查内存 RSS 最高的用户进程，检查其生命周期是否异常（如本该退出却常驻、连接数线性增长）； - 用
cat /proc/meminfo | grep -E "SReclaimable|Slab|KernelStack|PageTables"关注内核内存子系统：若Slab持续上涨且SReclaimable不增，大概率是 slab 分配器中某 kmem_cache 未释放对象（常见于驱动或内核模块）； - 对可疑进程，用
pmap -x看其地址空间分布，关注anon区域是否随时间不断扩张； - 内核态怀疑时，启用
slabtop实时观察各缓存使用量，或通过/sys/kernel/slab/下各 cache 目录的objects、slabs文件跟踪增长； - 终极验证：用
perf record -e kmem:kmalloc,kmem:kfree -a sleep 30录制内核内存事件，再用perf script分析分配/释放是否匹配（需开启 CONFIG_KPROBE_EVENTS 和 debugfs）。
常见误区提醒
别把“buff/cache 高”当泄漏——Linux 会尽可能利用空闲内存做缓存，这是设计优势；
别忽略内核模块或 eBPF 程序：它们分配的内存不会出现在用户进程 RSS 中，但会体现在 Slab 或直接占用直接映射区；
别依赖 top 的 %MEM 排序：它基于 VIRT 计算易失真，优先用 ps 的 RSS 或 PSS；
容器环境要进对应 cgroup 查 /sys/fs/cgroup/memory/xxx/memory.usage_in_bytes，宿主机 free 看不到容器内存上限外溢的真实压力。
