Java类加载器无法卸载类，热更新实为用新ClassLoader加载同名类并让旧类被GC回收；需确保旧类实例彻底不可达、使用独立URLClassLoader、避免静态引用；常见陷阱包括static字段未清理、线程未终止及JNI资源泄漏。
Java 类加载器不能真正卸载类，这是 JVM 规范决定的
Java 的 ClassLoader 只负责加载，不提供“卸载”接口。所谓“热更新”，本质是让旧类实例自然退出作用域、被 GC 回收，并用新 ClassLoader 加载同名类的新版本——不是卸载，而是绕过。
常见错误现象：ClassNotFoundException 或 NoClassDefFoundError 频发；修改后类行为没变；内存持续上涨（旧类元数据堆积）。
- 必须确保旧类的所有实例（包括静态字段引用的对象）彻底不可达，否则对应的
Class对象无法被 GC - 每次热更新都要新建一个独立的
ClassLoader实例（如URLClassLoader），不能复用 - 避免在新类中直接引用旧类的静态常量或内部类，否则会隐式持有旧类引用
用 URLClassLoader 实现可替换的动态加载
URLClassLoader 是最轻量、可控性最强的自定义加载器起点，适合文件系统路径或 JAR 包热加载场景。
使用场景：插件系统、规则脚本更新、开发期快速重载（非 Spring DevTools 那种）。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 构造时传入
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()无法改变类结构，只能改方法实现 - 要支持字段增删，必须配合类加载器切换 + 对象状态迁移（如序列化旧实例、反序列化到新类），这部分逻辑完全由业务控制
- 所有方案都回避不了“旧对象怎么处理”这个核心问题——它没有银弹，只有权衡
真正难的从来不是怎么加载新类，而是怎么让旧类活着的时候不干扰新类，又在死前把状态交出去。
