一、故障背景（复盘标准写法）

现象：

• 系统内存持续增长（free 可用内存下降）
• 无明显业务增长
• 最终触发：
• OOM Killer
• 应用异常退出
• 系统卡顿

典型特征：

• 内存“只涨不跌”
• 重启恢复正常（关键判断点）

二、问题本质分类（非常关键）

内存问题 ≠ 一定是泄漏，要先分类：

👉 80%误判来自：把 cache 当泄漏

三、排查流程（标准SRE流程）

Step 1：快速判断是不是“假泄漏”

free -m

重点看：

• available
   是否健康
• buff/cache
   是否过高

👉 如果是 cache：

echo 3 > /proc/sys/vm/drop_caches

Step 2：定位“谁在吃内存”

top# or
ps aux --sort =-%mem | head

关注：

• RES（真实内存）
• %MEM

👉 锁定 Top N 进程

Step 3：进程级深度分析

pmap -x <pid>

看：

• total 是否持续增长

cat /proc/<pid>/status

重点：

• VmRSS
• VmData
• VmSwap

Step 4：趋势分析（核心）

watch -n5 "cat /proc/<pid>/status | grep VmRSS"

👉 如果持续增长 = 高度怀疑泄漏

Step 5：细分内存来源

cat /proc/<pid>/smaps

分析：

• heap（堆）
• stack（栈）
• anon（匿名内存）
• file（映射文件）

Step 6：系统级分析（避免误判）

1）Slab分析

slabtop

👉 如果 slab 持续增长：

• 可能是内核泄漏（如网络连接）

2）句柄泄漏

lsof -p <pid> | wc-l

👉 fd 持续增长 = 泄漏

3）socket 泄漏

ss -s

Step 7：高级工具（生产必备）

🔹 C/C++ 程序

• valgrind
• gperftools

valgrind --leak-check=full ./app

🔹 Java 程序

• jmap
• jstat
• jvisualvm

jmap -dump:live,format=b,file=heap.hprof <pid>

🔹 通用（SRE神器）

• perf
• eBPF（bcc / bpftrace）

👉 例如：

memleak-bpfcc

四、典型真实案例（面试可讲）

案例1：Java 服务 OOM

现象：

• RSS 持续增长
• GC 无法回收

原因：

• 对象未释放（缓存未过期）

解决：

• 引入 LRU
• 限制缓存大小

案例2：Nginx 内存异常

现象：

• worker 内存增长

原因：

• keepalive 连接未释放

解决：

keepalive_timeout 65;keepalive_requests 1000;

案例3：内核 Slab 泄漏

现象：

• free 正常，但 slab 持续增长

原因：

• conntrack 表未清理

解决：

sysctl -w net.netfilter .nf_conntrack_max=...

五、核心判断口诀（非常重要）

👉 一句话判断是否内存泄漏：

“内存是否随时间持续增长，并且无法回收”

六、复盘结论模板（可以直接用）

【根因】应用存在内存未释放问题（缓存/对象/连接）【影响】导致系统内存持续增长，最终触发OOM【过程】1. 通过top定位高内存进程2. 通过/proc分析RSS增长趋势3. 使用工具确认堆内存未释放【解决】- 优化代码释放机制- 增加资源上限控制【预防】- 引入内存监控（Prometheus）- 设置告警阈值（80%）- 定期heap分析

七、SRE级优化建议（升维）

1）监控体系

必须监控：

• 内存使用率
• RSS TopN
• Page Cache
• Slab
• FD数量

👉 推荐：

• Prometheus + Node Exporter

2）告警策略

3）自动化防护

• OOM 自动重启
• cgroup 限制内存
• K8s limit

4）架构优化（关键）

• 缓存必须设置 TTL
• 连接池必须有上限
• 避免无限队列

八、一句话总结（面试杀手锏）

👉

内存泄漏排查的核心不是工具，而是“趋势判断 + 分层定位 + 逐级排除”。