fastjson因使用identityhashmap按对象地址缓存parameterizedtypeimpl，导致每次new新实例均被当作不同key持续堆积，引发内存泄漏；修复需将type提升为static final或改用typereference。
排查因动态生成类引发的序列化工具内存泄漏，关键不是“看日志”，而是盯住缓存机制与类型对象的生命周期。jackson 和 fastjson 都会为类型缓存反序列化器或序列化器，但它们对“类型相等性”的判断逻辑不同——这正是泄漏的温床。
先确认是不是动态类/动态 Type 在作祟
动态类常见于以下场景：运行时用 ASM 或 ByteBuddy 生成代理类、AOP 增强后的目标类、泛型擦除后又通过 ParameterizedTypeImpl 手动构造的 Type 实例、或基于反射拼装的 GenericArrayType 等。这些对象每次 new 出来都是新实例，哪怕语义完全一致。
验证方法：
- 用
jmap -histo:live <pid> | grep -E "(ParameterizedTypeImpl|Generated|Proxy|$$Enhancer)"</pid>查是否有大量动态类名或 Type 实现类 - 在 MAT 中查看
IdentityHashMap$Entry（Fastjson）或ConcurrentHashMap$Node（Jackson）的 key 列表，看是否堆着成百上千个不同地址但结构雷同的Type实例 - 检查代码中是否在循环、高频接口里反复调用类似
new ParameterizedTypeImpl(...)或Class.forName("xxx" + timestamp)
区分 Fastjson 和 Jackson 的缓存陷阱
Fastjson 使用 IdentityHashMap<type objectdeserializer></type> 缓存，只认对象地址（==），不走 equals。只要每次传入的是新 Type 实例，就新建一个反序列化器并永久驻留——这是最典型的泄漏路径。
Jackson 默认用 ConcurrentHashMap，key 是 JavaType，它重写了 equals/hashCode，对泛型结构做语义比对。但如果你绕过 TypeFactory，直接 new 自定义 JavaType 子类，或使用未标准化的 ResolvableType（Spring 场景），仍可能破坏缓存一致性。
所以不能只看“用了泛型”，要看“泛型类型对象是不是每次都 new”。
定位泄漏源头的实操步骤
按顺序执行，避免盲猜：
- 导出堆快照：
jmap -dump:live,format=b,file=heap.hprof <pid></pid> - 用 MAT 打开，执行 Leak Suspects Report，重点关注
ParserConfig（Fastjson）或SerializerProvider/DeserializerProvider（Jackson）的 retained heap - 对
IdentityHashMap或ConcurrentHashMap右键 → Path to GC Roots → exclude weak/soft references，看哪些业务线程或静态容器持有了大量 Type 键 - 反查代码：找到调用
JSON.parseObject(json, type)或objectMapper.readValue(json, typeReference)的位置，确认type是否来自局部 new
修复方式要匹配问题本质
不是加个 @JsonIgnore 就能解决，得切断“新类型→新缓存项”链路：
-
Fastjson 场景：把
ParameterizedTypeImpl提升为static final字段；或改用TypeReference<list>>() {}</list>（注意必须是匿名子类，才能保留泛型信息） -
Jackson 场景：统一通过
objectMapper.getTypeFactory().constructParametricType(List.class, User.class)构造JavaType，禁用手动 new 子类 - 通用兜底：若无法改造调用方，可限制缓存大小（Fastjson 1.2.83+ 支持
ParserConfig.setDeserializerCacheSize()；Jackson 可配置SimpleModule.setDeserializerModifier()拦截并复用已有 deserializer）
本质上，这不是序列化库的 bug，而是把“类型”当成一次性值来用，却忽略了它在框架里是缓存的 key。只要让相同语义的类型复用同一个实例，泄漏就自然消失。
