一次线上OOM问题的个人复盘

上个月，我们一个java服务上线后，偶尔会发生内存OOM(Out Of Memory)问题，但由于OOM导致服务不响应请求，健康检查多次不通过，最后部署平台kill了java进程，这导致定位这次OOM问题也变得困难起来。

最终，在多次review代码后发现，是SQL意外地查出大量数据导致的，如下：

<sql id="conditions">
    <where>
        <if test="outerId != null">
            and `outer_id` = #{outerId}
        </if>
        <if test="orderType != null and orderType != ''">
            and `order_type` = #{orderType}
        </if>
        ...
    </where>
</sql>

<select id="queryListByConditions" resultMap="orderResultMap">
    select * from order <include refid="conditions"/> 
</select>

查询逻辑类似上面的示例，在Service层有个根据outer_id的查询方法，然后直接调用了Mapper层一个通用查询方法queryListByConditions。

但我们有个调用量极低的场景，可以不传outer_id这个参数，导致这个通用查询方法没有添加这个过滤条件，导致查了全表，进而导致OOM问题。

我们内部对这个问题进行了复盘，考虑到OOM问题还是蛮常见的，所以给大家也分享下。

事前

在OOM问题发生前，为什么测试阶段没有发现问题？

其实在编写技术方案时，是有考虑到这个场景的，但在提测时，忘记和测试同学沟通此场景，导致遗漏了此场景的测试验证。

关于测试用例不全面，其实不管是疏忽问题、经验问题、质量意识问题或人手紧张问题，从人的角度来说，都很难彻底避免，人没法像机器那样很听话的、不疏漏的执行任何指令。

既然人做不到，那就让机器来做，这就是单元测试、自动化测试的优势，通过逐步积累测试用例，可覆盖的场景就会越来越多。

当然，实施单元测试等方案，也会增加不少成本，需要权衡质量与研发效率谁更重要，毕竟在需求不能砍的情况下，质量与效率的关系是得此失彼，这是任何一本项目管理的书都提到过的。

事中

在感知到OOM问题发生时，由于进程被部署平台kill，导致现场丢失，难以快速定位到问题点。

一般java里面是推荐使用-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/dump/这种JVM参数来保存现场的，这两个参数的意思是，当JVM发生OOM异常时，自动dump堆内存到文件中，但在我们的场景中，这个方案难以生效，如下：

1. 在堆占满之前，会发生很多次FGC，jvm会尽最大努力腾挪空间，导致还没有OOM时，系统实际已经不响应了，然后被kill了，这种场景无dump文件生成。
2. 就算有时幸运，JVM发生了OOM异常开始dump，由于dump文件过大(我们约10G)，导致dump文件还没保存完，进程就被kill了，这种场景dump文件不完整，无法使用。

为了解决这个问题，有如下2种方案：

方案1：利用k8s容器生命周期内的Hook

我们部署平台是套壳k8s的，k8s提供了preStop生命周期钩子，在容器销毁前会先执行此钩子，只要将jmap -dump命令放入preStop中，就可以在k8s健康检查不通过并kill容器前将内存dump出来。

要注意的是，正常发布也会调用此钩子，需要想办法绕过，我们的办法是将健康检查也做成脚本，当不通过时创建一个临时文件，然后在preStop脚本中判断存在此文件才dump，preStop脚本如下：

if [ -f "/tmp/health_check_failed" ]; then
    echo "Health check failed, perform dumping and cleanups...";
    pid=`ps h -o pid --sort=-pmem -C java|head -n1|xargs`;
    if [[ $pid ]]; then
        jmap -dump:format=b,file=/home/work/logs/applogs/heap.hprof $pid
    fi
else
    echo "No heal