JVM Metaspace 内存溢出排查与总结

一. 现象

前段时间公司线上环境的一个 Java 应用因为 OOM 的异常报警，导致整个服务不可用被拉出集群，本地模拟重现的现象如下:

image.png

当时的解决方案是增加 metaspace 的容量：-XX:MaxMetaspaceSize=500m，从原来默认的 256m 改为 500m，虽然没有再出现 oom，但这个只是临时解决方案，通过公司的监控系统观察 metaspace 的使用情况还是在上升，而且后面随着业务访问量越来越大还是有可能达到阈值。

image.png

二. 分析

Metaspace 元空间主要是存储类的元数据信息，我们的应用里加载的各种类描述信息，比如类名、属性、方法、访问限制等，按照一定的结构存储在 Metaspace 里。

由此可知 metaspace 空间增长是由于反射类加载，动态代理生成的类加载等导致的，也就是说 Metaspace 的大小和加载类的数据有关系，加载的类越多 metaspace 占用的内存也就越大。

因为了解当时的业务场景是因为有个邮件服务访问订单详情接口的访问量突然上升，以及查看 log 的 eroor 日志发现大部分都是订单详情接口先报出的这个问题:java.lang.OutOfMemoryError: Metaspace

这里我在测试环境 Java 应用的 jvm 里增加-XX:+TraceClassLoading -XX:+TraceClassUnloading记录下类的加载和卸载情况，然后通过 jmeter 多个线程调用订单详情接口模拟 metaspace 溢出的现象，发现在 catalina.out 文件里输出的除了业务上用到的类外还有大量的反射类，如下：

image.png

这些反射类被频繁的加载和卸载是不正常的，通过 Arthas 诊断工具（Java在线诊断利器之Arthas）观察调用链发现每次调用接口都是通过反射的方式实现的。

image.png

目前我们的项目都是基于 SOA 框架对外提供访问的，从上图sun.reflect的调用者也能看出来

image.png

通过上图可以看出在调用底层接口时都是通过反射的方式获取类的实例，查看框架底层代码实现可以确认

image.png

同样对底层接口返回的 json 数据反序列化时也会用到反射

image.png

image.png

继续跟代码可以看到这些反射的实现都会用到java.lang.Class里的ReflectionData对象

image.png

ReflectionData是个内部静态类被缓存起来，里面的属性就是我们做反射操作时需要用的属性Field，方法Method和构造函数等。但是有个问题reflectionData是被 SoftReference 软引用修饰的，如下图

image.png

如果是软引用的话在内存空间不足时就可能会被回收掉，如果回收掉那下次再使用的话只能重新通过反射获取。

而 SoftReference 是否被回收又跟SoftRefLRUPolicyMSPerMB参数的值有关系，查看我们线上 JVM 的配置发现XX:SoftRefLRUPolicyMSPerMB这个参数设置的是 0

image.png

SoftRefLRUPolicyMSPerMB这个参数大概意思是每 1M 空闲空间可保持的 SoftReference 对象的生存时长(单位是 ms 毫秒)，LRU 是 Least Recently Used 的缩写，最近最少使用的。

这个值 jvm 默认是 1000ms，如果被设置为 0，就会导致软引用对象马上被回收掉，进而会导致重新频繁的生成新的类，而无法达到复用的效果。

上图里大量的sun.reflect.GeneratedSerializationConstructorAccessor，GeneratedMethodAccessor就是这样产生的。

我把这个参数改回默认值-XX:SoftRefLRUPolicyMSPerMB=1000 (1 秒)，发布到生产环境验证了下，发布后就降下来了，到今天为止基本上趋于稳定

image.png

调整后基本上没有再出现波动

三. 总结

1. 目前主要是通过修改 JVM 的-XX:SoftRefLRUPolicyMSPerMB值来解决 metaspace 上升问题，后续会持续观察变化，适当调整参数。至于这个参数之前为什么会被设置成 0, 还需要找 ops 确认下。

2. 我们的应用需要大量 RPC 交互，属于 I/O 密集型业务，使用 SOA，Dubbo 都会遇到类似的问题，通过上面的源码分析可以看出这个是无法避免的(除非是换一种序列化协议，比如hessian，不走方法反射的方式来赋值)包括本身使用的 Spring 框架很多地方也是通过反射实现的比如 AOP，还有我们埋点经常使用的JsonUtils工具，通过 dump 文件也能看出来存在大量的属性拷贝和反射操作。

所以我们在平时的业务代码开发中如果遇到两个对象赋值的操作尽量少用反射的方式实现，比如下面的代码：

image.png

这里做的对象拷贝操作使用的是 apache common-beanutils.jar 中的BeanUtils，这个类底层采用 javabeans+反射实现，性能比较差，内存开销比较大，当系统高并发的情况容易导致 Metaspace 空间增长过快，不建议这样使用。

如果字段少的话直接赋值就行了，多的话可以使用Cglib的BeanCopier类，BeanCopier类底层是采用 asm 字节码操作方式来进行对象拷贝操作，性能损耗和内存开销都比较小。

或者使用 MapStruct 这种帮你生成set、get方法的工具，效果会更好。

文章来源：http://javakk.com/160.html