Java对象序列化不当会引发堆内存膨胀、元空间泄漏或堆外内存失控，重点排查对象结构、反序列化行为及类加载机制，需检查大集合引用、禁用Fastjson autoType、监控DirectByteBuffer及ClassLoader泄漏。
Java 对象序列化本身不直接导致内存溢出，但不当使用会引发堆内存膨胀、元空间泄漏或堆外内存失控——尤其在反序列化环节。排查重点不在“序列化过程”，而在被序列化的对象结构、反序列化行为、以及配套的类加载机制。
检查序列化对象是否携带大集合或长生命周期引用
序列化会递归遍历对象图，若对象持有未清理的缓存、静态集合、未关闭的流或数据库连接，这些引用会被一并写入字节流，反序列化后重新构建，可能造成内存堆积。
- 用
jmap -histo <pid>查看运行中实例数量异常多的类（如自定义 DTO、Map 实现） - 对可疑类启用
-XX:+HeapDumpOnOutOfMemoryError，OOM 后用 MAT 分析 Dominator Tree，确认是否由反序列化重建的对象主导内存占用 - 避免序列化含
transient以外的资源型字段（如InputStream、Connection），它们无法正确重建且可能隐式持引用
警惕 Fastjson 等库的 autoType 引发元空间爆炸
JDK 8+ 中，Fastjson（1.2.24–1.2.80）开启 Feature.SupportAutoType 时，会根据 JSON 字段名动态加载类，每次解析新类型都会向 Metaspace 注册类元数据，长期运行易触发 OutOfMemoryError: Metaspace。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 检查日志是否频繁出现
checkAutoType或autoType is not support警告 - 执行
jstat -gc <pid>观察MU（Metaspace Used）是否持续单向增长 - 禁用 autoType：
ParserConfig.getGlobalInstance().setAutoTypeSupport(false)，再压测对比 Metaspace 使用趋势
识别反序列化引发的堆外内存泄漏
部分序列化框架（如 Kryo、FST）或底层依赖（Netty 的 ByteBuf、NIO DirectByteBuffer）在反序列化过程中会分配直接内存。若未显式释放或复用缓冲区，容易触发 OutOfMemoryError: Direct buffer memory。
立即学习“Java免费学习笔记（深入）”；
- 用
jcmd <pid> VM.native_memory summary scale=MB查看Internal和Direct类别内存是否异常升高 - 检查反序列化代码是否调用
ByteBuffer.allocateDirect()且未调用.cleaner().clean()或依赖 GC 回收（不可靠） - 对 Netty 场景，确认
PooledByteBufAllocator是否启用，并设置合理maxOrder和tinyCacheSize
验证 Serializable 实现是否引入隐式类加载风险
实现 Serializable 的类若含匿名内部类、Lambda 表达式或动态代理（如 Spring AOP 增强后的 Bean），反序列化时需加载对应类——而这些类往往由临时 ClassLoader 加载，易造成元空间泄漏或 ClassNotFoundException 后续重试失败。
- 用
jmap -clstats <pid>统计已加载类总数及各 ClassLoader 实例数，观察是否存在持续增长的非系统 ClassLoader - 避免将 Spring Bean、Service 接口等直接序列化；优先使用 DTO 扁平结构，显式控制字段
- 为关键序列化类显式声明
serialVersionUID，防止因类版本不一致导致反复加载失败类
