Java动态加载与卸载机制解析

Java 并不支持真正意义上的类卸载，所谓“热更新”实则是通过创建独立的 URLClassLoader 加载同名类的新版本，同时确保旧类所有实例（包括静态字段、后台线程和 JNI 资源）彻底不可达，使其 Class 对象能被 GC 回收；但这一过程极易因静态引用残留、线程未终止或资源未释放而失败，导致 ClassNotFoundException、行为未更新或内存泄漏——真正难点不在加载新类，而在于安全、可控地终结旧类的生命并完成状态交接，这也是 JRebel 等方案需结合字节码增强、类加载器隔离与手动状态迁移的根本原因。

Java 类加载器不能真正卸载类，这是 JVM 规范决定的

Java 的 ClassLoader 只负责加载，不提供“卸载”接口。所谓“热更新”，本质是让旧类实例自然退出作用域、被 GC 回收，并用新 ClassLoader 加载同名类的新版本——不是卸载，而是绕过。

常见错误现象：ClassNotFoundException 或 NoClassDefFoundError 频发；修改后类行为没变；内存持续上涨（旧类元数据堆积）。

• 必须确保旧类的所有实例（包括静态字段引用的对象）彻底不可达，否则对应的 Class 对象无法被 GC
• 每次热更新都要新建一个独立的 ClassLoader 实例（如 URLClassLoader），不能复用
• 避免在新类中直接引用旧类的静态常量或内部类，否则会隐式持有旧类引用

用 URLClassLoader 实现可替换的动态加载

URLClassLoader 是最轻量、可控性最强的自定义加载器起点，适合文件系统路径或 JAR 包热加载场景。

使用场景：插件系统、规则脚本更新、开发期快速重载（非 Spring DevTools 那种）。

• 构造时传入 new URL[]{new File("plugin.jar").toURI().toURL()}，路径必须存在且可读
• 调用 loadClass("com.example.Plugin") 后，务必通过反射获取实例，不要硬编码类型（否则编译期就绑定老类）
• 加载失败时检查 ClassLoader.getParent() 是否意外委托给了系统类加载器——这会导致你加载的类被忽略

示例关键片段：

URLClassLoader loader = new URLClassLoader(new URL[]{pluginUrl}, null);
Class clazz = loader.loadClass("com.example.Plugin");
Object instance = clazz.getDeclaredConstructor().newInstance();

热更新失败的三个典型陷阱

多数热更新卡点不在加载逻辑本身，而在类与环境的耦合细节上。

• static 字段未清理：比如日志器、缓存 Map、线程池，只要还持有旧类的 ClassLoader 引用，整个类簇就无法回收
• 线程未终止：后台线程（如 Timer、ExecutorService）若在旧类中启动且未显式 shutdown，会持续持有该类的上下文
• JNI 或本地资源泄漏：如果类里调用了 System.loadLibrary() 或打开了 FileChannel，JVM 不会自动释放，需手动 close / unload

HotSwap 和 JRebel 的底层差异在哪

标准 JVM 的 hotswap（通过 JVMTI）仅支持方法体变更，不支持新增/删除字段、修改签名、增减类——这是 JVM 启动时类结构已固化导致的硬限制。

JRebel 等商业方案实际做了两件事：一是用字节码增强在类中插入回调钩子，二是用自定义类加载器隔离变更范围，再配合运行时类重定义（retransform）绕过部分限制。

• 普通 Java Agent + Instrumentation.retransformClasses() 无法改变类结构，只能改方法实现
• 要支持字段增删，必须配合类加载器切换 + 对象状态迁移（如序列化旧实例、反序列化到新类），这部分逻辑完全由业务控制
• 所有方案都回避不了“旧对象怎么处理”这个核心问题——它没有银弹，只有权衡

真正难的从来不是怎么加载新类，而是怎么让旧类活着的时候不干扰新类，又在死前把状态交出去。

理论要掌握，实操不能落！以上关于《Java动态加载与卸载机制解析》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！