Java应用内存过高需先区分堆内持续增长或非堆异常膨胀，再通过jstat看Old区回收率、jmap查存活对象、pmap识堆外泄漏、MAT分析Heap Dump定位GC Roots引用链，并结合GC日志验证修复效果。
Java 应用内存占用过高，核心在于区分是“堆内内存持续增长”还是“非堆内存异常膨胀”，再结合 GC 行为、对象生命周期和系统资源综合判断。不盲目调大 -Xmx，先定位真实瓶颈。
快速确认是否真有问题
别只看 top 里的 RES 值——它包含堆、元空间、直接内存、线程栈等总和。真正要盯的是 JVM 堆使用趋势：
- 用 jstat -gc <pid> 1000 5 观察 Eden、Old 区使用率变化：Old 区持续上升且 Full GC 后回收极少，大概率存在内存泄漏；
- 用 jmap -histo:live <pid> | head -n 20 查看存活对象TOP20，重点关注 byte[]、String、HashMap$Node、ArrayList 等高频类实例数是否异常偏高；
- 用 pmap -x <pid> 检查各内存段分布，若 `[anon]` 或 `libjvm.so` 映射区域远超堆设置，说明可能存在堆外内存泄漏（如 Netty DirectByteBuffer、JNI 调用未释放）。
抓取并分析堆转储（Heap Dump）
内存持续上涨时，主动触发 dump 比等 OOM 更可靠：
- 执行 jmap -dump:format=b,file=/tmp/heap.hprof <pid>（确保磁盘有足够空间）；
- 用 Eclipse MAT 打开，优先查看 Leak Suspects 报告——它会自动标出最可疑的引用链；
- 切换到 Dominator Tree，按 retained heap 排序，点开最大对象，逐层展开“Path to GC Roots”，重点看是否有 static 引用、ThreadLocal、监听器未注销、缓存未过期 等典型泄漏模式。
检查 GC 日志与回收效率
GC 日志是判断内存问题性质的关键证据：
立即学习“Java免费学习笔记（深入）”；
- 启动时加参数：-Xlog:gc*:file=gc.log:time,uptime,pid,tags,level（JDK 9+）；
- 关注日志中 Full GC 频率、每次回收前后 Old 区大小变化——若回收后 Old 区仍接近 -Xmx，说明对象无法被回收；
- 留意 “promotion failed” 或 “concurrent mode failure” 等警告，提示新生代晋升失败或 G1/CMS 并发失败，往往与堆配置或分配速率不匹配有关。
代码与配置层面常见修复点
多数问题集中在三类可落地的改进上：
- 静态集合类清理：检查所有 static Map/List，添加容量限制、LRU 驱逐策略或定时清理逻辑；
- 资源未关闭：数据库连接、文件流、HttpClient 实例必须用 try-with-resources 或显式 close；
- JVM 参数合理化：-Xms 和 -Xmx 设为相同值避免扩容抖动；-XX:MaxMetaspaceSize 显式限制元空间（如 256m）；G1 场景下加 -XX:MaxGCPauseMillis=200 控制停顿。
排查过程重在闭环验证：改完代码或参数后，重启应用，用 jstat 持续观察 10 分钟以上 Old 区是否趋于稳定。一次没降，就再查一次 GC 日志和 dump ——内存问题很少靠猜，靠的是数据链路闭环。
