java应用内存过高需先区分堆内持续增长或非堆异常膨胀，再通过jstat看old区回收率、jmap查存活对象、pmap识堆外泄漏、mat分析heap dump定位gc roots引用链，并结合gc日志验证修复效果。

Java 应用内存占用过高，核心在于区分是“堆内内存持续增长”还是“非堆内存异常膨胀”，再结合 GC 行为、对象生命周期和系统资源综合判断。不盲目调大 -Xmx，先定位真实瓶颈。

快速确认是否真有问题

别只看 top 里的 RES 值——它包含堆、元空间、直接内存、线程栈等总和。真正要盯的是 JVM 堆使用趋势：

• 用 jstat -gc 1000 5 观察 Eden、Old 区使用率变化：Old 区持续上升且 Full GC 后回收极少，大概率存在内存泄漏；
• 用 jmap -histo:live | head -n 20 查看存活对象TOP20，重点关注 byte[]、String、HashMap$Node、ArrayList 等高频类实例数是否异常偏高；
• 用 pmap -x 检查各内存段分布，若 `[anon]` 或 `libjvm.so` 映射区域远超堆设置，说明可能存在堆外内存泄漏（如 Netty DirectByteBuffer、JNI 调用未释放）。

抓取并分析堆转储（Heap Dump）

内存持续上涨时，主动触发 dump 比等 OOM 更可靠：

Java Maven Code Review

审查Java Maven项目（ZIP压缩包或GitLab仓库URL），检查代码规范、命名、模块边界、可维护性问题以及重复代码。

下载

• 执行 jmap -dump:format=b,file=/tmp/heap.hprof （确保磁盘有足够空间）；
• 用 Eclipse MAT 打开，优先查看 Leak Suspects 报告——它会自动标出最可疑的引用链；
• 切换到 Dominator Tree，按 retained heap 排序，点开最大对象，逐层展开“Path to GC Roots”，重点看是否有 static 引用、ThreadLocal、监听器未注销、缓存未过期 等典型泄漏模式。

检查 GC 日志与回收效率

GC 日志是判断内存问题性质的关键证据：

• 启动时加参数：-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 ——内存问题很少靠猜，靠的是数据链路闭环。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南