如何应用 requires 声明实战强制执行模块间的单向依赖原则并规避变量死锁
requires声明用于强制模块间单向静态依赖,从编译期阻断循环依赖,但无法解决变量死锁等运行时并发问题,后者需通过synchronized、Lock等机制处理。该声明只约束模块静态结构,不涉及线程同步,运行时并发问题需另行解决。
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能控制类加载顺序——它不介入类加载的执行顺序,只约束模块之间的可见性关系。
这个点听起来可能有点绕,但只要理清了模块可见性与并发控制的边界,就不会混淆了。


































