java应用内存飙升需分层排查：先用top、pmap确认系统级内存趋势；再用jstat -gcutil看ou是否持续上涨且full gc回收极少；接着用nmt对比native memory定位堆外膨胀；最后通过jmap dump分析存活对象及gc roots。
Java 应用内存飙升，不能只看“用了多少”，关键要判断是**正常增长、堆内泄漏，还是堆外膨胀**。排查必须分层推进，从系统到 JVM，再到对象级别，每一步都靠命令验证。
第一步：确认是不是真问题——看系统级内存趋势
先排除误报或资源争抢：
- 运行 top -M（按内存倒序），找到 Java 进程的 PID，重点关注 RES（常驻内存） 是否呈“楼梯式”持续上升（涨了不回落）；
- 配合 free -h 看整体内存和 swap 使用——如果 swap 被大量使用（
si/so非零），说明物理内存已严重不足； - 用 pmap -x
查看该进程各内存段分布，留意是否某一块（如 `[anon]` 或 `heap`）明显膨胀。
第二步：锁定 JVM 内存行为——查 GC 和堆使用率
启动参数没开 GC 日志也没关系，jstat 可实时观察：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
jstat -gcutil
2s （每 2 秒刷新）：重点盯 OU（老年代使用率） 和 FGC（Full GC 次数）； - 如果 OU 持续上涨，且每次 Full GC 后下降极少（比如只降 1%~2%），基本可判定堆内泄漏；
- 同时看 EU（Eden 区） 是否频繁打满又快速回收——这说明年轻代正常，问题大概率在老年代或永久代/元空间。
第三步：区分堆内 or 堆外——用 NMT 查原生内存
很多“内存飙升”其实是堆外导致的（如 Direct Buffer、Metaspace、线程栈），堆 dump 完全抓不到：
- 确保 JVM 启动时加了 -XX:NativeMemoryTracking=detail；
- 执行 jcmd
VM.native_memory summary ，先记下 baseline； - 等内存明显升高后，再执行一次，并用 jcmd
VM.native_memory summary.diff 对比； - 重点关注 Internal、Direct, Metaspace、Thread 几个区域的增量——比如 Direct 增长快，就查 Netty 或 NIO 代码；Metaspace 上涨猛，就查动态代理或脚本引擎。
第四步：定位泄漏对象——取堆快照并分析
确认是堆内问题后，才生成堆 dump（生产环境慎用，会 STW 约几秒）：
-
jmap -dump:live,format=b,file=heap.hprof
（推荐加 live，只导存活对象）； - 用 jmap -histo:live
| head -20 快速看前 20 名对象类型和数量，重点关注[B（byte[]）、HashMap$Node、业务类名、缓存类（如ExpiryMap）； - 把
heap.hprof拿到本地，用 JVisualVM 或 MAT 打开，看 “Leak Suspects” 报告，或按“Retained Heap”排序找大对象及其 GC Roots。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
