这个场景解决什么
怀疑内存泄漏不能凭感觉，要靠趋势：按固定间隔记录进程的常驻内存与系统可用内存，把数据摆成时间序列，再看它是不是单调增长、增长是否跨过了业务周期。同时要排除掉缓存、周期性批量任务、以及 JVM 这类有 GC 行为的运行时带来的假信号。结论来自多条曲线的相互印证，而不是单点的数字。
基本信息
| 场景 | 应用内存缓慢上涨，需要判断是不是泄漏 |
|---|---|
| 目标 | 区分真正的泄漏、缓存增长与周期性压力 |
| 工具组合 | 定时采样 /proc 数据、进程内存映射、运行时自身的堆信息 |
| 判断原则 | 看趋势不看单点，采样周期要覆盖完整业务周期（含高峰） |
典型使用场景
- 上线后观察：新版本运行数日后内存持续走高，需要给出有无泄漏的结论
- 容量规划：依据增长速率估算多久需要扩容或重启
- 故障复盘：OOM 事件后还原内存曲线，判断是突增还是长期累积
- 优化验证：改了缓存策略或对象生命周期后，对比前后趋势是否改善
- 容器治理：结合控制组指标确认是进程增长还是整机压力
采样脚本
采样脚本
for i in $(seq 1 24); do
pid=$(pgrep -f app.jar | head -1)
rss=$(awk '/VmRSS/{print $2}' /proc/$pid/status 2>/dev/null)
avail=$(awk '/MemAvailable/{print $2}' /proc/meminfo)
printf '%s rss_kb=%s avail_kb=%s\n' "$(date -Is)" "${rss:-0}" "$avail"
sleep 3600
done | tee /tmp/mem-trend-$(date +%F).log分析与交叉验证
分析与交叉验证
awk '{print $2}' /tmp/mem-trend-*.log | sort -n | head # 看最小值与量级
awk '{split($2,a,"="); print a[2]}' /tmp/mem-trend-*.log | head -n 24 # 抽成序列观察单调性
pmap -x $(pgrep -f app.jar | head -1) | tail -n 3 # 内存映射概览
# Java 应用还要看堆这条线
jcmd $(pgrep -f app.jar | head -1) GC.heap_info
jstat -gcutil $(pgrep -f app.jar | head -1) 60s 5内存指标口径
| 指标 | 含义 | 误用风险 |
|---|---|---|
| VSZ / VSS | 虚拟地址空间大小 | 数值大是常态，不能作为占用判断 |
| RSS | 常驻物理内存，含共享页 | 多进程共享库会重复计数，直接相加会高估 |
| PSS | 按共享比例分摊后的常驻内存 | 更适合多进程场景的合计口径 |
| USS | 该进程独占的常驻内存 | 判断单个进程真实占用最准 |
| 堆内与堆外 | 运行时管理的堆与堆外内存 | 堆稳定而 RSS 上涨，说明问题在堆外 |
Java 应用要同时看两条线：堆用量（jstat 或 jcmd）与进程 RSS。堆稳定而 RSS 持续上涨，通常指向直接内存、线程栈或本地库；两条线同步上涨才更像堆内泄漏。
采样周期短看不出长尾泄漏：按周级别缓慢增长的问题需要跨业务周期采样，包含月末结算、批量任务这些高峰时段，否则容易得出「没有泄漏」的错误结论。