分析一个线上内存告警的问题时，发现了造成内存告警的原因是使用fastjson不当导致的。
分析dump发现com.alibaba.fastjson.util.IdentityHashMap$Entry对象比较多。
查找相关文档：
- fastjson IdentityHashMap 内存泄漏排查 (这篇文档分析描述的情况与我们遇到的问题的原因一样，是使用com.alibaba.fastjson.util.ParameterizedTypeImpl不当导致的)
- fastjon官方在很早的版本就修复过类似的问题，https://github.com/alibaba/fastjson/issues/849 ，相关代码：https://github.com/alibaba/fastjson/commit/ef50a5b756a6cab1ab753f4a661bdfb0ccbd6b7e ，他们修复的这个bug是针对com.alibaba.fastjson.TypeReference，这个类实际也是基于com.alibaba.fastjson.util.ParameterizedTypeImpl的。
问题产生的原因分析：
- com.alibaba.fastjson.ParserConfig定义一个字段用于缓存不同类的反序列化器，使用的是IdentityHashMap（IdentityHashMap使用的是==比较key的值，不同于HashMap使用equals比较），缓存是以Type为key：
private final IdentityHashMap<Type,ObjectDeserializer> deserializers = new IdentityHashMap<Type,ObjectDeserializer>(); -
而我们的业务代码是在调用一个接口后将结果反序列化，然后每次都去创建一个ParameterizedTypeImpl实例，而fastjson针对每次创建的PamrameterizedTypeImpl都会作为一个key加入到deserizers中进行缓存。
// ... ... ParameterizedTypeImpl type = new ParameterizedTYpeImpl(new Type[]{ SomeInfo.class },null,CommonVO.class); CommonVO<SomeInfo> result = (CommonVO<SomeInfo>)JSON.parseObject(jsonString,type);所以，随着不断的请求发起，内存泄漏产生了。（上面提到的fastjson自身的bug修复就是针对不同的类型又采用了ConcurrentHashMap基于Class进行了一次缓存）
问题修复：
方法一：
由于这里主要只是因为泛型才用了ParameterizedTypeImp，并且只有这一处，所以可以简单粗暴把这个定义为局部变量的type改为private static final的全局变量就可以避免内存泄漏了
private static final ParameterizedTypeImpl SOME_INFO_TYPE = ...
方法二：
使用com.alibaba.fastjson.TypeReference。
JSON.parseObject(json,new TypeReference<CommonVO<T>>(SomeInfo.class) {});
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。