项目心得 | 深夜OOM

记一次深夜线上机器JVM OOM（堆内存溢出）的紧急排查及修复过程。

花2分钟阅读本文，你将收获：

1. 排查线上问题的一种思路及实践（可用于面试举例）
2. 感受笔者从懵逼到快乐的过程

部分内容改编自歌曲【许嵩-深夜书店】

🎵🎵🎵
已经是星期六的晚上零点
导师来电约我去线上查验
我困呆了 但我想拒绝也根本没法拒绝
关上了毕设就排查 等编译太费时间

登陆机器我看见一个超大日志
规整化一里散落着有缘的小报错
导师在企业微信向我抛了数据
我点头示意之后就发了个请求

请求 嘚瑟的心情忽然转懵
命令行上啥输出都没有好糊涂
我轻咬嘴唇 盯屏幕很投入
我瞄了一眼 它好像在说出现了宕机服务

大佬为你写出爆款程序
我能为你写出一堆八鸽
不断安慰自己佯装没事
通知导师 调整呼吸 打开谷歌 开始排查

=============================

言归正传，线上出现问题，就像是在拥挤马路上的凶杀现场，要先深呼吸保持冷静。然后第一件事不是立即拍照报案、恢复道路交通秩序，而是要注意保护现场（当然非常核心的业务 || 所有服务均宕机除外）。

首先观察问题现象，发送数据请求后，命令行没有打印任何输出，而是一直在阻塞等待。这表示服务进程应该还存在，猜测会不会是请求监听线程阻塞了。（如果进程闪退，命令行会直接返回host connection failed之类的信息）

整个排查及修复过程如下：

1. 验证其他机器是否出现相同问题。还好没有，那允许保护现场。

2. 先查看最新日志，“惊喜地”发现竟然发生了OOM内存溢出。
   

3. 快速dump内存（jmap -dump:format=b,file=文件名 <pid> 命令），并拉取日志到本地（命令行浏览不便，且防止日志丢失）。这一步其实是在保护现场，有时间的话还可以用jstack -l <pid>命令或其他工具做下thread dump。

4. 紧急重启服务。保护完现场，赶紧恢复道路秩序。

5. 本地打开dump及日志文件，通过查找快速定位到初次报OOM错误的位置，关联上下文进行分析。
   
   这里其实很容易定位到问题发生在BusConfigManager对象上

6. BusConfigManager对象是TubeMQ生产者的连接管理对象，属于第三方中间件，在自己毫无头绪的情况下，立刻联系TubeMQ相关维护人员联合排查。

7. 原来是TubeMQ相关依赖版本过低，可能存在SDK层的bug。修改代码中的依赖版本为最新稳定版的同时，修改了jvm的启动参数，增大堆内存。

8. 发布新版本，先灰度部署到有问题的机器进行验证。

9. 验证服务可用后，已是凌晨一点，先准备睡一觉，第二天再看看~

10. 第二天醒来，问题并没有复现，一切正常，美滋滋地部署新版本到其他机器（当然要一台一台验证）。

🎵🎵🎵
深夜…夜…夜…夜…夜
深夜…夜…夜…夜…夜