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

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

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

OutOfMemoryError出现的原因

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

1. 堆内存空间不足：意味着程序存在一直有引用的对象（强引用），主要对象在引用的状态就无法被GC回收，撑爆了-Xmx堆拓展的最大值，内存不足自然就会触发堆内存溢出。

2. 元空间：Java 8 引入了元空间概念，代替了之前堆的永久代，由于元空间属于堆外内存，不需要有对象引用，通过指针的方式表示类和元数据，之所以引用元空间就是一种 JDK 的升级优化，避免了永久代的内存溢出。

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

1. 查询数据库返回的数据量过大，加载到内存中导致内存溢出；

2. 代码中出现死循环情况，导致大对象一直被引用不能被 GC 回收；

3. 资源链接池、io 流在使用完没有进行手动释放；

4. 静态集合类里面存在引用对象，始终存在引用关系，没有进行清除；

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

现象分析

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

由于我们 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。

情景复现

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

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

总结

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

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

来源 | https://blog.csdn.net/lemon_TT/article/details/122905113

整理 | 一安未来