元空间内存泄漏最典型场景是动态代理类持续生成且类加载器无法回收。spring aop代理泛滥、反射膨胀、classloader泄漏、高频动态类生成未缓存等均会导致metaspace持续增长。
元空间内存泄漏最典型的场景，就是动态代理类持续生成、类加载器却无法回收。这不是类太多的问题，而是类“赖着不走”——只要加载它的类加载器还活着，这些代理类的元数据就永远钉在 Metaspace 里。
Spring AOP 代理泛滥
当切面表达式写得太宽，比如 @Within(*) 或 @Pointcut("execution(* com.example..*.*(..))")，Spring 会为每个匹配的类生成独立代理。CGLIB 为每个目标类创建形如 Service$$EnhancerByCGLIB$$a1b2c3d4 的子类；JDK Proxy 虽只生成少量 $ProxyN 类，但若接口过多或上下文反复刷新，也会快速堆积。
- 单元测试中每跑一个 @SpringBootTest 就 new 一个 AnnotationConfigApplicationContext，代理类不复用、ClassLoader 不释放
- 未加 @DirtiesContext，导致多个测试共用同一容器但代理持续叠加
- 全局启用 proxy-target-class=true，强制所有代理走 CGLIB，放大类生成压力
反射调用触发类膨胀
Java 反射默认有“膨胀机制”：前 15 次（默认阈值）走 JNI 快路径，之后自动生成 GeneratedMethodAccessorN 类优化性能。高频 setter/getter 访问（如 Jackson 反序列化、BeanUtils 拷贝、MyBatis 映射）会批量产出这类反射适配器。
-
jstat -class
显示 loaded 持续上涨、unloaded 长期为 0 -
jmap -clstats
中 sun.reflect.DelegatingClassLoader 加载类数超百，风险极高 - 压测时加 -Dsun.reflect.inflationThreshold=1，若 Metaspace 增速明显加快，即确认反射是主因
ClassLoader 泄漏导致卸载失效
类能否卸载，关键看类加载器是否被 GC。而泄漏往往藏在隐蔽引用中：
- ThreadLocal 持有 ClassLoader（如某些框架在线程初始化时缓存上下文类加载器）
- 静态集合（如 Map
）缓存了由特定 ClassLoader 加载的类 - Web 容器热部署后，监听器未反注册、Filter/Servlet 未销毁，导致旧 ClassLoader 被强引用
- Groovy/JSR-223 脚本引擎每次编译都新建 ClassLoader，又没显式 close
高频动态类生成未缓存
有些业务逻辑主动使用字节码工具，却忽略了复用原则：
- 循环中反复 new CglibEnhancer() 或 JavassistClassPool().getAndRename()
- 每次 HTTP 请求都基于不同参数生成新代理类，未做 class name → Class 缓存
- RPC 框架为每个服务接口动态生成适配器，但未限制接口数量或生命周期
- 规则引擎（如 Drools）、表达式引擎（如 Aviator）热加载时未复用 ClassLoader
