class卸载失败的根本原因是classloader未被回收，导致其加载的类元数据无法释放；g1虽能在并发标记阶段识别无用类，但实际卸载仍依赖full gc或mixed gc触发，而classloader泄漏会使metaspace持续膨胀、频繁gc甚至oom。
这个问题其实是在问：为什么类加载设计不合理，会让 G1 的并发标记阶段在卸载类时“力不从心”，甚至导致 Metaspace 压力陡增、频繁 Full GC 或 OOM。
不当类加载机制会制造不可回收的类加载器
类能否卸载，核心不是类本身，而是加载它的 ClassLoader。只要这个加载器还被强引用着，它加载的所有 Class 对象就无法被回收，对应的 Metaspace 元数据也就一直占着内存。
常见不当做法包括：
- 把自定义 ClassLoader 存在静态字段或单例中，导致其生命周期与应用同寿
- 在线程局部变量（ThreadLocal）里持有 ClassLoader，而线程长期存活（如线程池未清理）
- 监听器、回调、SPI 服务实现类通过反射间接持有了 ClassLoader 引用，却未显式释放
G1 的并发标记本身不主动触发类卸载
G1 从 Java 9 起确实在并发标记（Concurrent Marking）阶段能识别无用类元数据，但识别 ≠ 卸载。它只做两件事：
- 标记哪些 ClassLoader 已不可达（即满足卸载前提）
- 将这些 ClassLoader 关联的类元数据标记为“待回收”
真正执行卸载动作，仍需依赖一次 GC 周期——通常是 Mixed GC 或 Full GC。如果类加载器始终不可达判定失败，G1 就只能反复标记、反复跳过，Metaspace 持续膨胀。
动态元数据增长加剧 GC 压力传导
所谓“动态元数据”，比如：
- 大量使用字节码生成（CGLIB、Javassist、ASM）产生匿名类
- 频繁热部署（Spring Boot DevTools、Tomcat reload）反复创建新 ClassLoader
- 框架自动注册代理类、Lambda 生成的内部类（尤其在高并发初始化场景）
这些行为会在 Metaspace 中快速堆积元数据。而 G1 的 Metaspace 回收不是独立线程，它绑定在 GC 周期中完成。当新生代 GC 频繁（如 Eden 区太小）、Mixed GC 又因老年代碎片或阈值未达标而迟迟不触发时，Metaspace 就成了“堰塞湖”——G1 看得见问题，却腾不出手来清淤。
物理压迫的本质是资源调度失配
这不是算法缺陷，而是运行时资源分配逻辑的错位：
- ClassLoader 生命周期由应用代码控制，Metaspace 容量由 JVM 参数硬限，GC 触发节奏由堆使用率驱动
- 三者没有协同反馈机制：Metaspace 快爆了，不会自动加速 Mixed GC；ClassLoader 泄漏了，G1 也无法强制中断用户线程去断开引用链
- 结果就是：G1 在并发标记中不断“看到”该卸载的类，却始终等不到它们真正被回收的时机——这种延迟累积，就是对 G1 卸载能力的物理压迫
