生产环境又OOM了，这次是Mybatis的锅？

我会带着你远行 2023-10-13 16:36 4阅读 0赞

## **前言** ##

继上次线上 CPU 出现了报警，这次服务又开始整活了，风平浪静了没几天，看生产日志服务的运行的时候，频繁的出现 OutOfMemoryError，就是我们俗称的 OOM，这可还行！

频繁的 OOM 直接会造成服务处于一个不可用的情况，最严重的一天，它重启了 5 次。我通过 Skywalking 查看链路调用，基本全报红了，基本处于一个瘫痪状态，因为生产该服务是分布式部署，k8s 故障恢复当即对该服务进行重启，因为是 B 端的产品，先让公司业务能用起来了，保证服务的正常使用，然后紧急查看问题。

当然这个问题很多同事不会排查，老板就让我亲自动手了。既然分配给我了，咱高低给它查出来，并且修复了。

## **OutOfMemoryError出现的原因** ##

先来了解下`OutOfMemoryError`出现的原因，无非就是两类堆内存空间不足、元空间不足。

1.  堆内存空间不足：意味着程序存在一直有引用的对象（强引用），主要对象在引用的状态就无法被GC回收，撑爆了-Xmx堆拓展的最大值，内存不足自然就会触发堆内存溢出。
2.  元空间：Java 8 引入了元空间概念，代替了之前堆的永久代，由于元空间属于堆外内存，不需要有对象引用，通过指针的方式表示类和元数据，之所以引用元空间就是一种 JDK 的升级优化，避免了永久代的内存溢出。详细内容参见`https://t.zsxq.com/0fdOtNgEQ`。

## **常见堆内存溢出的几种情况** ##

1.  查询数据库返回的数据量过大，加载到内存中导致内存溢出；
2.  代码中出现死循环情况，导致大对象一直被引用不能被 GC 回收；
3.  资源链接池、io 流在使用完没有进行手动释放；
4.  静态集合类里面存在引用对象，始终存在引用关系，没有进行清除；

以上属于常见的几种堆内存溢出的场景，当然有时候我们的遇到的问题都是稀奇古怪的问题，常见的问题总是很少能遇到…

## **现象分析** ##

根据生产环境的报错日志来看，这边属于 Mybatis 报出的一个内存溢出情况，通过去看 Mybatis 源码发现，底层也是通过一些集合类来存放拼接的 sql，那么当然也有可能出现堆内存溢出，而且在 sql 体积比较大的情况下，接收 sql 的集合就会变的非常大，如果回收不了那么就会导致内存溢出。

![424c3176a411f69be693c8f07a86fcac.jpeg][]

内存

由于我们 docker 容器里面没有一些 jstack、jmap 的工具，并且 dump 文件也没有进行保存…导致我无法通过看线程高占用内存的对象，来分析具体是什么操作发生的内存溢出，这就难了… 于是只能去网上搜搜看了，没想到真的给到我一些启发，并且有点思路大概知道是哪里的问题。

老天真的赏饭吃，我搜到了一篇关于惨遭 DruidDataSource 和 Mybatis 暗算的 OOM 文章。看起来，和我的情况很像。

给我带来了新的启发，这是 Mybatis 带来的 OOM。主要是因为 Mybatis 拼接 SQL 的时候生成的占位符和参数对象，存放在 Map 里，当 SQL 的参数多导致 SQL 太长的时候，Map 持有这些 SQL 时间较长，并且多线程同时操作，这时候内存占用就很高，从而发生 OOM。

## **Mybatis源码分析** ##

通过对`DynamicContext`类源码查看，DynamicContext 又一个 ContextMap 类型的参数bindings，继承了 HashMap 相当于一个Map集合，接着看这个类中的 getBindings 方法，看到了 ForEachSqlNode 这类调用了 getBindings 方法，简单的说就是 ForEachSqlNode 通过 getBindings 方法，将 SQL 参数和参数的占位符统一 put 到 ContextMap 这个集合里面，主要是这里面的参数和占位符无法被 GC 回收，并发查询量多的情况下就会导致 OOM。

![8e1f712451d7482dd8632e50a3f1c008.jpeg][]

Mybatis源码分析

![68045758db536ddb567ab5a58dc8ece7.jpeg][]

Mybatis源码分析

![f71b2c3cff5fea47e87a0b3b341f0047.jpeg][]

Mybatis源码分析

## **情景复现** ##

随后我做了线上场景的复现，通过将 SQL 语句的拼接，将 IN 里面的参数变大，然后创建 50 个线程进行执行，将 JVM 堆内存设为`-Xmx256m -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError`

![7739c691d9d282fdf4a43fd719c385af.jpeg][]

OOM 复现

![8708b1b0db0ef7a7765200a27c61e9c6.jpeg][]

OOM 复现

这里看控制台打印的日志，服务在频繁的进行 Full GC，导致 OOM。

![26b313e31676f0bc7984445c61f54cb4.jpeg][]

频繁的Full GC

## **总结** ##

既然发现了问题出现的原因，接下来就是对代码 SQL 进行优化，尽量避免在 sql 拼接的时候体积过大。这里告诫我们代码不能乱写，SQL 语句也不能随意写啊，有时候把问题想的过于简单确实会带来不可预知的风险。

另外，docker 中也配置了 oom 留存 dump 文件。后面如果万一再出现故障，也不至于太被动

[424c3176a411f69be693c8f07a86fcac.jpeg]: https://img-blog.csdnimg.cn/img_convert/424c3176a411f69be693c8f07a86fcac.jpeg
[8e1f712451d7482dd8632e50a3f1c008.jpeg]: https://img-blog.csdnimg.cn/img_convert/8e1f712451d7482dd8632e50a3f1c008.jpeg
[68045758db536ddb567ab5a58dc8ece7.jpeg]: https://img-blog.csdnimg.cn/img_convert/68045758db536ddb567ab5a58dc8ece7.jpeg
[f71b2c3cff5fea47e87a0b3b341f0047.jpeg]: https://img-blog.csdnimg.cn/img_convert/f71b2c3cff5fea47e87a0b3b341f0047.jpeg
[7739c691d9d282fdf4a43fd719c385af.jpeg]: https://img-blog.csdnimg.cn/img_convert/7739c691d9d282fdf4a43fd719c385af.jpeg
[8708b1b0db0ef7a7765200a27c61e9c6.jpeg]: https://img-blog.csdnimg.cn/img_convert/8708b1b0db0ef7a7765200a27c61e9c6.jpeg
[26b313e31676f0bc7984445c61f54cb4.jpeg]: https://img-blog.csdnimg.cn/img_convert/26b313e31676f0bc7984445c61f54cb4.jpeg