4. ServiceLoader 加载过程源码分析：Provider 类、内部迭代器、缓存

4.1 概述

ServiceLoader 的加载过程围绕三个核心构件展开：Provider 接口封装服务提供者的类型与实例；LazyIterator 内部类实现真正的延迟加载逻辑；providers 缓存（LinkedHashMap）避免重复加载。三者协同完成从配置文件扫描到服务实例返回的完整链路。

本章直接进入 JDK 源码，逐段剖析每个构件的实现细节，并给出整体加载流程的可视化映射。学员可借此掌握 ServiceLoader 的内部运行机制，为后续的自定义 SPI 框架打下扎实基础。

4.2 Provider 接口源码分析

Provider 接口在 Java 9 中引入，定义在 java.util.ServiceLoader 内部，继承 Supplier<S>。

public final class ServiceLoader<S> implements Iterable<S> {

    // 嵌套接口 Provider
    public interface Provider<S> extends Supplier<S> {
        Class<? extends S> type();
        S get();
    }

    // 默认实现
    private class ProviderImpl<S> implements Provider<S> {
        private final Class<? extends S> type;
        private final S instance;

        ProviderImpl(Class<? extends S> type, S instance) {
            this.type = type;
            this.instance = instance;
        }

        @Override
        public Class<? extends S> type() {
            return type;
        }

        @Override
        public S get() {
            return instance;
        }
    }
}

设计意图：Provider 将“服务实现类的类型”与“服务实例”打包在一起。调用方可通过 type() 获取实现类的 Class 对象，而不必立即调用 get() 触发实例化。这种分离支持更细粒度的延迟决策——消费者可以先检查类型，再决定是否创建实例。

4.3 LazyIterator 内部迭代器源码分析

LazyIterator 是 ServiceLoader 的私有内部类，负责扫描 META-INF/services/ 下的配置文件，并延迟加载服务实现类。核心方法有两个：hasNextService() 和 nextService()。

4.3.1 hasNextService() 解析

private class LazyIterator implements Iterator<S> {
    Class<S> service;
    ClassLoader loader;
    Enumeration<URL> configs = null;
    Iterator<String> pending = null;
    String nextName = null;

    private boolean hasNextService() {
        if (nextName != null) {
            return true;
        }
        if (configs == null) {
            try {
                String fullName = "META-INF/services/" + service.getName();
                if (loader == null) {
                    configs = ClassLoader.getSystemResources(fullName);
                } else {
                    configs = loader.getResources(fullName);
                }
            } catch (IOException x) {
                fail(service, "Error locating configuration files", x);
            }
        }
        while ((pending == null) || !pending.hasNext()) {
            if (!configs.hasMoreElements()) {
                return false;
            }
            pending = parse(service, configs.nextElement());
        }
        nextName = pending.next();
        return true;
    }
}

执行流程：

1. 若 nextName 已缓存，直接返回 true，避免重复扫描。
2. 首次调用时通过 ClassLoader 获取所有 META-INF/services/<全限定接口名> 资源的 URL。
3. 逐条解析资源配置文件，将每行合法类名加入 pending 迭代器。
4. 取出下一个类名存入 nextName，返回 true；无剩余条目则返回 false。

4.3.2 nextService() 解析

private S nextService() {
    if (!hasNextService()) {
        throw new NoSuchElementException();
    }
    String cn = nextName;
    nextName = null;
    Class<?> c = null;
    try {
        c = Class.forName(cn, false, loader);
    } catch (ClassNotFoundException x) {
        fail(service, "Provider " + cn + " not found", x);
    }
    if (!service.isAssignableFrom(c)) {
        fail(service, "Provider " + cn + " not a subtype", x);
    }
    try {
        S p = service.cast(c.newInstance());
        providers.put(c.getName(), p);
        return p;
    } catch (InstantiationException | IllegalAccessException x) {
        fail(service, "Provider " + cn + " could not be instantiated", x);
    }
    return null; // unreachable
}

关键操作：

1. 调用 hasNextService() 确保 nextName 有值。
2. 使用 Class.forName(cn, false, loader) 延迟加载类（不执行静态块）。
3. 通过 service.isAssignableFrom(c) 检查类型兼容性。
4. 反射调用 newInstance() 创建实例，并立即存入 providers 缓存。

4.4 providers 缓存机制

缓存通过 LinkedHashMap<String, S> 实现，key 为服务实现类的全限定名，value 为已创建的实例。

// ServiceLoader 字段
private LinkedHashMap<String, S> providers = new LinkedHashMap<>();

缓存作用：

• 一旦某个实现类被 nextService() 加载并实例化，立即放入 providers。
• iterator() 返回的组合迭代器优先遍历 providers 中的条目，避免重复加载。
• LinkedHashMap 保持插入顺序，保证服务实例的返回顺序与配置文件中声明的顺序一致。

public Iterator<S> iterator() {
    return new Iterator<S>() {
        Iterator<Map.Entry<String, S>> knownProviders
            = providers.entrySet().iterator();

        public boolean hasNext() {
            if (knownProviders.hasNext()) {
                return true;
            }
            return lookupIterator.hasNext();
        }

        public S next() {
            if (knownProviders.hasNext()) {
                return knownProviders.next().getValue();
            }
            return lookupIterator.next();
        }
    };
}

双层读取策略：先检查 knownProviders（缓存），缓存耗尽后才委托 lookupIterator（LazyIterator）加载新服务。这种设计既保证了性能（缓存命中时零反射），又维持了懒加载语义。

4.5 加载流程总览

下图将上述三个构件串联为完整的加载流程。每个阶段标注了对应的核心类与方法，方便读者建立全景认知。

4.6 性能与稳定性优化

基于源码分析，可提炼以下优化要点：

4.7 常见错误与调试

• 配置缺失：META-INF/services/ 下未创建对应文件 → LazyIterator 的 configs.hasMoreElements() 返回 false，迭代器直接结束。调试时检查 classpath 或模块路径下的资源。
• 类名错误：配置文件中的类名拼写错误或全限定名不完整 → Class.forName() 抛出 ClassNotFoundException。使用 -Djava.util.logging.config.file 或开启 --add-opens java.base/java.util=ALL-UNNAMED 观察内部日志。
• 类型不兼容：配置的类未实现 SPI 接口 → isAssignableFrom 检查失败，抛出 ServiceConfigurationError。检查实现类的 extends/implements 声明。
• 并发加载：多线程共享同一 ServiceLoader 实例 → 迭代器内部状态被破坏。解决方案：每次迭代创建新的 ServiceLoader 实例，或在外部加 synchronized。