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。解决方法是：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 在
loadClass中对目标类（如com.example.plugin.*）跳过父委托，直接用defineClass加载，确保其归属当前加载器 - 若需调用模块内导出的 API，显式通过
Module.addExports或 JVM 启动参数--add-exports开放包访问（开发期可行，生产慎用） - 避免在模块代码中硬引用自加载器类；改用接口解耦——接口定义在核心模块，实现类由自定义加载器提供
热更新时的模块资源清理要点
模块化环境下的资源泄漏风险更高，因为 ModuleLayer 和 ClassLoader 的引用链更复杂：
立即学习“Java免费学习笔记（深入）”；
- 每次更新前，显式调用
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 放入独立目录，用自定义加载器 + 接口契约管理，反而更稳定可控
