如何应用 requires 声明实战强制执行模块间的单向依赖原则并规避变量死锁

requires用于声明模块单向静态依赖，可强制阻断循环依赖；它不解决变量死锁等运行时并发问题，后者需用synchronized、Lock等机制处理。

这里有一个核心判断：requires 声明负责的是模块间的静态依赖关系，不是线程同步工具。你提到的“变量死锁”，其实是多线程竞争共享变量时发生的循环等待问题，属于并发编程的范畴。而 requires 作为 Ja va 平台模块系统（JPMS）的关键字，主要作用于模块的编译期和启动期，跟运行时变量、锁、线程没有直接关系。

所以，需要把这两件事分开来看：
✅ requires 确实可以强制执行模块间的单向、显式、静态依赖原则，从机制上防止循环依赖；
❌ 但它无法解决“变量死锁”——这个问题要靠 synchronized、ReentrantLock、volatile 或者并发工具类（如 AtomicInteger、StampedLock）来处理。

接下来，重点聊聊如何用 requires 在实际项目中落实单向依赖原则，以及常见的误区和规避思路。

用 requires 确保模块依赖方向不可逆

单向依赖的核心含义是：A 依赖 B 可以，但 B 绝对不能反过来依赖 A，否则就形成了循环依赖，破坏模块的内聚性。JPMS 在编译和启动阶段会自动检测这种情况并报错，机制很严格。

• 模块 A 的 module-info.ja va：

  module com.example.service {    requires com.example.model; // ✅ 允许：service 依赖 model    exports com.example.service.api;}

• 模块 B（即 com.example.model）的 module-info.ja va：

  module com.example.model {    // ❌ 不应写：requires com.example.service    // 否则编译时 ja vac 会报错：circular dependency detected    exports com.example.model.data;}

只要某个模块反向声明了 requires，ja vac 编译或者 ja va --module-path 启动时就会直接报错。这个机制，从根源上杜绝了双向或循环依赖的可能性。

避免隐式传递依赖破坏单向性

requires transitive 虽然用起来方便，但容易在不知不觉中引入反向可见性，破坏依赖的单向性。举个例子：

• com.example.core 模块声明：

  module com.example.core {    requires transitive com.example.logging; // 日志模块对下游透明可见}

• 如果 com.example.logging 内部又声明了 requires com.example.core，哪怕只是测试代码或配置失误，也会直接导致循环依赖报错。

✅ 正确的做法是：requires transitive 只用于稳定、无业务逻辑的基础设施模块，比如日志库、JSON 序列化工具。而且，这些模块本身必须是不依赖上游业务组件的纯工具模块。建议定期使用 jdeps --multi-release 25 --check 验证模块依赖图是否包含环形结构。

单向依赖落地检查清单

• 每个 requires 声明，只能出现在高层模块依赖低层模块的位置，比如 service 层依赖 model 层，web 层依赖 service 层；
• 绝对禁止在 domain 或 model 层模块中 requires 任何 application 或 service 层模块；
• 所有跨模块调用必须通过 exports 显式开放的包进行，未导出的包对调用方不可见（反射也不允许）；
• 构建阶段可以加上 --validate-modules 参数，让 JVM 在启动时校验依赖图的完整性。

关于“变量死锁”的澄清与建议

如果你实际遇到的是模块初始化顺序导致的静态字段相互等待（比如 Class A 的 static 块依赖 Class B 的 static 字段，而 B 又反过来依赖 A），这属于类加载死锁，不是通常意义上的变量死锁，但同样需要警惕：

• ✅ 规避方式：

  • 避免在 static 块中触发其他模块类的主动加载和初始化；
  • 把模块间的协作逻辑延迟到实例方法中处理，不要依赖静态入口；
  • 使用 ServiceLoader 或依赖注入容器来解耦初始化时机。

• ❌ 不要指望 requires 能控制类加载顺序——它不介入类加载的执行顺序，只约束模块之间的可见性关系。

这个点听起来可能有点绕，但只要理清了模块可见性与并发控制的边界，就不会混淆了。