Java不支持类真正卸载，但可通过销毁旧ClassLoader间接实现动态替换，前提是彻底切断其与GC Roots的所有引用并触发Full GC回收。
Java 本身不支持类的真正“卸载”，但通过销毁旧的自定义类加载器（ClassLoader），可间接实现类的动态替换——前提是旧类加载器及其加载的所有类、实例、静态引用全部被 GC 回收。热部署框架（如 Spring Boot DevTools、JRebel、HotswapAgent）正是基于这一机制，核心在于隔离类加载 + 切断引用 + 触发 GC。
1. 类加载器隔离是前提
每个热部署单元（如一个模块、一个 jar、一个 web 应用）必须使用独立的自定义 ClassLoader（如 URLClassLoader 的子类），不能复用系统类加载器（AppClassLoader）或共享父加载器加载业务类。否则新旧类会混杂，无法安全卸载。
- 新类加载器应以系统类加载器为父，仅负责加载当前模块的字节码
- 避免在类中持有跨加载器的静态引用（如
static Map存了旧类实例） - 确保所有回调、监听器、线程局部变量（
ThreadLocal）都已清理，否则强引用会阻止加载器回收
2. 主动切断所有外部引用
类加载器能否被 GC，取决于是否还有任何活跃引用指向它或它加载的类。常见泄漏点包括：
-
全局缓存：Spring 的
DefaultListableBeanFactory、Guava Cache 等若缓存了旧类的 Bean 或 Class 对象，需手动清空或使用弱引用 -
线程与定时任务：后台线程（如
Timer、ScheduledExecutorService）若持有旧类的 Runnable，需显式 cancel/shutdown -
JNI 或代理对象：CGLIB 生成的代理类、JDK 动态代理的
InvocationHandler若引用旧类实例，需一并释放
3. 销毁加载器并触发类卸载
销毁不是调用某个方法，而是让加载器对象变为不可达，并协助 JVM 回收：
- 将旧加载器变量置为
null，例如：oldClassLoader = null; - 调用
oldClassLoader.close()（JDK 7+ 的URLClassLoader支持，会关闭底层资源） - 主动触发一次 Full GC（仅用于调试验证）：
System.gc();（注意：不保证立即执行，生产环境勿依赖） - 可通过
java.lang.ref.WeakReference包装加载器，观察其是否被回收，确认卸载是否成功
4. 创建新加载器并重新加载类
销毁旧加载器后，新建一个同源（相同 URLs）的 ClassLoader，再重新 loadClass：
- 推荐继承
URLClassLoader并重写findClass，便于控制字节码来源（如从磁盘/网络读取最新 .class） - 加载类后，需重建实例（如反射调用构造器）、重新注册到容器（如 Spring 的
BeanDefinitionRegistry） - 注意：类名相同但加载器不同 → 是两个完全无关的类，
instanceof和强制转型会失败，必须统一用新加载器加载所有关联类型
这个过程看似简单，实则对应用结构要求极高。多数场景建议直接使用成熟方案（如 DevTools 的 restart 模式、JRebel 的字节码注入），而非手写类加载器卸载逻辑——后者极易因引用残留导致内存泄漏或 ClassNotFoundException。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
