首先检查/proc/meminfo和slabtop确定内存泄漏范围，再用top定位高内存占用进程；用户态泄漏可用Valgrind、ASan或mtrace分析；内核态泄漏则通过kmemleak、Page Owner和Ftrace等工具追踪分配源头。
在Linux系统中，内存泄漏是导致服务性能下降甚至崩溃的常见元凶。发现某个进程或整个系统的内存使用量持续增长，基本就能怀疑存在泄漏。解决问题的关键在于快速定位泄漏源头，这需要结合系统监控和专业工具。下面分享一套实用的排查思路和方法。
观察系统整体内存状况
分析的第一步是站在全局视角，确认问题的范围和特征。
- 检查/proc/meminfo：这个文件是系统内存的总览。重点关注MemFree（空闲内存）是否持续下降，以及Slab（内核缓存）的大小。如果Slab占用极高且不断增长，特别是其中的SUnreclaim（不可回收部分）很高，说明很可能是内核态发生了泄漏。
- 使用slabtop实时监控：运行slabtop -o命令，它能动态显示内核slab缓存的使用情况。按缓存大小排序，观察哪个缓存项（如dentry、inode_cache、sock_inode_cache等）在持续增长。一个快速增长的特定缓存项就是重要的线索。
- 分析用户进程内存：对于用户态程序，用top命令查看，将光标定位到%MEM列并按Shift + M按键，可以让进程按内存占用率从高到低排序，迅速锁定可疑进程。
定位用户态程序的内存泄漏
一旦确定是某个用户态应用的问题，就需要深入其内部，检查代码层面的分配与释放。
-
Valgrind (Memcheck)：这是最经典的工具。它通过模拟CPU来监控所有内存操作，能精确报告未释放的内存块及其分配栈回溯。
使用命令：valgrind --leak-check=full --show-leak-kinds=all ./your_program
虽然非常强大，但会极大拖慢程序速度（可能降低几十倍），适合在测试环境或复现问题时使用。 -
AddressSanitizer (ASan)：这是一个编译时注入的检测器，性能开销比Valgrind小得多，更适合集成到开发流程中。
编译时加上参数：gcc -fsanitize=address -g your_code.c -o your_program
运行程序，一旦发生泄漏或越界访问，ASan会立即打印出详细的错误信息和调用栈，对调试帮助极大。 -
mtrace：这是glibc自带的一个轻量级工具，适合快速验证简单的C程序。
在代码中包含#include，并在main函数开头调用mtrace()，结尾调用muntrace()。
运行前设置环境变量export MALLOC_TRACE=memlog.txt，程序结束后会生成日志文件，可以用mtrace命令解析，查看哪些malloc没有匹配的free。
排查内核态的内存泄漏
当怀疑是驱动或内核模块泄漏时，排查难度更高，需要用到内核提供的特殊机制。
-
kmemleak：可以看作是内核的“内存扫描仪”。它通过周期性地扫描内存对象的引用关系来找出孤立的、无法被访问的内存块（疑似泄漏）。
启用方法：echo scan > /sys/kernel/debug/kmemleak
查看结果：cat /sys/kernel/debug/kmemleak
输出会包含泄漏内存的地址和分配时的调用栈，是定位内核泄漏的核心工具之一。 -
Page Owner：这个机制能追踪每一个物理内存页（page）是由谁分配的。它会在每个页面上记录分配时的调用栈。
需要在内核启动参数中加入page_owner=on来启用。
启用后，可以从/sys/kernel/debug/page_owner读取所有已分配页面的信息。通过比较内存泄漏前后的数据，用脚本分析调用栈的增量，就能精准定位是哪个内核函数或模块导致了大量页面分配而未释放。 -
Ftrace (Function Tracer)：当怀疑特定函数（如kmalloc）导致泄漏时，可以用ftrace跟踪这些函数的调用。
例如，用trace-cmd record -e kmem:kmalloc -e kmem:kfree记录kmalloc和kfree的事件，然后分析日志，看是否有分配记录找不到对应的释放记录，并结合堆栈信息进行判断。
