元空间溢出主因是反射或动态代理类持续加载且无法卸载，导致元数据累积；关键在类加载器存活和强引用阻碍回收，而非单纯类数量多。
元空间溢出往往不是突然发生的，而是反射或动态代理类持续加载、卸载失败后缓慢累积的结果。关键不在“有没有类”，而在“类是否能被回收”——只要类加载器还活着、Class对象还有强引用，这些类元数据就一直钉在 Metaspace 里。
确认是不是反射/代理类在撑爆 Metaspace
别急着调参数，先验证根源：
- 用 jstat -gc <pid> 看 MU（Metaspace used） 是否单边上涨，MGCC（Metaspace GC 次数） 是否极少或长期为 0；若 MU 接近 MC 且几乎不回落，基本可锁定
- 加 JVM 参数 -XX:+TraceClassLoading -XX:+TraceClassUnloading（测试环境），观察日志中是否高频出现 GeneratedMethodAccessor\d+、DelegatingConstructorAccessorImpl 或 $Proxy\d+、CGLIB\$\$ 类名
- 执行 jmap -clstats <pid>，重点看 sun.reflect.DelegatingClassLoader 加载了多少类——上百个就是高风险信号
定位高频反射或代理的业务入口
膨胀类不是凭空来的，它对应真实业务调用热点：
- 降低膨胀阈值快速验证：-Dsun.reflect.inflationThreshold=1，再压测。若 Metaspace 增速明显加快，说明反射调用确实是主因
- 检查常见高危点：JSON 反序列化（Fastjson/Jackson 的 setter 调用）、ORM 字段赋值（MyBatis 结果集映射）、Bean 工具类（BeanUtils.copyProperties）、AOP 中绕过代理直接反射调用目标方法
- 动态代理类多来自框架：Spring AOP 默认用 JDK Proxy（生成 $Proxy 类），CGLIB 增强则产生 ClassName$$EnhancerByCGLIB$$ 类；查 Spring 配置是否误配了 proxy-target-class=false 却又强制要求 CGLIB
缓解与根治策略要分层落地
不能只靠 -XX:MaxMetaspaceSize 硬扛，得从机制上切断源头：
- 禁用反射膨胀机制：-Dsun.reflect.noInflation=true。这会让所有反射调用跳过 JNI 慢路径，直接走 MethodAccessor 子类（如 NativeMethodAccessorImpl → GeneratedMethodAccessor），避免反复生成新类；首次调用略慢，但后续稳定且无类增长压力
- 替换反射为高效替代方案：对字段/方法高频访问场景，改用 MethodHandle（支持预绑定、可复用）、VarHandle（JDK9+，零开销）、或编译期生成（Lombok @Getter/@Setter、MapStruct）
- 确保类能被卸载：使用 G1 GC 时必须配 -XX:+UnlockExperimentalVMOptions -XX:+ClassUnloading；CMS 需 -XX:+CMSClassUnloadingEnabled；Parallel GC 不支持类卸载，换 GC 是前提
结合 GC 日志判断卸载是否生效
光看 Metaspace 使用量不够，要看卸载行为本身：
- 启用 -XX:+PrintGCDetails -XX:+PrintClassLoaderStatistics
- 关注每次 Full GC 后的 Classes unloaded 行：长期为 0 或个位数，说明类根本没被回收
- 看 ClassLoader 数量是否持续上升，尤其非系统类加载器（如 Tomcat WebAppClassLoader、Spring Boot 的 LaunchedURLClassLoader）——这是类加载器泄漏的典型表现
- 留意日志中 Metaspace: X->X(K) 这类字段：箭头后数值几乎不变，代表回收无效
