元空间泄漏核心是类卸载失败而非数量过多；需用jstat/jcmd/jmap定位动态代理生成源与类加载器泄漏，禁用CGLIB无缓存创建、启用类卸载、优先JDK代理根治。
Java 动态代理类过多引发的元空间泄漏，核心不是“类太多”，而是“类卸不掉”——只要加载它的类加载器还活着、Class 对象还有强引用，对应的元数据就永远钉在本地内存里。排查重点是定位谁在持续生成、谁在阻止卸载。
确认是否真是动态代理撑爆元空间
别猜，先看证据：
- 执行 jstat -gc
，观察 MU（Metaspace Used） 是否单边上涨、MGCC（Metaspace GC 次数） 长期为 0 或极低 → 表明元空间几乎没回收，高度怀疑类卸载失败 - 运行 jcmd
VM.classloader_stats ，若 loadedClassCount 持续上升、unloadedClassCount 几乎不动 → 类加载器泄漏坐实 - 用 jmap -histo:live
| grep -E "(Proxy|Enhancer|CGLIB)" 快速筛选：大量出现 com.sun.proxy.$Proxy\d+（JDK 代理）或 ClassName$$EnhancerByCGLIB$$[a-f0-9]{8}（CGLIB）即为高风险信号
定位代理类的生成源头
不能只看类名，要结合调用链和上下文：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 对高频类名执行 jstack
| grep -A 10 -B 5 "EnhancerByCGLIB\|Proxy" ，找栈中反复出现的方法，例如：
org.springframework.aop.framework.CglibAopProxy.getProxy → Spring 强制 CGLIB 代理
net.sf.cglib.proxy.Enhancer.create → 手动调用 CGLIB 创建代理 - 用 Arthas trace java.lang.ClassLoader.loadClass 实时捕获类加载行为，精准定位哪段业务代码在循环调用 enhancer.create() 或 Proxy.newProxyInstance()
- 检查常见高危场景：
Spring Boot 单元测试中反复 new AnnotationConfigApplicationContext()
AOP 切面表达式过宽（如 @Within(*)）导致为第三方类批量生成代理
MyBatis Mapper 接口方法调用频繁且未复用 SqlSession
验证并切断生成与滞留链条
从机制上阻断持续生成和无法卸载：
立即学习“Java免费学习笔记（深入）”；
- 临时加 JVM 参数：
-Dsun.reflect.noInflation=true（禁用反射膨胀）
-XX:+UnlockExperimentalVMOptions -XX:+ClassUnloading（启用类卸载），压测观察 MU 是否趋稳 - Spring AOP 中显式配置 @EnableAspectJAutoProxy(proxyTargetClass = false)，强制走 JDK 接口代理（仅生成少量 $ProxyN 类），避免 CGLIB 为每个类建独立子类
- 检查 CGLIB 使用点：若手动使用 Enhancer，务必开启缓存（enhancer.setUseCache(true)），禁用缓存（setUseCache(false)）是典型 OOM 诱因
检查类加载器是否真正释放
元空间泄漏本质是类加载器泄漏：
- 执行 jmap -clstats
，重点关注 sun.reflect.DelegatingClassLoader 或 org.springframework.cglib.core.internal.Function 相关加载器加载的类数，超 200 个即属高风险 - 观察 GC 日志中是否频繁出现 "Metadata GC Threshold"，且每次回收后 Metaspace used 下降极少（如 245120K→245088K）→ 说明类加载器没死，代理类赖着不走
- Tomcat redeploy、Spring Boot DevTools 热重启等场景下，旧 WebAppClassLoader 往往未被 GC 回收，它加载的所有类元数据全部滞留
