java内存持续增长需先判别是否泄漏：用jstat查ogc/occ比值、元空间及对象分布，jmap导堆转储后用mat分析gc roots，结合gc日志与代码变更定位静态缓存、未注销监听器等根因。
Java 应用内存持续增长且 GC 回收效果差，不是单纯“加内存”就能解决的问题。关键在于判断增长是正常波动，还是泄漏或配置失配导致的异常累积。核心思路是：先看现象、再查根源、最后验证优化效果。
观察实时内存与 GC 指标
不用等崩溃，第一时间用 JVM 自带工具抓取运行时状态：
-
jstat -gc
1000 ：每秒输出一次 GC 统计，重点关注 OGC（老年代已使用） 和 OCC（老年代容量） 的比值——若该比值持续上升、Full GC 后不回落，基本可锁定老年代泄漏； -
jstat -metaspace
或 jstat -gc | awk '{print $11}' ：查看元空间使用量，持续上涨往往指向动态类生成（如 Spring AOP、MyBatis Mapper 动态代理）或类加载器未释放； -
jmap -histo
：快速列出堆中对象数量和占用，重点关注 byte[]、HashMap$Node、String等高频类型是否异常偏多。
定位泄漏源头：堆转储分析
当确认老年代或元空间持续增长，需导出堆快照做深度分析：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 执行 jmap -dump:format=b,file=heap.hprof
获取堆镜像（注意：会触发 STW，建议在低峰期操作）； - 用 Eclipse MAT 打开 hprof 文件，打开 Dominator Tree，按“Retained Heap”排序，找出真正“撑大内存”的对象；
- 对可疑对象右键 → Path to GC Roots → with all references，查看谁在长期持有它——常见根因包括：静态缓存未清理、监听器注册后未注销、ThreadLocal 变量未 remove、线程池中堆积的未完成任务。
解读 GC 日志，识别回收瓶颈
GC 日志是判断回收策略是否匹配业务的关键证据：
- 启动时加上 -Xlog:gc*:file=gc.log:time,tags,level（JDK9+）或 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log（旧版）；
- 关注日志中 Full GC 频率 和 每次停顿时间；若 Full GC 后老年代内存几乎没下降，说明对象“该死不死”，大概率是强引用未断；
- 留意 Allocation Failure 或 Ergonomics 触发的 GC，这反映堆分配压力；若 Minor GC 频繁但晋升到老年代的对象多，说明年轻代太小或对象存活时间长，需调大 Young Gen 或检查对象生命周期。
结合变更与代码逻辑交叉验证
技术指标只是线索，最终要落到具体改动和实现上：
- 核对最近发布记录：是否新增了全局缓存、引入了反射/字节码增强框架（如 CGLIB、Byte Buddy）、启用了新的监控埋点或日志采样？
- 检查典型高危代码模式：static Map/Cache 是否有清理机制；addShutdownHook 或 Runtime.addShutdownHook 是否遗漏；Stream.iterate 或 递归调用 是否导致对象链过长；
- 确认线程池配置：corePoolSize 和 maxPoolSize 是否合理，拒绝策略是否导致任务堆积在队列中长期不执行。
不复杂但容易忽略。真正有效的分析，从来不是靠单点工具，而是把指标、日志、堆快照、代码变更串成一条证据链。找到那个“不该活这么久”的对象，问题就解决了一大半。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
