分析一个线上内存告警的问题时，发现了造成内存告警的原因是使用fastjson不当导致的。
分析dump发现com.alibaba.fastjson.util.IdentityHashMap$Entry对象比较多。

查找相关文档：

1. fastjson IdentityHashMap 内存泄漏排查 (这篇文档分析描述的情况与我们遇到的问题的原因一样，是使用com.alibaba.fastjson.util.ParameterizedTypeImpl不当导致的)
2. 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的。

问题产生的原因分析：

1. com.alibaba.fastjson.ParserConfig定义一个字段用于缓存不同类的反序列化器，使用的是IdentityHashMap（IdentityHashMap使用的是==比较key的值，不同于HashMap使用equals比较），缓存是以Type为key：
   private final IdentityHashMap<Type,ObjectDeserializer> deserializers = new IdentityHashMap<Type,ObjectDeserializer>();

2. 而我们的业务代码是在调用一个接口后将结果反序列化，然后每次都去创建一个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) {});

https://github.com/alibaba/fastjson/wiki/TypeReference