本文主要是介绍动态代理导致的Metaspace OOM（元空间内存溢出）问题，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
个人博客地址：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即可
结论
- fastjson的SerializeConfig自定义类的序列化方式有坑，请注意。
- 对于使用了ASM等字节码增强工具的类库，在使用他们时请多加小心（尤其是JDK1.8以后）
这篇关于动态代理导致的Metaspace OOM（元空间内存溢出）问题的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
