元空间GC由内存压力与类卸载条件共同触发，需同时满足：逼近MetaspaceSize阈值、存在可卸载类、启用类卸载支持；动态代理和反射存根易因ClassLoader泄漏阻断回收；通过GC日志中“Metadata GC Threshold”与“Classes unloaded: 0”等信号定位问题；调优需设合理上限、开启追踪、复用ClassLoader并启用缓存。
元空间（Metaspace）的垃圾回收不依赖固定时间或周期，而是由内存使用压力与类卸载条件共同驱动。它不会像堆内存那样按Eden区填满就触发Minor GC，而是等到“类元数据快撑爆了”且“有类能被安全卸掉”这两个信号同时出现时，才真正启动回收动作。
元空间GC触发的三个硬性前提
仅当以下三点全部满足，JVM才会在Full GC（或部分并发GC阶段）中尝试卸载类并回收元空间：
- 元空间已逼近当前上限（达到或超过-XX:MetaspaceSize设定的初始阈值），触发“Metadata GC Threshold”事件；
- 存在可被卸载的类——即这些类的所有实例已回收、其Class对象无强引用、且加载它们的类加载器本身也已被判定为垃圾；
- JVM启用了类卸载支持：对G1需加-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:+ExplicitGCInvokesConcurrent，对CMS则必须配-XX:+CMSClassUnloadingEnabled；ZGC/Shenandoah默认支持，无需额外开关。
动态代理与反射存根如何卡住回收链
动态生成的类（如CGLIB代理类、JDK Proxy、Lambda形参类型、MethodHandle存根）本身不是问题，问题在于它们的生命周期绑定方式：
- 若代理类由应用自定义ClassLoader加载，而该ClassLoader被Spring上下文、线程局部变量或静态缓存长期持有，就无法被回收 → 其加载的所有类（包括反射存根）也无法卸载；
- 反射调用中生成的
MethodHandle、VarHandle或Lambda缓存，会隐式强引用对应Class，尤其在未配置-Djdk.internal.lambda.dumpProxyClasses调试时难以察觉； - 频繁调用
Class.forName("xxx", true, cl)或Unsafe.defineAnonymousClass，若cl未复用或泄漏，会持续向元空间注入新类，但旧类因ClassLoader未死而积压不卸。
从GC日志快速定位回收失效点
开启-Xlog:gc*:file=gc.log后，重点关注三类组合信号：
- 高频出现“Metadata GC Threshold”但“Classes unloaded: 0” → 类生成失控，卸载路径被阻断；
- Full GC (Metadata GC Threshold) 后 Metaspace used 几乎不变（如204800K→204792K）→ 类加载器未回收，代理类堆积；
- 日志中夹杂“Unloading class xxx”但数量极少，且集中在系统类（如java.*） → 应用层类基本没动，说明卸载机制未覆盖到业务动态类。
调优与防御性实践建议
- 设置合理上限：-XX:MaxMetaspaceSize=256m（避免无限增长），配合-XX:MetaspaceSize=128m提前触发首次GC；
- 强制暴露类卸载行为：-XX:+TraceClassUnloading，结合-XX:+PrintClassLoaderStatistics确认ClassLoader是否在减少；
- 测试阶段加@DirtiesContext防止Spring测试反复创建ApplicationContext和全套代理类；
- 动态代理务必复用ClassLoader，避免每次new一个独立实例；CGLIB应启用
Enhancer.setUseCache(true)，禁用setClassLoader(null)。
