分享生产线上发生的一次OOM

2,202 阅读4分钟

本文正在参加「金石计划」

前言

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

OutOfMemoryError出现的原因

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

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

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

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

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

现象分析

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

F5DDC5E4-5B4F-4EAB-BD56-ACAD9F490540.png

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

文章来源于zzzzbw作者写一篇关于 惨遭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。

6FE21FA7-8A5A-45F3-994B-C7A1CE49CFF1.png

76423410-56AE-4DA7-87C1-69DB228A4C7A.png

E1A882E6-D902-4337-9597-AED53953F4AD.png

情景复现

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

7B67A386-8270-48DD-8F7A-1C62D03F31C8.png

829555B8-AC7D-47A5-BF1A-2C812A5E7AE2.png

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

47B5BE5C-2AD9-442B-9D49-0033D5B7D043.png

总结

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