方法区类计数器爆仓（Metaspace OOM）是动态代理类持续生成且未卸载的典型信号，反映ClassLoader被业务对象强引用导致代理类无法卸载，在Spring AOP、MyBatis、Feign等场景易引发类加载器级内存泄漏。
方法区类计数器爆仓（Metaspace OOM）本身不是内存泄漏，但它是动态代理类持续生成且未卸载的典型信号——而这类问题在 Spring AOP、MyBatis、Feign 等大量使用 JDK/CGLIB 动态代理的场景中，极易引发真正的类加载器级内存泄漏。
为什么方法区爆仓能暴露动态代理泄漏
Java 8+ 使用 Metaspace 存储类元数据，其大小默认无上限（受限于本地内存）。当看到如下日志：
java.lang.OutOfMemoryError: Compressed class spacejava.lang.OutOfMemoryError: Metaspace
说明 JVM 已加载的类数量或元数据体积超出限制。重点不是“类太多”，而是这些类无法被卸载——因为它们被某个存活的 ClassLoader 持有强引用，而该 ClassLoader 又被业务对象（如静态缓存、线程局部变量、未关闭的代理工厂）意外持有。
动态代理类（如 $Proxy123、com.sun.proxy.$ProxyXX 或 net.sf.cglib.proxy.Enhancer$$EnhancerBySpringCGLIB$$xxxx）正是这种“短命但难卸载”的典型：每次创建新代理都会生成新类，若 ClassLoader 不死，这些类就永远留在 Metaspace 中。
面试中如何快速定位到代理类泄漏
不用等 OOM，从常规监控和堆转储就能切入：
-
查类加载器数量与代理类占比：用
jstat -class <pid></pid>观察loaded持续上涨；再用jcmd <pid> VM.native_memory summary scale=MB</pid>看 metaspace 使用趋势 -
抓取并分析堆转储（heap dump）：用
jmap -dump:format=b,file=heap.hprof <pid></pid>，然后用 MAT 打开 → “Histogram” → 输入java.lang.ClassLoader查看加载器实例数；右键某个 ClassLoader → “Merge Shortest Paths to GC Roots” → 排除 system classloader 后，重点看谁在持有着它（比如一个 static Map、一个 ThreadLocal、一个未 close 的 SqlSessionFactory） -
过滤代理类名：在 MAT 的 Histogram 中搜索
$Proxy或CGLIB$$，看数量是否随请求量线性增长；点开某代理类 → “Merge Shortest Paths to GC Roots” → 若路径终点是某个业务 Bean 或静态容器，基本锁定泄漏源头
常见泄漏模式与修复要点
面试时说出具体模式比泛泛而谈更有说服力：
-
Spring Boot 中反复 refresh ApplicationContext：每次 refresh 都新建 ClassLoader 加载新代理类，但旧上下文里的 Bean 和代理仍被线程池、静态监听器等引用 → 解决：避免运行期 refresh；必须时确保老上下文彻底释放（调用
close()并清空所有外部强引用） -
MyBatis Mapper 动态代理未绑定生命周期：Mapper 接口被注入到 singleton Bean 中，而该 Bean 又被静态工具类缓存 → 解决：不用静态缓存 Mapper；或改用
@MapperScan+ 接口代理由 Spring 管理 - FeignClient 每次 new Builder 创建新代理：未复用 Feign.Builder 或未将 Client 声明为 @Bean → 解决：声明为单例 Bean，由 Spring 管理其生命周期
- CGLIB 回调函数持有外部对象：比如 Enhancer.setCallback(new MethodInterceptor() { ... }) 中匿名内部类捕获了 this，导致代理类无法卸载 → 解决：用静态内部类 + 显式传参，或使用 WeakReference 包装回调上下文
一句话收尾
方法区爆仓是表象，背后是 ClassLoader 被业务代码意外钉住；抓住“代理类数量增长 + GC Roots 持有路径”，就能把抽象的“动态代理泄漏”变成可验证、可修复的具体链路。
