Java类卸载需同时满足三个条件：所有实例被回收、ClassLoader被回收、Class对象无强引用；仅在Full GC或特定并发GC阶段被动触发，不依赖内存使用量阈值。
Java 类卸载不是“自动清理”，而是极严格的被动回收过程，核心目标是释放方法区（JDK 8+ 即元空间）中不再需要的类元数据。它不看内存用了多少，只看三个条件是否同时成立——缺一不可。
类卸载必须同时满足的三个硬性条件
这三个条件构成一个“与”逻辑，任意一条不满足，类就卡在元空间里，哪怕内存快爆了也不会卸载：
- 所有实例已被回收：不只是当前类的直接实例，还包括子类对象、内部类隐式持有的外部类引用、以及被静态集合（如 ConcurrentHashMap、List 缓存）长期持有的对象。
- ClassLoader 实例已被 GC 回收：系统类加载器（Bootstrap/Extension/AppClassLoader）基本不会被回收；真正可能被回收的是 WebAppClassLoader、URLClassLoader 等自定义加载器——前提是它本身不再被任何线程、监听器、静态字段或上下文（如 ServletContext）间接引用。
- Class 对象无任何强引用：常见阻断点包括 Spring 的 BeanDefinitionRegistry、MyBatis 的 MapperRegistry、ThreadLocal 未清理、反射 setAccessible 后残留的 AccessibleObject 引用、JNI 全局引用未配对释放。
元空间回收不是独立行为，而是 GC 的附属动作
元空间不会自己决定“该清了”，它只在特定 GC 场景下配合执行类卸载逻辑：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 仅在 Full GC 或某些并发 GC 阶段（如 G1 的并发标记周期末尾、CMS 的 concurrent mode failure 后）才尝试卸载。
- 达到
-XX:MetaspaceSize初始阈值会触发一次 GC，但只是“尝试”卸载；超-XX:MaxMetaspaceSize则强制 Full GC。 -
System.gc()是建议而非指令，JVM 可忽略；它不保证触发类卸载，更不保证成功。
为什么线上几乎看不到元空间明显下降？
不是没回收，而是条件太难凑齐：
立即学习“Java免费学习笔记（深入）”；
- 框架大量缓存 Class 对象（Spring 的泛型类型推导、MyBatis 的 Mapper 接口注册），且常通过 static 字段持有。
- 线程未重置上下文类加载器：
Thread.currentThread().setContextClassLoader(null)被忽略，导致旧 loader 被线程池长期持有。 - 热部署失败后旧 ClassLoader 残留，新请求已走新 loader，但旧 loader 仍被监听器、定时任务、未关闭的资源等间接引用。
- 即使卸载成功，元空间内存也不会立刻还给操作系统，而是进入 JVM 内部空闲池供后续复用。
怎么确认类真的被卸载了？
别只盯着 jstat -gc 的 MU 值，那可能是加载失败回滚，不是回收：
- 加参数
-XX:+TraceClassUnloading，日志里出现[Unloading class xxx]才算实锤。 - 用
jcmd <pid> VM.native_memory summary scale=MB</pid>对比前后 “class” 区域变化。 - 配合
jmap -histo:live查目标类实例数是否归零，并结合jmap -clstats或ClassLoader相关 dump 分析加载器状态。
