元空间溢出核心是“类卸不掉”而非“类太多”，主因包括反射膨胀生成不可回收的GeneratedMethodAccessor类、动态代理类持续累积、类加载器泄漏导致ClassLoader无法回收，以及未启用对应GC类卸载参数。
元空间溢出的核心不是“类太多”，而是“类卸不掉”。只要类加载器还活着、Class对象被强引用持有，这些类的元数据就一直钉在 Metaspace 里，持续占用本地内存。
高频反射调用撑爆元空间
Java 反射默认有“膨胀机制”：前几次调用走慢路径（NativeMethodAccessorImpl），达到阈值后动态生成 GeneratedMethodAccessorN 类并切换到快路径。这个过程会不断产生新类，且这些类由 sun.reflect.DelegatingClassLoader 加载——该类加载器通常不会被回收，导致对应元数据永久驻留。
- 典型场景：JSON 反序列化（Fastjson/Jackson setter 调用）、MyBatis 结果集映射、BeanUtils.copyProperties
- 验证方法：加参数
-Dsun.reflect.inflationThreshold=1压测，若 Metaspace 增速明显加快，基本可确认是反射主因 - 根治建议：启用
-Dsun.reflect.noInflation=true，强制跳过膨胀，统一走 JNI 路径；或改用MethodHandle/VarHandle替代高频反射
动态代理类持续累积
Spring AOP、MyBatis、RPC 框架等大量使用动态代理。JDK Proxy 生成 $ProxyN 类，CGLIB 生成 ClassName$$EnhancerByCGLIB$$ 类。若代理对象生命周期长、或代理创建逻辑嵌套在循环/请求中，就会批量加载代理类。
- 常见误配：Spring 配置
proxy-target-class=false（想用 JDK Proxy）但实际被 CGLIB 触发，或未限制代理缓存 - 排查手段：执行
jmap -clstats <pid>，重点关注DelegatingClassLoader加载类数；日志中搜索$Proxy、CGLIB\$\$ - 缓解方向：复用代理实例（避免每次 new）、检查是否误在循环内创建代理、升级框架版本看是否修复了代理缓存缺陷
类加载器泄漏阻断回收
Metaspace 中的类能否被 GC，取决于其类加载器是否可达。Web 容器热部署、OSGi、自定义 ClassLoader 等场景下，若 ClassLoader 对象本身被静态引用、线程局部变量（ThreadLocal）或监听器长期持有，它加载的所有类都无法卸载。
- 典型表现：多次部署/重启后 Metaspace 使用量阶梯式上涨，
jstat -gc <pid>显示MU（Metaspace used）单边增长、MGCC（Metaspace GC 次数）极少或为 0 - 必须配套：使用 G1 GC 时需加
-XX:+UnlockExperimentalVMOptions -XX:+ClassUnloading；CMS 需-XX:+CMSClassUnloadingEnabled；Parallel GC 不支持类卸载 - 定位工具：用
jcmd <pid> VM.native_memory summary或 MAT 分析类加载器引用链
其他高危触发点
除反射与代理外，以下行为也会显著增加元数据压力：
- ES/Spring Data 查询滥用：每次请求都 new 查询构建器（如 ElasticsearchRestTemplate 的 QueryBuilder），触发 Instantiator 类反复加载
- Groovy/JSR-223 脚本：每执行一段脚本就编译一个新类，尤其在循环中 eval 多次
- JSP 编译（传统 Web 容器）：每个 JSP 页面转为 Servlet 类，修改频繁时类数量激增
-
未设上限的
-XX:MaxMetaspaceSize：虽默认可扩容，但无节制增长终将耗尽物理内存，引发系统级 OOM
