线上java内存泄露处理实录

线上现象(各种监控数据)

1.公司项目在监控平台上开始报警（jvm堆内存占用报警，FullGC次数超频率报警）

2.观察具体的监控图标（预发机器） 线程数平稳（260左右）

3. 方法监控可以看到在fullGC比较频繁时，业务方法几乎无响应

线上配置(jvm配置,运行时内存分布)

1. 项目版本：jdk8 ,spring 5, 默认垃圾处理器 Parallel GC with 43 thread(s) -Xms800m -Xmx800m -XX:MaxPermSize=256m

2. 运行时jstat
   

3. 运行时jmap histo

4. heap
   

5.dump文件1G左右，不发了，稍后看一下MAT分析的图表吧

逻辑分析(定位问题大致方向)

1. 通过监控和运行时数据分析，堆内存（年轻代和老年代）、非堆（方法区）、均打满配置内存
2. 即使FullGC，堆内存和非堆也只能回收少许内存，并且整体水位倾斜向上，直到内存溢出

通过逻辑分析，内存溢出问题来自于存在泄漏，接下来分析dump文件

内存分析(定位问题确切泄漏源)

采用MAT工具载入dump文件进行leak分析

通过分析可以看出红色的业务方法保留引用太多, 找到泄漏源了，接下来就分析业务代码具体的问题

通过分析，我们最终定位了这段代码，我们改造过程中引入了一个开源的属性运行时拷贝的包
但是我们每次转换的时候都会先register一遍转换代理类，而此类底层为每次register注册一个新生的代理类被加载到非堆
但是又被业务代码中的MAPPER_FACTORY引用，导致每次生成的实例充斥着年轻代又到老年代
最终的现象就是老年代、年轻代、非堆内存同时爆满，而又GC不掉，内存泄露直到溢出

代码处理

找到了具体的代码问题，我们将同一个类转换的register在系统启动时注入一次就行，不用每次调用注册，这样的话就不会频繁创建和加载，就可以解决上述问题

本地验证

本地验证错误使用代码，可以复现问题

加入 参数-verbose -verbose:gc 也 可以看到新增的代理类在循环中疯狂生成与加载， 修复后本地监控数据平稳运行，具体图标参考预发验证图表

预发验证

预发验证后续我们还将采用压测排除性能与其他内存问题，此次排除结束。

后记

此次问题还是属于比较常见的内存溢出分析，整体按着常用流程没有太多的难点，只有在分析register的时候一时定位不到是开源包的register方法调用的原因（虽然事后感觉很简单，当时也是耗费了30分钟左右才发现）。
troube shooting 三要素： 锻炼自己的逻辑思维、锻炼自己的技术能力、多看多查