java热部署核心是用新类加载器加载新版本类，而非替换旧类；同名类可共存于不同加载器，通过接口解耦实现无缝切换，旧加载器及类在无引用后由gc回收。

Java 中热部署的核心在于绕过默认类加载机制，用自定义类加载器动态加载新版本的类字节码，从而避免重启 JVM。关键不是“替换已加载类”，而是让新请求走新类，旧对象仍用老类——JVM 本身不支持运行时卸载或重定义已加载类（ClassLoader 实例不可变，Class 对象不可替换）。

用独立类加载器隔离新旧版本

每个类版本由独立的 ClassLoader 实例加载，确保类名相同但实际是不同 Class 对象（即不同运行时类型）。JVM 允许同名类共存，只要它们由不同加载器加载。

• 每次更新时新建一个自定义加载器（如继承 URLClassLoader），指向新的 classpath 或字节码流
• 通过该加载器调用 loadClass("com.example.Service")，得到的是新版本的 Class
• 用反射或接口约定创建新实例，老实例和老类加载器保留在内存中，自然 GC 可回收（前提是无强引用）

通过接口解耦，避免直接依赖具体类

业务逻辑需面向接口编程。比如定义 ServiceInterface，所有实现类都实现它。热部署时只替换实现类，接口保持不变且由系统类加载器（或共享父加载器）加载。

Java Maven Secondary Analysis

分析ZIP压缩包或GitLab仓库中的Java Maven项目，确定二次开发范围、类数量、模块分布及生产相关指标。

下载

• 接口必须在自定义加载器的双亲中可见（推荐放在 classpath 根路径，由 AppClassLoader 加载）
• 自定义加载器设置该接口类加载器为 parent，保证 isAssignableFrom 和类型转换正常
• 调用方通过接口引用操作对象，无需知道背后是哪个 Class 实例

触发加载与生命周期管理

不能依赖静态初始化或单例模式——它们绑定到特定类加载器。需显式控制加载、使用和释放时机。

• 监听文件变化（如 WatchService），检测 .class 或 .jar 更新
• 销毁旧加载器关联的资源（关闭线程池、数据库连接等），再丢弃对旧实例的引用
• 新加载器创建新实例后，切换路由（如 Web 请求分发器指向新服务对象）
• 注意：旧 ClassLoader 及其加载的所有类，在无引用后可被 GC，但需确保无静态字段、线程、JNI 引用等泄漏

常见陷阱与注意事项

热部署易出问题，多数源于类加载器关系或资源未清理。

• 不要重写 loadClass 并忽略双亲委派：除非明确需要打破委派（如插件隔离），否则应复用 URLClassLoader 默认行为，仅重写 findClass
• 避免日志框架（如 Log4j）、JSON 库等被重复加载：将它们放在共享类路径，由父加载器提供
• JSP、Spring Boot DevTools、JRebel 等成熟方案本质也是基于类似原理，但做了大量兼容性封装（如处理 ThreadLocal、代理、字节码增强残留）
• Java 9+ 的模块系统和 Layer API 提供了更安全的类隔离方式，但尚未普及用于热部署

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南