前言

继上次线上CPU出现了报警，这次服务又开始整活了，风平浪静了没几天，看生产日志服务的运行的时候，频繁的出现OutOfMemoryError，就是我们俗称的OOM，这可还行！频繁的OOM直接会造成服务处于一个不可用的情况，通过Skywalking查看链路调用，基本全报红了，基本处于一个瘫痪状态，因为生产该服务是分布式部署，运维当即立断对该服务进行重启，因为是B端的产品，先让公司业务能用起来了，保证服务的正常使用，然后紧急查看问题，找到了根源，并且修复了。

OutOfMemoryError出现的原因

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

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

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

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

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

现象分析

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

主要是因为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语句也不能随意写啊，有时候把问题想的过于简单确实会带来不可预知的风险。