当面临 JVM OOM 时，你会告急吗 ？会不会手足无措 ？
这篇文章，分享前段时间帮一位同砚梳理面临 JVM OOM 事故时的解题思绪。
首先从对话中，我们可以看到内存溢出呈现两种环境：
- 运行一段时间之后，CPU 飙高 ；
- 服务假死，体现出来日记没有任何输出。
我的第一反应是：非常明显的 JVM 内存溢出体现 ，不过不知道是爆炸性的内存增长，照旧迟钝的内存增长。
于是，我回复：可以每隔一段时间 观察 top -p Pid （历程号） 看看应用的内存占用环境。
雷同的结果见下图：
接下来，我让他通过 jstat -gcutil pid 1000 看看 gc 的频率 。
从图中，新生代 E 区和老年代基本都满了 ，我基本可以确定是海量大对象产生导致 JVM OOM 了。
定时任务这四个字如电光火石般在我眼前闪过，基本八九不离十了。
接下来，他发了张那段时间的监控图：
哇，这张图太有画面感了，我都能感觉到 GC 线程在到处灭火，但依然无法开释内存的彷徨。
最后，我有点担心，是不是 JVM 内存分配小了才导致 OOM 了，同砚的回复是 ：12 G 。
我以为内存巨细还可以 ，一样平常环境下通过 jmap -heap pid 来检察，示例图如下：
分析到这里，基本上我得到了如下的结论：
1、要检察代码中是否有一次性查询海量对象的操作 ；
2、大概有什么公共的对象一直在使用，而忘记了开释；
3、12 G 对一样平常的小应用来讲是绰绰有余的，而且他们的应用非高并发场景，是内网系统。
最后，我建议观察在日记停的谁人时候到底做了哪些事变，那才是真正的案发现场。
那到底是什么缘故原由导致 JVM OOM 呢 ？和我预期的基本千篇一律：
SQL 语句雷同下图，查询条件没有拼接好，导致全表扫描。
我们总结下，解决 JVM 内存溢出题目的流程：
1、分析事故现场（CPU、内存、日记）；
2、通过 top -p Pid （历程号）分析历程资源占用，判断是爆炸性的内存增长，照旧迟钝的内存增长。
3、 jstat -gcutil pid 1000 看看 gc 的频率 ，可以分析是否有大对象产生以及 检察 GC 频率。
4、 jmap -heap pid 分析真实的 JVM 内存占用 ，确认是否真的内存分配得太小了。
5、 事故发生当时到底做了什么，有没有出现雷同于内存大概 CPU 占用呈现脉冲飙高样子。
6、 若有飙高的场景，分析彼时彼刻到底有哪些操作。
7、 若是迟钝增长，则考虑使用 MAT 结合清除法分析内存占用。
上面的流程是我解决过内存溢出的套路，虽然很糙，但很实用，好比曾经资助艺龙付出团队解决过订单查询内存溢出题目、西南某航空公司用户中心内存溢出题目等等。
最后，我想说：一定要注意 where 1 = 1 哦 ，真的出现太多次啦。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
