背景

我们团队的一个项目,测试环境最近隔三岔五报错,虽然不是生产环境,但既然有报错那还是得排查下,以免带到了生产环境导致事故。

登录上测试环境服务器,查了下日志,发现是Metaspace内存溢出。

image.png

思路

1、首先我们知道,JDK1.8的Metaspace是在堆外内存的,那么堆分析神器MAT在此案例中没有用武之地;
2、Metaspace中存放的内容包括类结构信息、常量池(编译时字面量等)、字节码等等
3、内存溢出是运行时发生的,考虑到大量的框架用到了动态代理生成字节码等技术,可以将关注点放在生成了大量的类上面
4、由于测试环境是偶尔发生,说明需要请求积累到一定的量才会发生,本地调试直接调对应报错的接口的话可能没法复现出来,此时可以使用postman或jmeter等进行简单压测

复现

因为是测试环境,直接拉test分支在本地跑就好了,使用jmeter调用报错接口,设置20个并发进行压测。
打开Visual VM工具,连接到对应进程,在压测过程中,虽然没有发生Metaspace内存溢出,但是发现Metaspace确实一直在上涨。

CleanShot 2024-03-20 at 00.37.05@2x.png

排查

JDK1.8的Metaspace区域是保存字面量和符号引用字面量就是类中的字符串常量,符号引用就是类元数据信息,父类、接口、属性、方法名等,那么首先排查是否有大量动态代理类加载。

应用启动变量增加几个参数:

-XX:MetaspaceSize=128m
-XX:MaxMetaspaceSize=256m
-XX:+TraceClassLoading
-XX:+TraceClassUnloading

继续对接口进行压测,一开始有一大堆乱七八糟的日志信息,不过继续压了一会以后,日志中频繁出现了一个代理类的加载信息:com.alibaba.fastjson.serializer.ASMSerializer_1_RespResult

CleanShot 2024-03-20 at 00.35.55@2x.png

因此可以确定是代理类 com.alibaba.fastjson.serializer.ASMSerializer_1_RespResult加载太多次问题,此时基本可以锁定是fastjson使用方式错误问题。

找到fastjson依赖包下找到 com.alibaba.fastjson.serializer路径,发现有一个ASMSerializerFactory的类,在这个类中搜索ASMSerializer_关键字,发现类名生成规则如下:

String className = "ASMSerializer_" + seed.incrementAndGet() + "_" + clazz.getSimpleName();

跟加载的类完全吻合。打上条件断点调接口,根据debug堆栈信息发现是引入的公司内部开发的链路追踪组件包,其实现了ResponseBodyAdvice在结果返回之前拦截,对数据进行脱敏后记录在链路追踪上下文中。

搜下整个链路使用fastjson的情况(可以使用打断点方式),定位到有一处不正规使用方式:

CleanShot 2024-03-20 at 00.40.00.png

CleanShot 2024-03-20 at 00.41.24.png

使用fastjson的SerializeConfig。SerializeConfig创建时默认会创建一个ASM代理类用来实现对目标对象的序列化。也就是上面被频繁创建的类 com.alibaba.fastjson.serializer.ASMSerializer_1_RespResult,如果我们复用SerializeConfig,fastjson会去寻找已经创建的代理类,
从而复用。但是如果new SerializeConfig(),则找不到原来生成的代理类,就会一直去生成新的RespResult代理类。

new SerializeConfig构造方法

修复方案

改成只初始化一次SerializeConfig即可

结论

  1. fastjson的SerializeConfig自定义类的序列化方式有坑,请注意。
  2. 对于使用了ASM等字节码增强工具的类库,在使用他们时请多加小心(尤其是JDK1.8以后)