如何通过 uses 关键字实战声明服务接口消费需求并掌握 ServiceLoader 的变量加载逻辑-java教程-PHP中文网

uses用于声明模块可能使用某服务接口，是被动提示而非主动加载；真正加载由ServiceLoader在运行时通过META-INF/services配置动态完成。

如何通过 uses 关键字实战声明服务接口消费需求并掌握 serviceloader 的变量加载逻辑

在 Java 模块系统（JPMS）中，uses 关键字不是用来“声明消费需求”的主动动作，而是模块描述符（module-info.java）中用于**声明本模块会使用某服务接口类型**的被动指示。它本身不触发加载，也不保证服务可用；真正负责发现、加载和实例化服务实现的是 ServiceLoader。掌握二者配合逻辑，关键在于理解「声明」与「加载」的分工：前者是编译期/运行期的契约提示，后者是运行时的动态查找机制。

uses 的真实作用：告诉模块系统“我依赖这个服务类型”

uses 出现在 module-info.java 中，仅表示当前模块在运行时**可能通过 ServiceLoader.load() 获取该接口的实现**。它不导入包，不强制依赖提供方模块，也不校验实现是否存在——只是为模块系统提供元信息，用于更精准的模块图分析（如 jlink、jdeps 工具可据此识别潜在服务依赖）。

写法示例：uses com.example.LogService; —— 表明本模块可能加载 LogService 接口的实现
注意：uses 后必须是接口（或抽象类），且该类型需在模块路径上可访问（通常通过 requires 引入其所在模块）
常见误区：以为写了 uses 就能自动注入或调用服务——实际仍需手动调用 ServiceLoader.load(MyService.class)

ServiceLoader 加载逻辑：按约定路径扫描 + 双亲委派式查找

ServiceLoader 的加载行为不依赖 uses，但二者常协同使用。其核心逻辑是：在类路径（ClassPath）或模块路径（ModulePath）下，查找 META-INF/services/全限定接口名 文件，并解析其中列出的实现类名进行实例化。

对于模块化环境：若服务接口定义在模块 A，实现类在模块 B，则模块 B 必须在 module-info.java 中用 provides com.example.Service with com.impl.ServiceImpl; 声明提供关系
加载时，ServiceLoader.load(Service.class) 会按以下顺序查找实现：
- 先查当前线程上下文类加载器（Context ClassLoader）能加载的 META-INF/services/... 文件
- 再查 Service.class 所在类加载器（通常是模块系统类加载器）对应的路径
- 模块路径下，还会检查提供方模块是否已导出（exports）实现类所在的包
每个 ServiceLoader 实例是懒加载的：调用 iterator() 或 stream() 时才真正读取配置、加载类、实例化对象

实战要点：声明、提供、加载三步缺一不可

一个完整的服务消费流程需要三方配合，uses 只是其中一环：

服务接口模块（API）：定义接口，导出包（exports com.example;），无需 uses
服务实现模块（Impl）：依赖 API 模块（requires），声明提供关系（provides ... with ...），并在 META-INF/services/ 下写实现类全名（模块化下该文件可省略，因 provides 已替代）
服务消费模块（App）：依赖 API 模块（requires），声明使用意图（uses com.example.Service;），并在代码中显式调用 ServiceLoader.load(Service.class) 获取实例