ModuleLayer通过模块名+类加载器双重标识实现类唯一性，天然隔离同名类的静态变量；借助exports/uses服务机制控制状态可见性，无需多ClassLoader即可达成轻量安全的对象隔离。
Java模块化（java.lang.ModuleLayer）本身不直接隔离“变量”，但能通过**类的唯一性约束 + 模块边界控制 + 服务解耦机制**，在不引入多个自定义 ClassLoader 的前提下，实现轻量、安全、可维护的对象与状态隔离。它不是类加载器的替代品，而是更高层次的隔离范式——用声明式模块关系代替手工加载器管理。
模块层隔离天然避免同名类冲突
Java 9+ 的模块系统将“类的唯一性”从 全限定名 + 类加载器 扩展为 全限定名 + 模块名 + 类加载器。当两个模块各自导出同名包（如 com.example.config），只要它们不互相 requires 或未被同一层聚合，JVM 就不会允许它们的类共存于同一个模块图中。这意味着：
- 模块 A 中的
ConfigHolder.counter和模块 B 中同名类的静态变量，物理上位于不同模块的运行时镜像中，互不可见； - 即使模块 A 和 B 都使用 AppClassLoader 加载，只要它们属于不同
ModuleLayer，其类实例就无法强转、无法共享字段； - 无需手动 new URLClassLoader、绕双亲委派、管理 jar 路径——模块系统自动完成命名空间划分。
用模块导出/依赖控制变量可见范围
变量所属的类（如 UserContext、CacheManager）是否被隔离，取决于它是否被其他模块“看到”。关键在于模块描述符（module-info.java）的精确配置：
javascript-typescript-typescript-scaffold
下载
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
- 只在内部使用的变量类，不
exports对应包，外部模块连类名都解析不到； - 需跨模块共享的状态，应定义为接口（如
CounterService），由模块提供方在provides中声明实现，调用方通过uses获取——此时变量实际存储在提供方模块内，调用方仅持接口引用，无静态字段暴露风险； - 禁止模块间直接传递含私有状态的对象（如
new UserContext()实例），否则仍会因模块加载器差异触发ClassCastException。
动态 ModuleLayer 实现运行时多开隔离
对需要“多租户”或“插件多版本共存”的场景，可按需创建独立 ModuleLayer，每个层加载一组互信模块，彼此完全隔离：
立即学习“Java免费学习笔记（深入）”；
- 主应用层加载通用基础模块（
core-api,logging）； - 为每个租户/插件创建新
ModuleLayer，仅 resolve 其专属模块（如tenant-a-service,v2-validator），不包含其他租户的模块； - 各层中的
Config类虽同名同包，但因所属模块不同、模块图独立，其静态变量内存地址分离，方法区数据互不干扰； - 相比每个插件配一个 URLClassLoader，ModuleLayer 启动更快、GC 友好、调试更直观，且天然支持 JPMS 安全策略（如禁止反射访问非导出包）。
与类加载器协同而非取代
模块化不是要淘汰 ClassLoader，而是将其“语义升级”。真实落地中常组合使用：
- 系统级基础类（
java.base）由 BootstrapClassLoader 加载，模块层在此之上构建； - 业务模块 JAR 打包为具名模块后，由
ModuleFinder发现，再交由统一的ClassLoader（如AppClassLoader）加载——省去为每个模块维护独立加载器的复杂度； - 当必须混用非模块化老 JAR（如某些 SDK）时，才启用自定义 ClassLoader 隔离，其余部分交由模块系统管理，形成“主干模块化 + 边缘插件化”的混合架构。
