Java内存持续增长需先判别是否泄漏：用jstat查OGC/OCC比值、元空间及对象分布，jmap导堆转储后用MAT分析GC Roots，结合GC日志与代码变更定位静态缓存、未注销监听器等根因。
Java 应用内存持续增长且 GC 回收效果差，不是单纯“加内存”就能解决的问题。关键在于判断增长是正常波动，还是泄漏或配置失配导致的异常累积。核心思路是：先看现象、再查根源、最后验证优化效果。
观察实时内存与 GC 指标
不用等崩溃，第一时间用 JVM 自带工具抓取运行时状态：
- jstat -gc <pid> 1000：每秒输出一次 GC 统计，重点关注 OGC（老年代已使用） 和 OCC（老年代容量） 的比值——若该比值持续上升、Full GC 后不回落，基本可锁定老年代泄漏；
- jstat -metaspace <pid> 或 jstat -gc <pid> | awk '{print $11}'：查看元空间使用量，持续上涨往往指向动态类生成（如 Spring AOP、MyBatis Mapper 动态代理）或类加载器未释放；
-
jmap -histo <pid>：快速列出堆中对象数量和占用，重点关注
byte[]、HashMap$Node、String等高频类型是否异常偏多。
定位泄漏源头：堆转储分析
当确认老年代或元空间持续增长，需导出堆快照做深度分析：
- 执行 jmap -dump:format=b,file=heap.hprof <pid> 获取堆镜像（注意：会触发 STW，建议在低峰期操作）；
- 用 Eclipse MAT 打开 hprof 文件，打开 Dominator Tree，按“Retained Heap”排序，找出真正“撑大内存”的对象；
- 对可疑对象右键 → Path to GC Roots → with all references，查看谁在长期持有它——常见根因包括：静态缓存未清理、监听器注册后未注销、ThreadLocal 变量未 remove、线程池中堆积的未完成任务。
解读 GC 日志，识别回收瓶颈
GC 日志是判断回收策略是否匹配业务的关键证据：
立即学习“Java免费学习笔记（深入）”；
- 启动时加上 -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 是否合理，拒绝策略是否导致任务堆积在队列中长期不执行。
不复杂但容易忽略。真正有效的分析，从来不是靠单点工具，而是把指标、日志、堆快照、代码变更串成一条证据链。找到那个“不该活这么久”的对象，问题就解决了一大半。
