记一次生产OOM的排查过程

最近生产突然在每日早上都出现了服务宕机的情况，当日宕机后我们查询的生产的日志发现服务发生了OOM,日志如下:

 根据日志的信息查找到对应的代码发现是自定义的过滤器导致，我们查看代码发现是过滤器执行放过的流程，此时并不能定位具体的原因

并且我们通过观察grafana的监控发现内存的使用并没有太大的波动

此时我们只能在生产增加配置生产dump文件，然后重启服务，这时一切恢复正常（万能的重启大法）。这一天也一直没有什么问题，等待到了次日早上，灾难再次如期而至

此时我们只能拉取生产的heapdump.hprof文件。由于heapdump.hprof是乱码文件我们不能直接打开，我们可以自行百度搜索对应的工具，我是使用的一款在线工具Brilliant Graphs, metrics and heap dump analysisanti-patterns reportedIdentify memory wasted due to wrong memory size settings, inefficient collections, duplicate Objects, duplicate arrays, inefficient arrays, finalization, boxed numbers, object headershttps://heaphero.io/heap-index.jsp

添加对应的dump文件，然后确认Analyze会自动解析文件此时可能需要等待一段时间。

解析完成后会进入如下页面： 

这里已经告知了发生OOM出现的具体位置,在dominator Tree目录下会有相关内的内存使用情况

此时我们只需逐步去分析内存占用最高的几个类的详情逐步分析，可以查看到具体的执行服务(方法代码)

 此时我们只需要去查询对应的代码就可以，发现接口是用于批量任务使用的

发现此段代码是导致内存溢出的主要原因，此处查询返回大量的数据导致，只需根据业务要求优化此处代码即可。