个人博客地址：https://blog.flycat.tech/archives/1710866783664

背景

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

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

思路

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

复现

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

排查

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

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

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

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

因此可以确定是代理类 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的情况（可以使用打断点方式），定位到有一处不正规使用方式：

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

修复方案

改成只初始化一次SerializeConfig即可

结论

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