记一次生产内存溢出分析解决

情景

一个怡然自得的下午，正开心的mo着鱼，突然测试发来一条消息，说现网功能出问题了。
我慌忙的开始排查问题，打开日志一看
java.lang.OutOfMemoryError: GC overhead limit exceeded
GC回收不到内存，内存溢出了

虽然说这种情况重启服务就能暂时解决，但是如果不找出根源问题，修改代码。那么即使重启了，也还会再次出现。

解决过程

简单的看了一下报错出错的类的逻辑，分析之后觉得应该不是这个类的问题。既没有循环，也没有大量的new实例，也没有用到list等集合、数组。
那么应该就是别的地方使用了大量的内存，导致这里运行时获取不到内存，GC也回收不到内存然后报的错。
然后上网查询了一下，很多方案都是说分析内存溢出快照。但是这玩意得在项目启动时添加启动参数才会在内存溢出时自动生成，-XX:+HeapDumpOnOutOfMemoryError

-Xms21m -Xmx21m -XX:+HeapDumpOnOutOfMemoryError

不过还好生产的项目启动时加了，因为我搜索到了内存溢出的快照文件

可以看到内存溢出文件名的pid就是我们进程的pid，说明这个内存溢出快照文件就是我们想要的

下载内存分析工具JPROFILER(工具是收费的，不过刚安装的前10天是免费的。10天应该够用了吧，不能项目天天内存溢出吧，那代码问题也太大了)

可以看到pdf的是实例对象有两个1000多万个，查看代码后发现是pdf中表格的行对象(一个定时生成pdf发送邮件的任务)，就是说生成的这个pdf表格有1000多万行。这明显是不合理的，分析过后发现按照需求统计确实会出现这么多数据，这么多数据的pdf报告客户根本是看不了的。因此需要重新规划需求，或是限制查询出的行数。
最后和产品确认之后限制了sql查询出来的数据条数，解决了此次问题。