警惕动态代理导致的Metaspace内存泄漏问题

前一段时间,公司将jdk升级到1.8之后,系统出现问题,问题集中在系统中包含的两个服务上。通过监控发现,每过十五分钟,这两个服务所在的服务器的内存就会减少,不到一天的时间,整个服务器的内存就被耗光,导致两个服务出现异常。两个服务的负责人经过多次分析无果,只能将问题提给我,让我协助分析。


首先从监控的数据来看,服务器内存下降是很有规律的,每过十五分钟,可用物理内存就掉下一个台阶,跟服务开发人员了解到这两个服务之间,会通过一个定时任务同步数据,同步数据的周期正是十五分钟,因此很容易可以判断,这个问题的根源,应该就是出在定时任务上。


接下来就是查看服务的jvm内存情况,为了更好的复现问题,我让应用开发人员帮我搭建起了这两个服务的测试环境,然后将定时任务触发的频率提高为一分钟执行一次。然后通过:


jstat -gccapacity  进程号


查看服务的jvm内存分配和回收情况,结果很容易就发现导致服务器可用内存下降的原因,正是因为每次定时任务触发之后,jvm的metaspace内存都在扩张,最终导致系统可用内存被耗尽。


接下来就是分析是什么原因导致metaspace一直不断扩张,因为metaspace主要存储类元数据,所以导致其不断扩张的原因,最有可能是加载类元数据导致内存泄漏,因此我给服务启动命令加上-verbose:class启动参数,让jvm输出类装载和卸载的情况,并将服务的标准输出重定向到指定文件中,方便运行一段时间之后去检查输出的情况。


运行一段时间之后,查看输出文件,可以看到每次定时任务执行的时候,都会大量的加载Fastjson创建的代理类。检查对应的服务代码,发现两个服务在定时任务触发时,其中一个服务会通过rpc调用另外一个服务,调用参数和响应参数是json格式的,通过Fastjson进行序列化和反序列化,而出现问题的地方,正是服务通过Fastjson进行反序列化时出现。从服务的代码看,在反序列时,创建了一个ParseConfig对象用于配置Fastjson的反序列化设置,但并未指定专门的实现了ObjectDeserializer接口的反序列化器,通过分析Fastjson的源码,可以发现在这种情况下,Fastjson会默认创建一个JavaBeanDeserializer实例用于将json转换成java bean,而在转换的过程中,会首先加载这个目标java bean的代理类,加载代理类的时候通过ParseConfig对象进行检查,如果目标类已经创建了代理类,则不在创建,直接使用这个代理类来实例化bean,否则会先创建这个目标类的代理Class。Fastjson默认使用ASM来创建代理类,在未禁用ASM代理的情况下,会直接读取目标类的.class文件,然后通过Classloader的definClass1方法来将读取的字节码加载生成代理类,生成的代理类命名为Fastjson_ASM_XXX_1,其中XXX是目标类的类名,而数字1则是由一个AtomicLong递增得到。


这样就很清楚了,我们的服务在每次接口被调用时,都实例化一个ParseConfig对象来配置Fastjson反序列的设置,而未禁用ASM代理的情况下,由于每次调用ParseConfig都是一个新的实例,因此永远也检查不到已经创建的代理类,所以Fastjson便不断的创建新的代理类,并加载到metaspace中,最终导致metaspace不断扩张,将机器的内存耗尽。


定位到问题之后,解决这个问题就简单了,有很多种方法,而且每种方法都没什么难度。比如说可以定义一个全局的ParseConfig对象用于反序列化,也可以直接使用JSON.parseObject来进行反序列化,还可以通过实现ObjectDeserializer接口,自己实现反序列化的逻辑,避免让fastjson自动创建代理类。


  这个问题解决虽然简单,但是导致问题发生的原因还是值得重视。为什么在升级之前不会出现这个问题?这就要分析jdk1.8和1.7自带的hotspot虚拟机的差异了。从jdk1.8开始,自带的hostspot虚拟机取消了过去的永久区,而新增了metaspace区,从功能上看,metaspace可以认为和永久区类似,其最主要的功用也是存放类元数据,但实际的机制则有较大的不同。首先,metaspace默认的最大值是整个机器的物理内存大小,所以metaspace不断扩张会导致java程序侵占系统可用内存,最终系统没有可用的内存;而永久区则有固定的默认大小,不会扩张到整个机器的可用内存。当分配的内存耗尽时,两者均会触发full gc,但不同的是永久区在full gc时,以堆内存回收时类似的机制去回收永久区中的类元数据(Class对象),只要是根引用无法到达的对象就可以回收掉,而metaspace判断类元数据是否可以回收,是根据加载这些类元数据的Classloader是否可以回收来判断的,只要Classloader不能回收,通过其加载的类元数据就不会被回收。这也就解释了我们这两个服务为什么在升级到1.8之后才出现问题,因为在之前的jdk版本中,虽然每次调用fastjson都创建了很多代理类,在永久区中加载类很多代理类的Class实例,但这些Class实例都是在方法调用是创建的,调用完成之后就不可达了,因此永久区内存满了触发full gc时,都会被回收掉,而使用1.8时,因为这些代理类都是通过主线程的Classloader加载的,这个Classloader在程序运行的过程中永远也不会被回收,因此通过其加载的这些代理类也永远不会被回收,这就导致metaspace不断扩张,最终耗尽机器的内存了。


  其实这个问题并不局限于fastjson,只要是需要通过程序加载创建类的地方,就有可能出现这种问题。尤其是在框架中,往往大量采用类似ASM、javassist等工具进行字节码增强,而根据上面的分析,在jdk1.8之前,因为大多数情况下动态加载的Class都能够在full gc时得到回收,因此不容易出现问题,也因此很多框架、工具包并没有针对这个问题做一些处理,一旦升级到1.8之后,这些问题就可能会暴露出来。

  • 8
    点赞
  • 4
    评论
  • 13
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值