Metaspace OOM前必先频繁扩容并触发Full GC，关键看GC日志中Metaspace使用量回落极少（如10240K→10240K）且Classes unloaded长期为0，结合-XX:+PrintClassLoaderStatistics确认类加载器与类数量持续增长，表明动态代理或类加载器泄漏导致卸载失效。
看到 GC 日志里出现“Metaspace”相关字样，尤其是伴随频繁 Full GC 或元空间持续增长，是动态代理类泄漏的典型信号。关键不是等它爆，而是从日志细节里抓线索——重点看“触发原因”和“回收效果”。
盯紧日志里的三类关键触发提示
Java 8+ 的 GC 日志（开启 -Xlog:gc*:file=gc.log）中，以下三类描述直接指向动态代理问题：
- “Metadata GC Threshold”：表示元空间已达到扩容阈值，JVM 主动触发 GC 尝试回收类。如果这条高频出现（比如每分钟数次），说明新类生成速度远超卸载能力，CGLIB 或反射生成代理类极可能失控。
- “Class unloading” 后紧跟着 “Metaspace used” 下降极少（如只降几十 KB）：说明类加载器没真正死亡，代理类无法卸载。常见于 Spring 测试中反复刷新 ApplicationContext，或自定义 ClassLoader 没被回收。
-
“Full GC” 日志中明确带 “Metaspace” 字样，且耗时长、回收量小：例如
Full GC (Metadata GC Threshold) ... Metaspace: 245120K->245088K(249856K)，前后几乎没变化——这是典型的“类堆积但卸不掉”，大概率是 AOP 切面太宽或代理未复用。
结合时间线定位高危操作段
把 GC 日志的时间戳和业务日志对齐，快速缩小范围：
- 如果某次部署后，“Metadata GC Threshold” 出现频率陡增，立刻检查是否新增了全局切面（如
@Around("@within(*)")）、启用了全包扫描代理，或集成了新脚本引擎（Groovy/JSR-223）。 - 若在定时任务、批量接口调用期间集中爆发，重点查该逻辑是否用
new CGLIBEnhancer()或Javassist动态生成适配器类，且未做缓存（比如每次调用都 new 一个新 ClassLoader）。 - 单元测试运行时频繁出现，基本可锁定
new AnnotationConfigApplicationContext()或@SpringBootTest未加@DirtiesContext，导致每个测试都建全新上下文和全套代理类。
用 jstat 快速验证类加载趋势
不用等 OOM，实时确认是否在“狂生类”：
- 执行
jstat -gc <pid>，重点关注MU（Metaspace Used）和MC（Metaspace Capacity）列。若MU持续上涨、MC随之扩大，且CCSU（Compressed Class Space Used）同步涨，说明新类在不断加载。 - 再跑
jstat -class <pid>，观察loaded（已加载类数）是否只增不减，unloaded（已卸载类数）长期为 0 或极低——这说明类卸载机制失效，动态代理类卡在内存里出不去。
下一步该做什么
确认是动态代理泄漏后，别急着调大 -XX:MaxMetaspaceSize。先做两件事：一是把 CGLIB 代理改成 JDK Proxy（目标类有接口就设 @EnableAspectJAutoProxy(proxyTargetClass = false)）；二是检查所有 @Scope("prototype") Bean 是否真需要每次都新建，能懒加载的加上 @Lazy。控量比扩容管用。
