java类卸载需同时满足三个条件：所有实例被gc回收、自定义类加载器被gc回收、class对象无强引用；缺一不可，否则类永久驻留metaspace。
Java 类加载器本身不提供“卸载类”的接口，所谓卸载，其实是让 JVM 在垃圾回收时自动清理掉类的元数据——前提是三个条件同时满足：该类所有实例已被回收、加载它的自定义类加载器实例已被回收、该类的 Class 对象没有强引用。
卸载依赖的三个硬性条件
缺一不可，任意一条未满足，类就会一直留在 Metaspace 中：
- 所有实例被 GC 回收：包括直接 new 的对象、内部类隐式持有的外部类引用、被静态集合（如缓存 Map）长期持有的对象；
-
自定义类加载器实例被 GC 回收：系统类加载器（Bootstrap/Platform/AppClassLoader）不会被回收，只有你手动创建的
URLClassLoader或自定义子类才可能；但若它被线程、静态字段、ServletContext、ThreadLocal等间接持有，就无法回收； -
Class 对象无强引用：常见泄漏点包括 Spring 的
BeanDefinition、MyBatis 的MapperRegistry、未清理的ThreadLocal、反射后残留的AccessibleObject、JNI 全局引用等。
如何设计可回收的自定义类加载器
核心是切断所有外部引用链，让类加载器成为“孤岛”：
- 继承
URLClassLoader而非直接继承ClassLoader，避免重写findClass的复杂逻辑（除非需从非标准源加载字节码）； - 加载完类后，立即把局部变量中的
Class和类加载器引用设为null； - 若使用
Thread.currentThread().setContextClassLoader()，用完务必重置为null或原始值； - 不在静态字段中缓存
Class、实例或类加载器本身； - 确保动态类不持有对外部宿主类的强引用（例如避免在匿名内部类中引用
this）。
触发与验证卸载是否发生
不能靠 System.gc() 强制执行，它只是建议，JVM 可忽略。真正卸载只发生在特定 GC 阶段：
- 启动参数加
-XX:+TraceClassUnloading，运行时观察日志是否出现[Unloading class com.example.Xxx]； - 配合
-verbose:class查看类加载/卸载总数变化； - 用
jstat -gc <pid></pid>关注MU（Metaspace used）是否下降（注意：下降≠卸载成功，可能是加载失败回滚）； - 更可靠的方式是用 JFR（Java Flight Recorder）录制事件，筛选
ClassUnloading事件。
为什么不能“主动卸载”？
因为 JVM 规范未定义卸载 API。类元数据按类加载器隔离存储在 Metaspace 中，JVM 只在确认该加载器彻底不可达时，才扫描其名下所有类是否可卸载。一旦你的 CustomClassLoader 被某个静态变量、监听器或框架悄悄持有，它和它加载的所有类就全卡在内存里了。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
