Java热部署核心是用新类加载器加载新版本类，而非替换旧类；同名类可共存于不同加载器，通过接口解耦实现无缝切换，旧加载器及类在无引用后由GC回收。
Java 中热部署的核心在于绕过默认类加载机制，用自定义类加载器动态加载新版本的类字节码，从而避免重启 JVM。关键不是“替换已加载类”，而是让新请求走新类，旧对象仍用老类——JVM 本身不支持运行时卸载或重定义已加载类（ClassLoader 实例不可变，Class 对象不可替换）。
用独立类加载器隔离新旧版本
每个类版本由独立的 ClassLoader 实例加载，确保类名相同但实际是不同 Class 对象（即不同运行时类型）。JVM 允许同名类共存，只要它们由不同加载器加载。
- 每次更新时新建一个自定义加载器（如继承
URLClassLoader），指向新的 classpath 或字节码流 - 通过该加载器调用
loadClass("com.example.Service")，得到的是新版本的Class - 用反射或接口约定创建新实例，老实例和老类加载器保留在内存中，自然 GC 可回收（前提是无强引用）
通过接口解耦，避免直接依赖具体类
业务逻辑需面向接口编程。比如定义 ServiceInterface，所有实现类都实现它。热部署时只替换实现类，接口保持不变且由系统类加载器（或共享父加载器）加载。
- 接口必须在自定义加载器的双亲中可见（推荐放在
classpath根路径，由AppClassLoader加载） - 自定义加载器设置该接口类加载器为 parent，保证
isAssignableFrom和类型转换正常 - 调用方通过接口引用操作对象，无需知道背后是哪个
Class实例
触发加载与生命周期管理
不能依赖静态初始化或单例模式——它们绑定到特定类加载器。需显式控制加载、使用和释放时机。
立即学习“Java免费学习笔记（深入）”；
- 监听文件变化（如
WatchService），检测.class或.jar更新 - 销毁旧加载器关联的资源（关闭线程池、数据库连接等），再丢弃对旧实例的引用
- 新加载器创建新实例后，切换路由（如 Web 请求分发器指向新服务对象）
- 注意：旧
ClassLoader及其加载的所有类，在无引用后可被 GC，但需确保无静态字段、线程、JNI 引用等泄漏
常见陷阱与注意事项
热部署易出问题，多数源于类加载器关系或资源未清理。
-
不要重写
loadClass并忽略双亲委派：除非明确需要打破委派（如插件隔离），否则应复用URLClassLoader默认行为，仅重写findClass - 避免日志框架（如 Log4j）、JSON 库等被重复加载：将它们放在共享类路径，由父加载器提供
- JSP、Spring Boot DevTools、JRebel 等成熟方案本质也是基于类似原理，但做了大量兼容性封装（如处理
ThreadLocal、代理、字节码增强残留） - Java 9+ 的模块系统和
LayerAPI 提供了更安全的类隔离方式，但尚未普及用于热部署
