案例 | 业务员的非常规操作OOM故障处理

案例 | 业务员的非常规操作OOM故障处理

OOM本质是程序程序申请内存过大，虚拟机无法满足我们，然后自杀了。OOM经常伴随Full GC,高JDBC, Pending User Request等一系列的问题内存溢出的案例数不胜数， 所以日常运维中我们需要尽量避免OOM的发生。

为了避免内存溢出的发生，我们往往会对内存中一些大对象的操作分外注意，时刻警惕因为逻辑不严谨产生的内存溢出。

但有时候，应用的操作人员总是以一种想不到的方式，用非常规的操作手法，引发OOM的惨案。

而这次的故事主角就是业务人员的非常规操作。

2019年某天，工程师接到了一个应用的多个节点不可用告警，经确认，日志中有明显的OOM报错，由于我们已经优化了生产环境参数，所以，在OOM的同时，应用也生成了对应的内存快照文件。

工程师迅速打开内存快照文件进行问题定位，从分析工具自动生成的报告文件看

只存在一个大的内存泄漏点a

可见13个

org.apache.poi.hssf.usermodel.HSSFSheet[]

占用了66.34%的内存。

工程师之前在其他地方就有遇到过org.apache.poi.hssf.usermodel.HSSFSheet[]这个类，这个类是在做Excel的相关操作。

工程师在执行线程中，查看13个实例中的其中一个28号线程的调用情况如下，另外，从调用的方法名来看是在做导出Excel表格操作：

at XXXX/querycount/action/TakerIoQueryAction.exportExcel

结合内存快照，我们可以确认。此段时间28号线程调用exportExcel方法的请求URL以及IP地址如下：

URL地址：/XXXX/XX/querycount/takerIoQuery.do

IP地址：10.XXX.XXX.XX2

另外，查看多个/XXXX/XX/querycount/takerIoQuery.do发现，请求发起的IP地址是相同的。

写在后面：

按开发人员常规的设计，同一时间不会有那么多的报表导出操作，即使有，也会由负载均衡器分发到不同节点。

但是很多时候业务的操作人员不会关心系统是怎么运行的，系统会不会有压力，所以为了提升业务工作效率，他们会手动开启多个作业页面进行业务处理。由于会话保持策略等原因，这些操作会同时分配到一个节点。这时候这些作业信息会疯狂的压榨系统的空闲资源（如内存），当业务人员觉得系统卡顿时，会时不时刷新下，加剧资源的使用。

所以，开发人员对于一些资源消耗非常敏感的操作，一定要做好业务层级的控制，避免一个业务人员提交大资源消耗的操作，也要避免业务人员同时提交多个大资源消耗的操作，最终导致系统卡死。

|  北京    |    上海    |   广州    |   成都    |

4008-906-960