top不能直接确认内存泄漏，但能发现长期内存增长趋势，是排查第一步；需结合%MEM、RES等字段观察异常模式，并用pmap、/proc/PID/status等工具交叉验证。
top 本身不能直接确认内存泄漏，但它能帮你发现可疑的长期内存增长趋势，是排查的第一步。 真正的泄漏判定需要结合进程行为、代码逻辑和更专业的工具（如 valgrind、pmap、/proc/PID/smaps），但 top 提供了最快速、最直观的运行时观察窗口。
关注 top 中的关键内存字段
启动 top 后按 Shift+M 按内存使用量倒序排列，重点关注以下列：
- %MEM：进程占用物理内存的百分比——持续上升且不回落的进程需警惕；
- RES（Resident Memory）：实际驻留物理内存大小（单位 KB），比 VIRT 更反映真实内存压力；
- VIRT（Virtual Memory）：虚拟地址空间总量，包含已分配但未使用的内存、映射文件等，单独看意义有限；
- SWAP：若某进程 SWAP 值持续增大，说明其 RES 超出物理内存，系统开始换出，可能是泄漏或内存压力过大。
识别“长时间运行后”的异常模式
内存泄漏通常表现为：进程运行时间越长，RES 单调递增，且在空闲/无新请求状态下也不回落。操作建议：
- 记录初始 RES 值（例如：启动后 5 分钟稳定时记为 baseline）；
- 每隔 1–2 小时观察同一进程的 RES，计算单位时间增量（如每小时增长 >5MB 且无业务负载增加）；
- 对比多个同类型进程：若仅某个实例 RES 异常升高，大概率是个体泄漏而非设计行为；
- 注意排除缓存行为：Java 应用的堆外内存、glibc 的 malloc arena 扩张可能被误判，需结合 /proc/PID/status 中的 RssAnon 和 RssFile 进一步区分。
配合其他命令交叉验证
单靠 top 容易误判，必须辅以诊断命令：
- 查某进程详细内存分布：
pmap -x PID，观察 anon 匿名内存是否持续增长； - 看内核级统计：
cat /proc/PID/status | grep -E "^(VmRSS|VmSize|RssAnon)"； - 检查是否存在大量未释放的 mmap 区域：
cat /proc/PID/maps | wc -l，值随时间显著增加提示 mmap 泄漏； - 监控整体内存趋势：
free -h配合watch -n 30 free -h，观察 available 是否持续下降且无法回收。
避免常见误判
以下情况常被当作泄漏，实则正常：
- Java 应用的堆内存（由 JVM 管理）未及时 GC，但 Full GC 后 RES 未明显下降 才值得怀疑；
- 使用内存池或连接池的程序（如 nginx、redis）会预留内存，RES 稳定在高位属预期行为；
- 进程频繁 fork 子进程后未 wait，导致僵尸进程堆积——此时看 top 的 DEFUNCT 列，不是内存问题而是进程管理问题；
- 内核模块或驱动申请的内存（如 GPU 显存、DMA 缓冲区）不会出现在用户进程 RES 中，需用
dmesg | grep -i memory或专用工具排查。
