OOM那些事

随着业务量的增长，很容易产生OOM。目前已经遇到过三次OOM，下面我将讲解每次OOM的解决方案。

问题的产生

最近一次OOM发生在今天，当时前端反馈微信公众号扫描出现故障。后面几乎群里就炸了。我默默的打开了后门，通过郁闷访问试了下，果然挂了。返回503。什么原因导致503呢？什么情况下突然系统就不行了呢？最先想到的是网络问题，然后打开xshell。通过ip端口访问后台。发现竟然可以访问通。所以，我更加断定是网络问题。

解决思路

我找到了运维，说是网络问题，就让运维去查找问题了。如果是网络问题，中间只有两种设备，分别是NG和spring-gateway的。如果说是NG，那通过NG的其他服务应该也会出问题，但是事实上并没有。那可能是spring-gateway的问题。于是，我们打开了gateway的日志，发现在不断的刷日志。既然不是spring-gateway，那只有我们的应用了。但是刚才的访问，应用也在正常刷日志呀。这时，我一边想，一边看着应用的日志。发现偶然会出现报错，定睛一看，晕，OOM。

于是，我先后重启了服务，通过域名可以正常访问了。算是临时解决了生产问题。

为啥会出现OOM

当我想进一步考虑为啥会出现OOM时，我想通过导出的堆栈日志去分析，发现竟然没有配置OOM打印堆栈的参数-XX:+HeapDumpOnOutOfMemoryError。欲哭无泪。通过分析发现，更多的OOM是发生在HTTP链接，如下所示。

1、配置方法
在JAVA_OPTIONS变量中bai增加
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${目录}。
2、参数说明du
（1）-XX:+HeapDumpOnOutOfMemoryError参数表示zhi当JVM发生OOM时，自动生成DUMP文件dao。
（2）-XX:HeapDumpPath=${目录}参数表示生成DUMP文件的路径，也可以指定文件名称，例如：-XX:HeapDumpPath=${目录}/java_heapdump.hprof。如果不指定文件名，默认为：java_<pid>_<date>_<time>_heapDump.hprof。

https://blog.csdn.net/vic_qxz/article/details/82219301

https://blog.csdn.net/liberalliushahe/article/details/80534116?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.channel_param&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.channel_param