Java ServiceLoader 如何隔离实现发现：模块路径、迭代器与故障边界

插件式报表服务上线后，最难查的往往不是接口本身，而是“为什么实现没有被发现”或“遍历到某个实现时突然失败”。Java 的 ServiceLoader 把发现动作交给运行时，但模块声明、服务配置和实例化时机必须同时对上。

把服务接口放在稳定的 API 模块，消费方声明 uses，实现方声明 provides ... with ...；需要先筛选提供者时用 stream() 查看 Provider.type，确认选中后再调用 Provider.get。

ServiceLoader 解决的是哪一段耦合

假设主程序只认识 Formatter，CSV 和 JSON 格式化器由独立模块提供。直接写 new JsonFormatter() 会把消费方绑定到实现类；服务机制把绑定点移到运行时发现。

public interface Formatter {
    String format(String input);
}

ServiceLoader loader = ServiceLoader.load(Formatter.class);
for (Formatter formatter : loader) {
    System.out.println(formatter.format("order-17"));
}

这里的 ServiceLoader.load 得到的是可遍历对象。它可以找到零个、一个或多个提供者；“找到”与“成功创建实例”不是同一个时刻。

模块路径上要同时写对 uses 和 provides

命名模块中，消费方在 module-info.java 写出服务需求，实现方写出服务供给。服务接口必须对消费方可访问，实现类不必暴露成消费方的直接依赖。

// app/module-info.java
module report.app {
    uses demo.format.Formatter;
}

// json-provider/module-info.java
module report.json {
    requires report.api;
    provides demo.format.Formatter with demo.json.JsonFormatter;
}

启动时把这些模块放在同一个模块路径中。若只把实现 JAR 放在普通类路径、却没有服务配置，消费方会得到空的提供者集合；若 uses 漏写，模块系统也不会按预期完成服务发现。

为什么 stream 比直接遍历更适合做实现筛选

当系统里有多个 Formatter 时，可以先看提供者类型，再创建真正选中的实现。stream() 的元素是 ServiceLoader.Provider，Provider.type 不会提前调用构造器。

ServiceLoader loader = ServiceLoader.load(Formatter.class);
Optional> jsonProvider = loader.stream()
    .filter(provider -> provider.type().getName().equals("demo.json.JsonFormatter"))
    .findFirst();

Formatter formatter = jsonProvider
    .map(ServiceLoader.Provider::get)
    .orElseThrow(() -> new IllegalStateException("JsonFormatter 未找到"));

这段代码的关键不是把流写得更短，而是把“筛选类型”和“创建对象”拆开。提供者的构造器、工厂方法或依赖缺失，通常会在 Provider.get 处暴露。

迭代器失败时怎样保留可诊断性

ServiceLoader 的迭代是惰性的。某个实现类名写错、构造器不可用、工厂方法抛错时，错误可能在 hasNext 或 next 的过程中出现，而不是发生在 load 调用处。

List available = new ArrayList();
Iterator iterator = ServiceLoader.load(Formatter.class).iterator();
while (true) {
    try {
        if (!iterator.hasNext()) {
            break;
        }
        available.add(iterator.next());
    } catch (ServiceConfigurationError error) {
        System.err.println("formatter provider failed: " + error.getCause());
        break;
    }
}

示例选择在首个坏实现处停止，并保留已经成功加载的列表。批处理工具也可以记录失败实现后继续，但前提是业务允许缺少某一种格式；不能把所有 ServiceConfigurationError 都当成可忽略告警。

常见误区与回归检查

• 把 ServiceLoader.load 当成“已经创建全部对象”，导致启动耗时和异常位置判断错误。
• 只改实现类名，不检查模块路径或 META-INF/services 文件，结果始终找不到提供者。
• 用 Provider.type 直接强转实例；真正的对象必须来自 Provider.get。
• 为了让启动成功而吞掉所有 ServiceConfigurationError，使实际缺失能力直到业务请求才暴露。

回归时至少覆盖三种状态：没有提供者时的空结果、筛选到目标类型后的成功实例化、一个提供者配置错误时的日志和停止策略。

相关问题

ServiceLoader.load 会马上调用提供者构造器吗？

不会。直接迭代时实例化通常发生在迭代推进阶段，使用 stream() 时可以先通过 Provider.type 筛选，调用 Provider.get 才明确请求实例。

模块化应用还需要 META-INF/services 文件吗？

命名模块优先使用 uses 和 provides。类路径或未命名模块场景仍应检查 META-INF/services 配置文件。

一个坏提供者会影响其他实现吗？

它至少会影响当前迭代路径。能否跳过取决于业务容错；建议记录异常原因，并明确是停止装载还是保留已成功实例。

小结

ServiceLoader 的边界可以用三句话记住：模块声明负责让实现可发现，迭代器负责按需推进，Provider.get 负责把类型变成实例。把这三步拆开后，空结果、延迟异常和坏实现就都有了明确的排查位置。