一次线上oom故障引发的思考

前言

首先声明qvq 这个问题其实是同事搞得，我在他的故障复盘会议上，学到了很多新东西。
我本人可没有搞出这种问题（自信 O(∩_∩)O）

问题

简言之就是容器oom了，出现了线上繁忙，部分服务响应时间过长。

排查

内存溢出了，根据这位同事的排查（查dump文件以及他最近的改动），是由于使用threadLocal变量未手动释放内存。

后来通过修复，也证明了他的猜测是正确的。
毕竟能oom的原因不多，java基本是虚拟机自动去释放内存，需要程序员手动释放内存的场景并不多。

那为什么这个问题并没有在灰度阶段暴露出来，而是在上线全量几天后才暴露呢？

这里还有个小点，就是灰度机器切换期间，docker容器销毁与重启，已经释放了堆积的内存。而在上线紧接着几天里，我们的应用陆续每天都有发布，相当于容器每天都会清空一次，所以问题就潜伏了起来。

而在问题暴露前，我们的应用刚好有个两三天没发布，其实就是docker容器内存堆积了。

收获

收获一 ：什么是dump文件，为什么同事根据它查出了问题？

Dump文件是进程的内存镜像。可以把程序的执行状态通过调试器保存到dump文件中。

Dump文件是用来给驱动程序编写人员调试驱动程序用的，这种文件必须用专用工具软件打开。

当我们的程序发布出去之后，在客户机上是无法跟踪代码的，所以Dump（扩展名是 .dmp）文件对于我们来说特别重要。我们可以通过.dmp文件把出现问题的情况再现，然后根据再现的状况（包括堆栈调用等情况），可以找到出现问题对应的行号。

生成Dump文件方法多样，最常用的即通过WinDBG软件。步骤如下：

1. 下载安装WinDBG
2. 打开WinDBG，打开File->A