java模块化（jpms）不支持运行时模块替换，热部署需通过模块感知的类加载器隔离与手动生命周期管理实现：将稳定代码打包为命名模块，易变部分用urlclassloader加载非模块化jar，并通过接口解耦、动态服务发现及资源清理保障更新安全。

Java 模块化（JPMS）本身不支持运行时模块替换，热部署在模块化环境中比传统 classpath 更受限，但可通过“模块感知的类加载器隔离”配合手动模块生命周期管理来逼近目标。关键不是让 java.lang.Module 热卸载，而是绕过模块系统对类加载的强约束，用自定义加载器承载可变逻辑。

模块边界与类加载器的协同设计

JPMS 要求每个模块有明确的 module-info.class，且模块一旦解析完成就不可变更。因此热部署不能动模块声明本身，而应将可变业务代码放在“非模块化 JAR”或“自动模块（Automatic Module）”中，由独立类加载器加载：

• 把核心框架、稳定 API 打包为命名模块（如 com.example.core），由平台类加载器或模块层加载
• 把插件、服务实现、UI 组件等易变部分打包为普通 JAR（无 module-info.class），交由自定义 URLClassLoader 加载
• 模块内的服务发现（ServiceLoader）改用反射+上下文类加载器动态触发，避免编译期绑定到固定模块

打破双亲委派以兼容模块类可见性

默认情况下，模块系统会阻止跨模块访问非导出包，而自定义加载器加载的类又不在任何已解析模块中，容易触发 IllegalAccessError。解决方法是：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 在 loadClass 中对目标类（如 com.example.plugin.*）跳过父委托，直接用 defineClass 加载，确保其归属当前加载器
• 若需调用模块内导出的 API，显式通过 Module.addExports 或 JVM 启动参数 --add-exports 开放包访问（开发期可行，生产慎用）
• 避免在模块代码中硬引用自加载器类；改用接口解耦——接口定义在核心模块，实现类由自定义加载器提供

热更新时的模块资源清理要点

模块化环境下的资源泄漏风险更高，因为 ModuleLayer 和 ClassLoader 的引用链更复杂：

• 每次更新前，显式调用 ModuleLayer.Controller.close()（如使用 Configuration.resolveAndBind 动态构建层），释放模块图引用
• 确保自定义加载器不持有 Module 或 ModuleLayer 实例的强引用（尤其避免静态缓存）
• 关闭该加载器加载的所有服务实例：调用 AutoCloseable.close()、清理 ThreadLocal、注销 MBean、断开数据库连接等
• 监听 ENTRY_MODIFY 后，先停用旧模块层关联的服务，再创建新加载器并构建新模块层（如有必要）

实际落地建议

纯 JPMS + 热部署目前缺乏官方支持，推荐分场景处理：

• 开发阶段：用 Spring Boot DevTools（基于 restart classloader）或 JRebel，它们能透明处理模块路径与类加载冲突
• 插件系统：采用 OSGi 或 Apache Felix，它们原生支持模块热部署，且比 JPMS 更灵活
• 轻量扩展：放弃模块化打包，将插件 JAR 放入独立目录，用自定义加载器 + 接口契约管理，反而更稳定可控

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