正文
- 事件回溯 1.1、现场反馈运营商门户网站使用卡顿，反映慢
1.2、我进行了问题定位，查看tomacat内存占用情况，发现多次超过85%，定位到存在oom问题，拉取内存快照dump；
- 事件分析 1、根据监控历史数据，发现7月10日后，内存逐步上升，且不能被full GC；怀疑和前一周版本有关，但检查前一周版本内容，不可能导致omm；
2、拿到线上dump文件分析，发现大量生存报表对象，占据了内存80%以上
3、走查代码，发现有个业务会返回大对象给前台，并且该业务触发的频率很高，
4 初步判断是该代码导致的omm,改造代码，后问题解决
- 问题修复 1、在本地环境压力测试模拟线上情况，重现oom；
回到顶部 4. 总结 1、引入第三方jar时，核心功能一定要做压力测试，模拟线上真实高并发场景，检查是否存在并发问题或者omm问题；
2、使用第三方jar时，一定参考官方的资料或者demo做开发，切不可轻信网上随意搜索得来的二手资料；
3、oom的现象：jvm内存使用不断上升，且不能被full GC掉；正常情况下jvm内存使用曲线是平缓的锯齿状，而oom的内存使用曲线上升趋势的锯齿状，如下：
线左边为正常状态，线右边为oom时。
4、oom确认手段：jvm内存dump分析：
查看内存占用最大的对象，并据此找到泄露点； 间隔两个full gc区间各拉一个dump，并比对这个时间段内增加的最多的对象，据此找到泄露点。（可能两次full gc时间拉得较长，也可以退步到一个时间区间的对比）。
