江苏龙网

  1. 主页 > 生活百科 > >

一次完整的JVM堆外内存泄漏故障排查记录( 五 )

JVM


/** * 返回Json字符串.驼峰转_ * @param bean 实体类. */public static String buildData(Object bean) {    try {        SerializeConfig CONFIG = new SerializeConfig();        CONFIG.propertyNamingStrategy = PropertyNamingStrategy.SnakeCase;        return jsonString = JSON.toJSONString(bean, CONFIG);    } catch (Exception e) {        return null;    }}问题根因我们在调用wcs前将驼峰字段的实体类序列化成下划线字段，**这需要使用fastjson的SerializeConfig，而我们在静态方法中对其进行了实例化 。SerializeConfig创建时默认会创建一个ASM代理类用来实现对目标对象的序列化 。也就是上面被频繁创建的类com.alibaba.fastjson.serializer.ASMSerializer_1_WlkCustomerDto,如果我们复用SerializeConfig，fastjson会去寻找已经创建的代理类，从而复用 。但是如果new SerializeConfig()，则找不到原来生成的代理类，就会一直去生成新的WlkCustomerDto代理类 。
下面两张图时问题定位的源码：

一次完整的JVM堆外内存泄漏故障排查记录

文章插图
 

一次完整的JVM堆外内存泄漏故障排查记录

文章插图
 
我们将SerializeConfig作为类的静态变量，问题得到了解决 。
private static final SerializeConfig CONFIG = new SerializeConfig();static {    CONFIG.propertyNamingStrategy = PropertyNamingStrategy.SnakeCase;}fastjson SerializeConfig 做了什么SerializeConfig介绍：
?
SerializeConfig的主要功能是配置并记录每种Java类型对应的序列化类（ObjectSerializer接口的实现类），比如Boolean.class使用BooleanCodec（看命名就知道该类将序列化和反序列化实现写到一起了）作为序列化实现类，float[].class使用FloatArraySerializer作为序列化实现类 。这些序列化实现类，有的是FastJSON中默认实现的（比如Java基本类），有的是通过ASM框架生成的（比如用户自定义类），有的甚至是用户自定义的序列化类（比如Date类型框架默认实现是转为毫秒，应用需要转为秒） 。当然，这就涉及到是使用ASM生成序列化类还是使用JavaBean的序列化类类序列化的问题，这里判断根据就是是否Android环境（环境变量"java.vm.name"为"dalvik"或"lemur"就是Android环境），但判断不仅这里一处，后续还有更具体的判断 。
?
理论上来说，每个SerializeConfig实例若序列化相同的类，都会找到之前生成的该类的代理类，来进行序列化 。们的服务在每次接口被调用时，都实例化一个ParseConfig对象来配置Fastjson反序列的设置，而未禁用ASM代理的情况下，由于每次调用ParseConfig都是一个新的实例，因此永远也检查不到已经创建的代理类，所以Fastjson便不断的创建新的代理类，并加载到metaspace中，最终导致metaspace不断扩张，将机器的内存耗尽 。
升级JDK1.8才会出现问题导致问题发生的原因还是值得重视 。为什么在升级之前不会出现这个问题？这就要分析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时，都会被回收掉 。


推荐阅读


上一篇：监控Redis？使用Grafana的Source插件轻松搞定

下一篇：李济仁气血双补茶禁忌,五味枸杞强身茶气血双补