java类卸载必须同时满足三个条件：所有实例被回收、classloader被回收、class对象无任何引用；仅自定义类加载器加载的类才可能卸载，系统类终身驻留，成功卸载需通过-xx:+traceclassunloading日志验证。
Java 类卸载不是“不用就删”，而是有严格前提：必须同时满足三个条件，缺一不可。真正能被卸载的类，几乎全部来自自定义类加载器，系统类（如 java.lang.String）基本终身驻留。
类卸载的三个硬性条件
JVM 不主动清理类，只有当以下三点全部成立时，才允许卸载：
- 该类所有 Java 堆实例已被回收——包括直接 new 出的对象、子类实例、内部类隐式持有的外部类引用，以及静态集合里残留的引用；
- 加载它的 ClassLoader 实例已被垃圾回收——ClassLoader 是类元数据的“主人”，它不消失，类就卡在 Metaspace 里；
-
该类对应的
java.lang.Class对象无任何强引用——常见干扰源包括：Spring 的类型注册表、静态缓存 Map、未清理的ThreadLocal、反射调用后遗留的setAccessible(true)、JNI 全局引用等。
哪些类实际可能被卸载
由 Bootstrap、Platform 或 Application ClassLoader 加载的类（比如 Spring Boot 启动类、业务 Service 类）通常不会卸载，因为它们的加载器生命周期和 JVM 一样长。真正有机会卸载的，只出现在动态场景中：
-
Web 应用重启时：Tomcat 卸载旧应用，丢弃
WebAppClassLoader，其加载的全部类才有机会被清理； -
插件或模块热部署：OSGi Bundle、IDE 插件、自定义脚本引擎反复创建
URLClassLoader或DynamicClassLoader，卸载插件后若加载器被 GC，相关类才可卸载； - 字节码动态生成框架：CGLib 代理类、Javassist 修改类、动态代理接口实现类，若频繁生成又不清理加载器，极易引发 Metaspace OOM；
- JSP 编译与重载：每个 JSP 页面编译为 Servlet 类，由独立类加载器加载，页面修改后旧加载器弃用，是经典卸载场景。
为什么线上很少见到类成功卸载
不是 JVM 不支持，而是条件太难凑齐：
- Spring 等框架默认把
Class对象缓存在ConcurrentHashMap里，且通过ApplicationContext长期持有； - 线程池中的线程未重置上下文类加载器（
Thread.currentThread().setContextClassLoader(null)被忽略）； - 热部署失败后，旧
ClassLoader被监听器、定时任务、异步回调等间接引用，导致整个链路无法回收； - 即使卸载成功，Metaspace 内存也不会立刻还给操作系统，而是留在 JVM 空闲池中复用，所以
jstat的MU值下降 ≠ 类卸载发生。
如何确认类真的被卸载了
别信图表和内存数字，只看日志证据：
- 启动参数加
-XX:+TraceClassUnloading，运行中看到类似[Unloading class com.example.PluginService]才算实锤； - 配合
jcmd <pid> VM.native_memory summary scale=MB</pid>对比前后 “class” 区域变化； - 再用
jmap -histo:live查证目标类实例数是否归零，排除“假卸载”（比如只是加载失败回滚）。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
