该问题本质是类加载器违反双亲委派机制，导致同一类被重复加载、常量池持续膨胀，引发Metaspace OOM；需通过jstat、jmap及类加载日志确认现象，定位loadClass/findClass实现错误，并修复为显式委托父加载器、缓存已加载类、避免递归加载。
这个问题本质是类加载器未遵循双亲委派机制，导致同一类被反复加载、常量池持续膨胀，最终引发 Metaspace OOM。它不表现为堆内存泄漏，而是 JVM 元空间的结构性失控。
确认是否为常量池级联暴涨
先看现象是否匹配：
- Metaspace 使用量随请求量线性增长，Full GC 不释放，重启后快速复现
- jstat -gc <pid> 显示 MC（Metaspace Capacity）和 MU（Metaspace Used）持续攀升，而堆内存稳定
- jmap -histo:live <pid> | grep -i "class" 显示 Class 实例数异常高（远超应用实际类数量）
- 开启 -XX:+TraceClassLoading -XX:+TraceClassUnloading 后，日志中出现大量重复类名（如 com.example.Service$$EnhancerBySpringCGLIB$$a1b2c3d4）且几乎不卸载
定位“未重写双方法”的具体位置
双亲委派失效的关键在于自定义 ClassLoader 中 loadClass() 和 findClass() 的实现逻辑错误。重点检查以下三类代码：
- loadClass() 中跳过父委托：比如直接调用 findClass(name)，未先调用 super.loadClass(name) 或 parent.loadClass(name)
- findClass() 内部重复 defineClass()：每次调用都 new 一个新 byte[] 并 defineClass，未做类名缓存或已加载判断
- 重写了 findClass() 却没重写 loadClass()：看似安全，实则绕过双亲委派——因为默认 loadClass() 会调用 findClass()，而你没覆盖父加载逻辑
验证类唯一性破坏与常量池污染
用 MAT 或 jcmd 分析 heap dump：
- 筛选 java.lang.Class 实例，按 classLoader 字段分组，查看同一全限定名是否对应多个 Class 对象
- 对任意一个疑似重复类（如 com.example.User），右键 → “Merge Shortest Paths to GC Roots” → 看其 ClassLoader 是否为自定义实例，且该 ClassLoader 被 ThreadLocal 或静态 Map 强引用
- 展开 Class 对象的 constantPool 属性，对比不同实例的 constantPool.cache.length 或内部符号表大小——若差异显著，说明常量池已分裂冗余
修复必须从加载器契约入手
不是加个 synchronized 或缓存就能解决，核心是回归 ClassLoader 设计契约：
- 若需定制加载逻辑，必须重写 loadClass(String, boolean)，并在开头显式调用父类逻辑：
if (name.startsWith("java.") || name.startsWith("javax.")) return super.loadClass(name, resolve); - findClass() 只负责字节码获取，defineClass() 前应先检查 ClassLoader 已加载缓存（可通过 ConcurrentHashMap<String, Class> 实现）
- 禁止在 defineClass() 后再做任何可能触发新类加载的操作（如反射 newInstance()、访问静态字段），否则形成递归加载链
不复杂但容易忽略
