JavaServiceLoader详解：SPI服务加载核心类

Java的ServiceLoader是SPI机制的核心，但其动态发现能力常被误解：它仅依赖META-INF/services/下严格命名和格式的配置文件，不扫描类路径、不支持热加载、不提供实例移除功能，且在Java 9+模块系统中受requires/exports/provides等可见性规则深度约束；真正用好它，必须精准把控资源打包路径、类声明可见性、模块声明完整性，并摒弃对reload()的误用——理解这些底层限制，才是解决“找不到实现类”问题的关键。

ServiceLoader.load() 为什么总找不到实现类

根本原因不是代码写错了，而是 ServiceLoader.load() 只认 META-INF/services/ 下的配置文件，且文件名必须是接口全限定名，内容必须是实现类的全限定名（不能带空格、注释或多余换行）。常见错误包括：把配置文件放在 src/main/resources 但没打包进 jar；文件名写成 MyService 而不是 com.example.MyService；实现类没声明为 public；或者用了模块系统（Java 9+）却没在 module-info.java 中用 uses 声明依赖。

• 确认 jar 包里真有 META-INF/services/com.example.MyService，用 jar -tf your.jar | grep services 检查
• 配置文件内容只写一行：com.example.MyServiceImpl，末尾不要回车
• 如果用 Maven，确保 resources 目录被正确包含，且没有被 filtering 意外修改
• Java 9+ 模块中，服务提供方模块需在 module-info.java 写 provides com.example.MyService with com.example.MyServiceImpl;

ServiceLoader.reload() 的实际作用很有限

reload() 不会重新扫描 classpath 或检测新 jar，它只是清空当前已缓存的实例列表，下次 iterator() 时会重新加载——但加载逻辑和首次一样，仍走原来的类加载器和已加载的 jar。它对热替换、插件动态更新毫无帮助。真正想做到运行时发现新实现，得自己配合文件监听 + 自定义 ClassLoader + 手动调用 ServiceLoader.load(..., newClassLoader)。

• reload() 后再遍历，只会重新实例化已知的那些实现类，不会发现新加入的 jar
• 多次调用 load() 返回不同实例，但每个实例都来自同一个 ClassLoader，无法隔离
• 若需插件热加载，别依赖 reload()，改用 URLClassLoader 加载外部 jar，再传给 ServiceLoader.load(service, classLoader)

ServiceLoader.iterator() 返回的 Iterator 不支持 remove()

调用 iterator().remove() 会直接抛 UnsupportedOperationException。这不是 bug，是设计使然：SPI 是只读发现机制，不提供运行时剔除某实现的能力。想跳过某个实现？只能在遍历时手动判断过滤，或提前用 StreamSupport.stream() 转成流再 filter()。

• 以下写法会崩溃：loader.iterator().remove()
• 安全做法是收集后过滤：StreamSupport.stream(loader.spliterator(), false).filter(...).collect(...)
• 注意 iterator() 是懒加载，每次调用都可能触发新实例化，避免反复遍历

Java 9+ 模块系统下 ServiceLoader 行为变化明显

模块路径（--module-path）取代 classpath 后，ServiceLoader 默认只查当前模块和其 requires 的模块，不再自动扫描所有 jar。如果服务接口在模块 A，实现类在模块 B，但 A 没 requires B，那 load() 就看不到 B 的实现——哪怕 jar 就在模块路径里。

• 服务使用方模块（A）必须 requires 服务提供方模块（B），否则无法访问其实现类
• 服务提供方模块（B）必须在 module-info.java 显式 exports 实现类所在包，并 provides 接口
• 启动时若用 --class-path 混用传统 jar，模块系统会退化为 classpath 模式，但此时 ServiceLoader 可能漏掉模块路径里的实现

ServiceLoader 的核心约束始终没变：它只做静态发现，不管理生命周期，也不处理类加载隔离。最容易被忽略的是模块系统下的可见性规则——看似配置都对，实则败在 requires 缺失或 exports 不足。

理论要掌握，实操不能落！以上关于《JavaServiceLoader详解：SPI服务加载核心类》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！