事件回溯

1、7月26日上午11:34，告警邮件提示：tomcat内存使用率连续多次超过90%；

2、开发人员介入排查问题，11:40定位到存在oom问题，申请运维拉取线上tomcat 内存快照dump；

3、开发人员担心服务抗不过下午的业务高峰期，让运维在中午低谷期间重启tomcat；

4、11:45，运维人员重启tomcat，内存使用回落。

事件分析

1、根据监控历史数据，发现7月10日后，内存逐步上升，且不能被full GC；怀疑和前一周版本有关，但检查前一周版本内容，不可能导致omm；

2、拿到线上dump文件分析，发现drools规则引擎相关对象占据了90%的内存，初步断定和drools的使用有关；

3、走读代码和drools的使用手册，发现使用不当：在使用完drool的fact对象后，未能及时释放，导致对象无法回收；

4、再回溯drools使用业务场景为当前app版本的新功能提供服务，新版本刚好在7月10日左右发布市场，所以，内存飙高最先出现在7月10日。

整个现象解释通畅。

问题修复

1、在本地环境压力测试模拟线上情况，重现oom；

2、更改drools相关使用代码，加上资源释放逻辑。

更改前：

{

.......

kSession.insert(fact);

kSession.fireAllRules();

.......

}

更改后：

{

.......

FactHandle handle = kSession.insert(fact);

kSession.fireAllRules();
kSession.delete(handle);

........

}

3、更改后，再次压测，问题修复。

总结

1、引入第三方jar时，核心功能一定要做压力测试，模拟线上真实高并发场景，检查是否存在并发问题或者omm问题；

2、使用第三方jar时，一定参考官方的资料或者demo做开发，切不可轻信网上随意搜索得来的二手资料；

3、oom的现象：jvm内存使用不断上升，且不能被full GC掉；正常情况下jvm内存使用曲线是平缓的锯齿状，而oom的内存使用曲线上升趋势的锯齿状，如下：

线左边为正常状态，线右边为oom时。

4、oom确认手段：jvm内存dump分析：

• 查看内存占用最大的对象，并据此找到泄露点；
• 间隔两个full gc区间各拉一个dump，并比对这个时间段内增加的最多的对象，据此找到泄露点。（可能两次full gc时间拉得较长，也可以退步到一个时间区间的对比）。