动态代理类过多引发metaspace溢出，本质是classloader未卸载导致元数据无法回收；其元数据存于本地内存的metaspace中，受-xx:maxmetaspacesize限制，不受-xmx控制。
Java 动态代理类生成过多本身不会直接“泄漏内存”，但会引发 Metaspace 内存持续增长直至溢出，本质是类元数据无法卸载——这属于方法区（JDK 8+ 即 Metaspace）的内存泄漏。
动态代理类为什么占的是 Metaspace 而不是堆内存
动态代理生成的类（如 com.sun.proxy.$Proxy123 或 Service$$EnhancerByCGLIB$$a1b2c3d4）本身是 Class 对象，它存放在堆中；但它的结构信息——包括方法签名、常量池、注解、字段描述、字节码等元数据——全部存储在 Metaspace（本地内存） 中。Metaspace 不受 -Xmx 控制，而是由 -XX:MaxMetaspaceSize 限制。
只要加载它的 ClassLoader 还活着，这些元数据就永远钉在 Metaspace 里，GC 无法回收。
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
代理类堆积 → 类加载器无法卸载 → Metaspace 持续上涨
- Spring AOP 切面过宽（如
@Pointcut("execution(* com.example..*.*(..))")），为每个匹配类生成独立代理，CGLIB 每个目标类都新建一个子类 - 单元测试中反复创建
AnnotationConfigApplicationContext，但未加@DirtiesContext，导致多个上下文共存、ClassLoader 无法释放 - 手动循环调用
Proxy.newProxyInstance()或Enhancer.create()，且每次传入不同接口或类，触发新类生成 - 使用匿名内部类实现接口后再代理它——每个实例都会生成唯一命名的代理类，无法复用
为什么说这是“泄漏”，而不是“用得多”
正常情况：类被加载后，若其 ClassLoader 被 GC 回收，且该类无任何强引用（如 Class 对象未被静态持有、代理实例已销毁），则对应元数据可被 Metaspace GC 清理。
泄漏情况：ClassLoader 被意外强引用保留，例如：
- ThreadLocal 缓存了上下文类加载器（某些框架初始化时未清理）
- 静态 Map 缓存了由该 ClassLoader 加载的 Class 或代理对象
- Web 容器热部署后，Filter/Listener 未正确销毁，旧 WebAppClassLoader 仍被引用
- Groovy 脚本引擎每次执行都新建 ClassLoader，却未显式
close()
此时，哪怕代理对象早已不再使用，ClassLoader 活着 → 所有它加载的代理类元数据也一直驻留 → Metaspace 使用量只增不减。
如何确认是这个问题
- 启动参数加
-XX:+TraceClassLoading -XX:+TraceClassUnloading，观察日志中Loaded [com.sun.proxy.$Proxy...]频繁出现，但Unloaded几乎为零 - 运行
jstat -gc <pid></pid>，发现MU（Metaspace used）持续上升，MGCC（Metaspace GC count）长期为 0 或极低 - 执行
jmap -clstats <pid></pid>，重点关注sun.reflect.DelegatingClassLoader或org.springframework.cglib.core.internal.Function类加载器加载的类数是否超 200+
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
