元空间垃圾回收的触发临界点取决于类卸载能否启动，而非单纯内存使用量；必须同时满足三条件：类实例全被回收、其ClassLoader被GC回收、Class对象无强引用，且需Full GC配合才能批量释放内存。
元空间垃圾回收的触发临界点，不是单纯看“用了多少内存”，而是由类卸载机制能否启动所决定的——它本质上是一次“条件满足后的被动响应”，不是容量阈值到达就自动清理。
类卸载是元空间回收的前置开关
Metaspace 本身不直接做“按类回收”，它只在 Full GC（或某些并发 GC 阶段）中，配合类卸载逻辑批量释放内存。也就是说：没有类被成功卸载，元空间就不会真正减少占用。而类卸载必须同时满足三个硬性条件：
- 该类所有 Java 堆实例已被 GC 回收（包括子类、内部类隐式引用、静态集合里残留的对象）
- 加载它的 ClassLoader 实例已被 GC 回收（关键！系统类加载器永不回收，只有自定义加载器才可能）
- 该类对应的 Class 对象无任何强引用（如 static 缓存、ThreadLocal 未 remove、反射 setAccessible 后未清理、JNI 全局引用未配对释放）
临界点实际由“可卸载类加载器数量”驱动
元空间是否收缩，取决于有多少个自定义 ClassLoader 被判定为“不可达”。一旦某个 ClassLoader 满足上述三条件，它所加载的全部类元数据就会在本次 GC 中被一并卸载。此时 Metaspace 才会真正释放对应内存块。
所以真正的临界点是：
- 应用中存在一批生命周期结束的自定义加载器（如 Web 应用重启、插件卸载、DevTools 热更失败后旧 loader 残留）
- 这些 loader 不再被任何 GC Root 引用（线程上下文类加载器已重置、Spring 上下文已 close、static 字段已置 null）
- Full GC 被触发（比如元空间使用量超过 -XX:MetaspaceSize 初始阈值，或堆 GC 连带触发）
为什么调大 -XX:MaxMetaspaceSize 反而可能延缓回收？
当 MaxMetaspaceSize 设置过大（如 2G），JVM 会推迟触发 Full GC，也就推迟了类卸载的执行时机。即使已有大量可卸载类，只要没到 GC 触发点，元空间占用就持续上涨。更危险的是：频繁小幅度增长可能让 JVM 误判为“需扩容”，不断向 OS 申请新内存，却始终不尝试回收旧块。
合理做法是：
- 设一个偏保守的上限（如 512m–1g），让 GC 更早介入
- 搭配 -XX:+CMSClassUnloadingEnabled（JDK8）或 -XX:+G1UseConcMarkSweepGC（JDK9+）启用并发类卸载
- 加 -XX:+TraceClassUnloading 观察日志中是否有 “Unloading class xxx” 输出，确认卸载是否真实发生
监控时要看“卸载量”，不是只盯“使用率”
元空间使用率持续上升 ≠ 一定泄漏；但若 GC 日志中长期看不到类卸载记录，且 ClassLoaderStatistics 显示加载器数量只增不减，那基本可以断定卸载条件被阻断。常见阻断点：
- Thread.currentThread().setContextClassLoader(oldLoader) 后忘记恢复
- 第三方框架（如某些 RPC 或序列化库）缓存了 Class 对象并持有强引用
- 使用 URLClassLoader 加载插件后，未显式调用 close()，也未清空其 parent 引用
