Java类卸载需同时满足：所有实例被GC回收、自定义类加载器被GC回收、Class对象无强引用；否则类将永久驻留元空间。
Java 中无法“主动卸载”一个类，但可以通过让自定义类加载器被垃圾回收，间接促成其所加载的类被 JVM 卸载。这整个过程不是调用某个方法就能完成的，而是依赖 GC 对类加载器和 Class 对象的清理——前提是三个条件同时满足。
类卸载必须同时满足的三个硬性条件
缺一不可，任意一条不成立，类就永远留在元空间（Metaspace）里：
- 该类所有实例已被 GC 回收：不只是直接 new 出的对象，还包括子类实例、内部类隐式持有的外部类引用、被静态集合（如缓存 Map、List）长期持有的对象。
- 加载它的自定义类加载器实例已被 GC 回收：系统类加载器（Bootstrap/Platform/AppClassLoader）基本不会被回收；只有你手动创建的 URLClassLoader、CustomClassLoader 等才可能被回收——但前提是它没被任何线程、静态字段、ServletContext、ThreadLocal 或监听器间接持有。
- 该类的 Class 对象没有强引用：常见阻断点包括 Spring 的 BeanDefinition、MyBatis 的 MapperRegistry、未清理的 ThreadLocal、反射后残留的 AccessibleObject、JNI 全局引用未释放等。
如何设计可回收的自定义类加载器
核心是切断所有外部引用链，让类加载器成为“孤岛”。推荐做法：
- 继承 URLClassLoader 而非直接继承 ClassLoader，避免重写 findClass 的复杂逻辑（除非有特殊字节码来源需求）；
- 加载完类后，**立即断开对 Class 对象和类加载器的局部变量引用**（如设为 null）；
- 若使用线程上下文类加载器（Thread.currentThread().setContextClassLoader），用完后务必重置为 null 或原始值；
- 避免在静态字段中缓存 Class、实例或类加载器本身；
- 确保加载的类不持有对外部类（尤其是宿主类）的强引用，例如不要在动态类中匿名引用 main 方法所在类的 this。
触发与验证卸载是否发生
不能靠 System.gc() 强制执行，它只是建议，JVM 可忽略。真正卸载只发生在特定 GC 阶段：
立即学习“Java免费学习笔记（深入）”；
- 添加 JVM 参数 -XX:+TraceClassUnloading，运行时看日志中是否出现 “Unloading class xxx”；
- 配合 -verbose:class 观察类加载/卸载总数变化；
- 使用 jstat -gc <pid> 关注 MU（Metaspace used）值是否下降（注意：下降≠卸载成功，可能是加载失败回滚）；
- 更可靠的方式是用 JFR（Java Flight Recorder）录制事件，筛选 ClassUnloading 事件。
典型失败场景与规避建议
线上环境类卸载失败，90% 源于这几类“隐形引用”：
- 线程池未清理上下文类加载器：提交任务前设置 Thread.currentThread().setContextClassLoader(loader)，但任务结束后没恢复；
- 静态缓存未清理：比如自己写的 ClassUtils.cache.put(name, clazz)；
- 未关闭资源：动态类中打开了 FileInputStream、Socket 等，且未在 finally 或 try-with-resources 中释放，导致 finalize 链路延长生命周期；
- 热部署残留监听器：如 ServletContextListener、Spring 的 ContextRefreshedEvent 监听器仍持有着旧 loader。
