java类卸载是jvm被动触发的回收行为，需同时满足三个条件：所有实例被gc、classloader被回收、class对象无强引用；metaspace回收依赖gc类型与时机，验证需通过-xx:+traceclassunloading日志确认。
Java 类卸载不是主动操作，而是 JVM 在特定条件下被动触发的回收行为。要真正释放元空间（Metaspace）内存，关键不在于“怎么卸”，而在于“怎么让类满足卸载条件”。大多数线上问题不是卸载没发生，而是三个硬性条件始终凑不齐。
类卸载必须同时满足的三个核心条件
少一个，类就卡在元空间里不动——这不是配置问题，而是对象引用和生命周期管理问题：
- 该类所有 Java 堆实例已被垃圾回收：包括显式创建的对象、内部类隐式持有的外部类引用、静态集合中缓存的实例，甚至线程局部变量里残留的引用
- 加载它的 ClassLoader 实例已被 GC 回收：系统类加载器（如 Bootstrap/AppClassLoader）基本不会被回收；能被回收的，主要是 Web 容器里的 WebAppClassLoader、动态生成的 URLClassLoader 等自定义加载器
- 该类对应的 Class 对象无任何强引用：常见泄漏点包括 static 字段缓存 Class、Spring ApplicationContext 持有 Bean 定义、ThreadLocal 未调用 remove()、反射 setAccessible 后未清理、JNI 全局引用未配对释放
元空间回收依赖 GC 类型和时机，不是独立触发
Metaspace 不会因为内存占用高就自动清理，它只在特定 GC 阶段配合执行：
- Full GC 时会尝试卸载满足条件的类（最常见但代价高）
- G1 垃圾回收器在并发标记周期末尾自动集成类卸载逻辑，无需额外参数
- CMS 需显式启用：
-XX:+CMSClassUnloadingEnabled（仅旧版本适用） - Metaspace 使用量达到
-XX:MetaspaceSize初始阈值会触发一次 GC 尝试卸载；超过-XX:MaxMetaspaceSize则强制 Full GC
验证类是否真被卸载，别只看 jstat
jstat 的 MU（Metaspace Used）值下降 ≠ 类被卸载，可能是加载失败回滚或元空间内部复用。实锤方式只有一种：
- 启动时加参数：
-XX:+TraceClassUnloading - 观察日志中是否出现类似
[Unloading class com.example.MyService]的输出行 - 配合
jcmd <pid> VM.native_memory summary</pid>或jstat -class <pid></pid>对比类加载总数变化
实际开发中更容易落地的控制手段
与其等卸载，不如从源头减少无用类进入元空间：
- 启动加
-verbose:class记录真实加载的类，分析哪些第三方包只用了 5% 的类，再用mvn dependency:tree精准排除传递依赖 - Web 应用热部署后，手动清理线程上下文类加载器：
Thread.currentThread().setContextClassLoader(null) - 避免 static 缓存 Class 对象；使用软引用/弱引用持有 Class（需谨慎评估业务场景）
- 设置合理上限：
-XX:MaxMetaspaceSize=256m防止无节制增长，配合容器内存限制使用-XX:+UseContainerSupport
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
