生产环境jvm内存泄漏排查

问题回顾
20220801
09:28 生产环境故障告警，consul将business-215服务剔除,但随后又注册上了
09:40 生产环境再次故障告警，consul将business-215服务再次剔除，手动curl actuator/health发现响应缓慢
09:48 服务端大量报错，用户反映系统卡顿有不可用的情况，business-215频繁注册剔除
09:50 手动将business-215服务剔除，business服务暂时只用216提供服务，检查215异常情况
09:52 进入215 docker查看服务gc日志，发现大量频繁full gc，且gc并未释放内存，eden\old区域基本占用100%，初步估计内存泄露。

故障分析
1、导出应用服务jvm内存快照

jmap -dump:live,format=b,file=m.hprof 1

2、将内存快照下载至本地用Jprofiler进行导入分析
2.1 发现三大内存占用对象
“byte[ ]” 实体数量 50609208,内存占用7985172816B约8G
“com.mysql.cj.protocol.a.NativePacketPayload”,实体数量 50588063,内存占用1214113512约1G
“com.mysql.cj.protocol.a.result.TextBufferRow” 实体数量 50588000, 内存占用 2428224000B约2G

2.2 byte和NativePacketPayload对象都是保存的变量，我们直接分析TextBufferRow项进行进入分析。
发现controller com.ysjr.base.controller.CustomerFollowController.followList
调用service com.ysjr.base.domain.elasticsearch.impl.FollowRepositoryImpl.followListByEsPage

2.3 查看调用图，可以发现mysql对象映射还没有赋值内存就已经满了，由此推断应该是查询完成后没有即时释放响应数据以及其他查询参数，导致系统jvm 内存一直强链接不能释放内存。

2.4 查询followListByEsPage 内部插叙ES 数据后会进行后续处理。java 代码：

数据库响应数据后还对数据进行了再次处理，这部分如果在高并发下会有性能瓶颈，会导致查询参数不能释放、数据响应数据不能释放，从而造成byte[]、NativePacketPayload、TextBufferRow对象内存不能释放。

结论：前端调用查询数据库逻辑，由于数据响应后会对数据进行再次处理，导致查询参数不能释放，响应数据不能释放。在高并发条件下会造成内存堆积，严重会将内存吃满。建议在处理并发量高的业务需要缩短数据处理时间，有条件的情况下可以手动置空便于垃圾处理器收集内存。