这个错误发生在 Dubbo 远程调用过程中，当尝试反序列化响应时。
为什么会导致元空间(OOM)迅速上涨
- 类加载机制：每次反序列化失败时，JVM 都会尝试加载缺失的类，这些失败的类加载尝试会在元空间中留下痕迹。
- Dubbo/Hessian 序列化行为：Hessian 序列化框架在遇到未知类时会不断尝试解析和加载这些类，每次失败都会在元空间中积累元数据。
- 重试机制：从日志看 Dubbo 尝试了 3 次调用，每次调用都会触发相同的类加载失败过程。
- 元空间特性：元空间用于存储类元数据，这些失败的类加载尝试会导致元数据不断累积但无法释放，最终导致元空间耗尽。
当JVM遇到NoClassDefFoundError时，会在元空间中留下以下不可回收的"痕迹"：
-
ClassLoader元数据：
- 每次加载尝试都会创建ClassLoader相关的元数据记录
- 包括ClassLoader的层级关系、加载历史等内部结构
- 这些元数据会被记录在元空间的"LoaderData"区域
-
Klass结构体残留：
- JVM会为尝试加载的类分配Klass结构体(类的内部表示)
- 即使加载失败，部分Klass骨架结构仍会保留
- 这些结构体占用元空间但无法完整使用
-
常量池残留：
- 类加载过程中已解析的部分常量池项会残留
- 包括部分方法签名、字段描述符等符号引用
-
方法元数据碎片：
- 如果类中有方法声明，方法元数据(MethodData)会部分初始化
- 这些半初始化的方法元数据无法被完整回收
为什么Full GC无法回收这些痕迹
-
可达性判断问题：
- 这些残留元数据仍然被JVM内部数据结构引用(如ClassLoaderDataGraph)
- GC根可达性算法认为它们仍在"使用中"
-
元空间内存管理特性：
- 元空间使用"块分配"策略，碎片化严重
- 部分加载失败的类元数据会污染整个内存块
- 即使其中部分数据可回收，整个内存块也可能无法释放
-
Klass生命周期问题：
- JVM对Klass对象的生命周期管理较为保守
- 一旦创建就不轻易释放，以防后续需要复用
-
ClassLoader的保守行为：
- ClassLoader会保留加载历史记录(即使失败)
- 这些历史记录会保持对失败加载尝试的引用
