java热加载本质是创建新类加载器加载更新类，而非卸载旧类；因jvm不允许重复defineclass且系统加载器无法卸载类，必须通过隔离的自定义classloader实例加载新字节码，使同名类在不同命名空间中视为不同类型，配合接口编程与引用清理实现平滑替换。
Java 中无法真正“卸载”已加载的类，所以热加载不是靠卸载旧类，而是通过创建新的类加载器来加载新版本的类，让旧实例逐步被回收，新请求使用新类。核心在于：每个自定义类加载器实例相互隔离，同一类被不同加载器加载后视为不同类（即使全限定名相同）。
为什么需要自定义类加载器做热加载
默认的 AppClassLoader 和 BootstrapClassLoader 都是双亲委派模型下的系统级加载器，它们加载的类在 JVM 生命周期内不会被卸载，也无法重复加载同名类。要实现热替换，必须绕过双亲委派（或部分绕过），用新加载器加载更新后的字节码，从而获得新 Class 对象。
关键步骤：实现可重用的自定义类加载器
-
继承 ClassLoader，不复用系统加载器，避免双亲委派干扰（通常重写
loadClass方法并去掉super.loadClass调用，或只对特定包路径绕过委派） -
重写 findClass(String name)：负责根据类名定位 .class 文件（如从文件系统、JAR 或内存字节数组读取），调用
defineClass将字节码转为 Class 对象 - 避免静态资源/单例污染：新加载器加载的类不能持有旧类的静态字段引用；全局单例（如 Spring Context）需配合刷新机制，否则仍指向旧类实例
- 类加载器自身不能被旧类引用：加载器对象应由外部容器管理（如 Web 容器中的 ContextClassLoader 切换），防止内存泄漏
一个轻量热加载示例逻辑
假设监控某个目录下 MyService.class 是否变更：
- 每次检测到文件修改，就 new 一个
HotSwapClassLoader实例 - 该加载器从磁盘读取最新字节码，调用
defineClass("com.example.MyService", bytes, 0, bytes.length) - 用新 Class 的
getDeclaredConstructor().newInstance()创建新实例 - 老服务实例逐步停止接收请求，GC 后旧 Class 可被回收（前提是无强引用）
注意事项和常见陷阱
-
类型不兼容：用新加载器加载的
MyService和旧加载器的MyService是两个 Class 对象，不能直接强转，需面向接口编程（如都实现IService接口） - 资源泄漏：类加载器持有其加载的所有类和静态字段，若类中开启线程、注册监听器、持有 IO 句柄，未清理会导致 OOM
-
线程上下文类加载器（TCCL）需同步切换：例如在 Servlet 环境中，处理请求前应设置
Thread.currentThread().setContextClassLoader(newLoader) -
JDK9+ 模块系统限制：模块化环境下需显式开放包（
open）、导出（exports）或添加--add-opens参数才能反射访问内部类
不复杂但容易忽略的是生命周期协同——热加载不只是换 Class，更是换行为、换状态、换依赖关系。实际项目中建议结合字节码增强（如 Javassist）、框架扩展点（如 Spring Boot DevTools、JRebel）或容器级支持（如 Tomcat 的 reloadable="true"）来降低风险。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
