元空间回收需同时满足显式设置-xx:maxmetaspacesize、触发full gc、启用-xx:+classunloading，且类及其classloader均不可达、非系统类；运行时常量池随类卸载而释放，字符串常量池例外。
JVM 对方法区（JDK 8+ 为元空间 Metaspace）中类元数据和运行时常量池的回收，并非按需即收，而是有明确、严格的触发与准入条件。它不像堆内存那样频繁、自动地响应对象分配压力，而是一种“被动式、高门槛”的清理行为。
元空间触发回收的硬性前提
元空间本身使用本地内存（Native Memory），其容量默认无上限（受限于系统资源），因此仅当显式配置了 -XX:MaxMetaspaceSize 且实际使用量逼近该阈值时，才会考虑触发元空间回收。未设上限时，JVM 通常不会主动清理——哪怕存在大量可卸载的类，也不会仅因“存在冗余”而启动回收。
- 必须发生一次 Full GC（或至少是包含元空间扫描的 GC 阶段），因为元空间清理不是独立动作，而是嵌套在整堆回收流程中的可选环节
- GC 过程中检测到元空间已接近或达到 -XX:MaxMetaspaceSize 限制（或系统内存告急）
- JVM 启用类卸载机制：需设置 -XX:+ClassUnloading（HotSpot 默认开启，但某些定制 JDK 或容器环境可能关闭）
类元数据可被回收的四个必要条件
即便触发了元空间回收流程，一个类的元数据（Class、常量池、字段/方法信息等）也必须同时满足以下全部条件，才可能被真正卸载：
- 该类对应的 java.lang.Class 对象没有被任何地方强引用（包括静态变量、线程栈、JNI 全局引用等）
- 该类的所有实例（即堆中该类创建的对象）都已被回收（即堆中无存活实例）
- 该类的类加载器（ClassLoader）本身已是垃圾——即该 ClassLoader 对象不可达，且其加载的其他类也满足上述条件
- 该类不是由引导类加载器（Bootstrap ClassLoader）或扩展类加载器（Platform ClassLoader）加载的系统类（这类类永不卸载）
运行时常量池内容的回收逻辑
运行时常量池（Runtime Constant Pool）作为类元数据的一部分，其条目（如字符串字面量、符号引用）不单独判断是否回收，而是随所属类整体卸载而一并释放。但有两个特例值得注意：
- 字符串常量池（String Table）中的 intern 字符串：若通过 String.intern() 进入全局字符串常量池（位于堆中，JDK 7+），其生命周期独立于类；只有当该字符串对象本身不可达，且未被任何变量引用时，才可能被回收
- 动态生成的常量（如 invokedynamic 生成的 MethodHandle）：若对应的方法句柄或调用点已失效，且无强引用持有时，会在元空间回收阶段被一并清理
常见误区与关键事实
很多人误以为“类加载后长期不用就会被自动卸载”，实际上：没有显式触发 Full GC、没有类加载器退出作用域、没有打破类与 ClassLoader 的强引用链，元空间里的类元数据将一直驻留。典型场景如 Web 应用热部署失败、OSGi 框架残留类、自定义 ClassLoader 泄漏，都会导致元空间持续增长直至 OOM（java.lang.OutOfMemoryError: Metaspace）。
