类卸载必须同时满足三个条件：该类所有实例已被gc回收、classloader实例已被回收（仅自定义加载器可能）、class对象无任何强引用，且需full gc或g1并发标记周期配合才能释放metaspace内存。
Java 类元数据区（即 Metaspace）的回收不依赖于“空间满了就清”，而是严格绑定在类卸载（class unloading）这一动作上。只有当某个类被彻底卸载，它占用的元数据才会从 Metaspace 中释放。
类卸载必须同时满足的三个条件
这三个条件缺一不可，任一不满足，该类的元数据就无法被回收：
- 该类及其子类的所有实例对象均已从堆中回收，即堆中不存在任何对该类的强引用实例；
- 加载该类的 ClassLoader 实例本身已被 GC 回收，例如 Web 应用重启时 Tomcat 的 WebAppClassLoader 失去所有引用；
- 该类对应的
java.lang.Class对象没有被任何强引用持有，包括静态变量、ThreadLocal、JNI 全局引用、反射缓存（如Method.getDeclaringClass()残留）、或 Spring 的类型注册表等。
Metaspace 回收的实际触发时机
即使类卸载条件全部满足，Metaspace 的清理也不会立即发生，而是在特定 GC 事件中执行：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 多数情况下，需等待一次 Full GC（如 Parallel GC、CMS 或 G1 的 Full GC 阶段）；
- G1 收集器会在并发标记周期（Concurrent Marking Cycle）结束时，检查并卸载符合条件的类；
- 当设置
-XX:MaxMetaspaceSize且 Metaspace 接近上限时，JVM 会主动触发一次 GC 尝试类卸载，但是否成功仍取决于上述三条件； -
System.gc()仅是建议，不能保证触发 Metaspace 回收，现代 JVM 通常忽略该调用。
常见能真正触发元数据回收的场景
这些场景之所以有效，是因为它们天然促成三条件同时成立：
- Web 容器热部署/应用卸载：如 Tomcat 停止一个 WebApp，其 WebAppClassLoader 被回收，所有由它加载的业务类实例（Controller、Service 等）也已销毁，Class 对象无外部强引用；
- 动态代理类生命周期结束：Spring AOP 或 CGLIB 生成的代理类，若其创建所依赖的自定义类加载器被回收，且代理对象全部销毁、Class 引用清除，元数据可被卸载；
- OSGi 或模块化框架卸载模块：每个模块独占类加载器，模块卸载即类加载器失效，连带其加载的全部类元数据被批量清理。
影响回收效果的关键配置
合理配置有助于及时发现和释放废弃元数据：
-
-XX:MaxMetaspaceSize=256m：设上限可避免 Metaspace 无限增长，超限时强制触发 GC 尝试卸载； -
-XX:MetaspaceSize=64m：初始阈值，首次达到即触发第一次 Metaspace 相关 GC（类似 Eden 区满）； -
-XX:+TraceClassUnloading：开启后可在 GC 日志中看到哪些类被成功卸载，用于诊断泄漏； - 避免静态集合长期持有 Class 或 ClassLoader 引用（如
static Map<string class></string>），这是最常见的元数据泄漏源头。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
