生产环境下的一次 JVM 实践

近期发现生产环境下的某应用有重启情况，频率为 7 天内 2~3 次，因为给容器设置了存活检查，临到快崩时应用会重启，也没有保留事故现场。

在云监控看了下健康状况，发现内存使用量有些高，如图：

图中的谷点是因为发生了重启，但之后内存占用很快又升上去了。我首先是详细 review 了近段时间提交到 master 分支的功能代码，再看了下 rds 及 redis 的情况，都没发现问题，猜想极有可能是历史代码诱发了 OOM。

要弄清楚 OOM 发生的原因，就得收集内存溢出 Dump 文件进行分析，最终采取的方案是在 shell 脚本中设置 JVM 启动参数 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/jvmdump，同时容器挂载 NAS，链接 HeapDumpPath 属性指向的路径。这样发生了 OOM 后能保留堆溢出现场，会生成 java_pidxxx.hprof 文件，pid 后面是发生溢出的进程 id，之后可以用 JDK 自带的 VisualVM 或者 MAT 等工具打开分析。

工作快 5 年了，对 JVM 的认知一直停留在概念级别上，很开心能有这样一次实践经历，虽然仅仅是单个参数的设置，但依然享受解决问题带来的快乐。JVM 是高级 Java 程序员必过的坎，《深入理解Java虚拟机》这本书买着一直在吃灰，在接下来的 2021 年我一定要把它读完，加油！