一个 redis 异常访问引发 oom 的案例分析

「推断的前提是以事实为依据。」

这两天碰到一个线上系统的偶尔出现突然堆内存暴涨，这倒不是个什么疑难杂症， 只是过程中有些思路觉得可以借鉴参考，故总结下并写下来。

现象

内存情况可以看看下面这张监控图。

一天偶尔出现几次，持续时间一般几分钟不等。 当这种情况出现时，我们检查错误日志，发现有下面两几种 OOM 错误。

• java.lang.OutOfMemoryError: GC overhead limit exceeded
• java.lang.OutOfMemoryError: Java heap space

与之相伴的还有个错误日志，是访问 redis 抛出的异常

• JedisConnectionException: java.net.SocketException: Broken pipe

我们一共观察到的现象大概就是这么多了，观察了两天感觉现象发生没什么规律性，持续时间也不长，一会儿应用 又会自动就恢复正常了。

诊断

通过上面的现象，负责系统开发和维护的童鞋认为可能是网络不稳定，java.net.SocketException: Broken pipe这个异常看起来确实是连接 redis 的长连接中断了， 而出现这个问题的应用，正好是我们新部署在一个新的 IDC，它需要访问在老 IDC 部署的 redis， 而在老 IDC 部署的应用则没出现过此类现象。

虽然两个 IDC 之间通过高宽带光纤连接作成了局域网，但依然比同一 IDC 内相比要慢上一些，再加上这个伴生 的应用抛出的网络异常，让人容易判断是网络环境的稳定性可能有区别导致应用行为的差别。 只是连接 redis 的长连接中断和应用抛出 OOM 有什么关联？我咋一想没觉得有必然联系。 而且负责网络监控的同事也确定两个 IDC 之间在发生应用异常时网络很稳定，完全没有丢包现象，带宽也足够。 因此将其原因推断于网络不稳定，就显得让人不太能理解，难以信服。

而且在 OOM 中能自己恢复的应用就不是内存泄露，应该属于内存溢出。 大概可能就是应用申请的内存短时间内超出了 JVM 堆的容量，导致抛出 OOM，从上面抛出的两种类型的 OOM 看确实像这种情况，特别是提示GC overhead limit exceeded这个说明就更指向了代码可能有问题。 只是如何找到哪段代码有问题，这个只好先通过在 OOM 时 dump 内存来分析了，在应用启动时加入下面启动参数 来捕捉 OOM 现场。

• -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=mem.dump

弄到了内存 dump 文件后，用 jhat 或 MAT 分析，顺利找到了某个线程在当时申请了 1.6G 内存，再顺着 线程栈找到了调用方法，一看源码立刻明白了，代码所在方法提供了对外的接口服务，方法参数来自外部输入，没有 对输入参数作安全性判断，而是直接根据输入参数确定边界创建了一个超级大的数组（2000多万个整数），导致立刻触发 了 OOM 并持续 FullGC 一段时间后被直接回收了，所以内存曲线才会像上图中那样。

再想想

现象中还有个连接 redis 的网络异常，这又是怎么回事？ 再回到代码去看，原来那个拼出来的 2000 多万个整数元素数组，是作为访问 redis 的命令参数（hmget）。 到这里，瞬间明白了是吧，这么长的参数做过服务端网络编程的都明白，协议解析时超过一个合理长度估计就会被拒绝 被认为是恶意的客户端，而导致服务端拒绝该客户端，拒绝的行为一般都是关闭连接。

再去扒了下 redis 的文档，确实找到了这样的说明：

Query buffer hard limit Every client is also subject to a query buffer limit. This is a non-configurable hard limit that will close the connection when the client query buffer (that is the buffer we use to accumulate commands from the client) reaches 1 GB, and is actually only an extreme limit to avoid a server crash in case of client or server software bugs.

上面就是说 redis 最大能接受的命令长度是写死在代码里地，就是 1 GB，超过这个自然被拒绝了。 更多关于细节参看 redis官方文档

总结

我觉得从这个案例中收获了两点感悟：

1. 现象并不那么可靠，不能头痛医头脚痛医脚。
2. 先从怀疑自己的代码开始。

第一点，应该是个常识了，医生诊断的例子充分说明了这点。 第二点，为什么要先从怀疑自己代码开始呢，简单来说就是应用的业务代码通常是测试和验证最不充分的代码。 业务应用依赖的环境不论是硬件（主机、网络、交换机）的还是软件的（操作系统、JVM、三方库）这些通常都比业务代码 经过更多地测试和广泛地应用验证，所以要先从怀疑自己开始，除非有非常明确地证据指向其他方面， 个人经验大部分时候这都是找到问题的最短路径。

----------------------------

下面是我自己开的一个微信公众号 [瞬息之间]，除了写技术的文章、还有产品的、行业和人生的思考，希望能和更多走在这条路上同行者交流，有兴趣可关注一下，谢谢。