ServiceLoader 无法真正延迟初始化，因其 load() 方法会立即扫描并实例化所有服务；需通过 Supplier.memoize 封装或手动类加载+延迟 newInstance 实现按需加载，并注意类加载器隔离与原生镜像配置。
ServiceLoader 本身不提供延迟初始化语义，它的 load() 方法一调用就立即扫描并实例化所有匹配服务，但你可以通过封装 + 懒加载包装器实现真正的“按需加载”
为什么直接用 ServiceLoader.load() 会破坏延迟目标
常见错误是把 ServiceLoader.load(DatabaseDriver.class) 放在静态字段或构造函数里——这会导致类加载时就触发全量扫描、反射实例化、甚至连接数据库。尤其当服务实现类含静态块或重量级初始化逻辑时，冷启动时间直线上升。
关键问题在于：ServiceLoader 的迭代器（Iterator）虽是惰性遍历，但 next() 一调就实例化；而 load() 调用本身已触发 META-INF/services/ 文件读取和类加载准备。
- 每次
serviceIterator.next()都调用Class.forName().getDeclaredConstructor().newInstance() - 没有缓存机制，重复调用
load()会重复扫描 JAR 清单 - 无法控制单个服务的初始化时机，更别说按条件筛选或 fallback
用 Lazy<serviceloader>></serviceloader> 封装是最小侵入方案
在 Java 8+ 环境中，可用 Lazy（如 Guava 的 Suppliers.memoize()）或自定义闭包延迟执行 ServiceLoader.load()，确保第一次真正需要服务列表时才触发扫描。
示例：
private static final Supplier<Stream<DatabaseDriver>> DRIVERS = Suppliers.memoize(() ->
StreamSupport.stream(ServiceLoader.load(DatabaseDriver.class).spliterator(), false)
);
public static Optional<DatabaseDriver> findDriver(String name) {
return DRIVERS.get()
.filter(d -> d.getDriverName().equalsIgnoreCase(name))
.findFirst();
}
这样，DRIVERS.get() 第一次调用才执行 ServiceLoader.load() 和文件 I/O；后续调用直接复用已构建的 Stream（注意：该 Stream 是一次性消费的，若需多次遍历，应转为 List 或重新封装）。
- 避免了类加载阶段的副作用
- 适用于模块启动时注册服务发现入口，但实际业务逻辑未触发前零开销
- 配合
Optional使用可自然表达“未找到”的语义，无需异常处理
更严格的按需实例化：只在真正调用时才 new 实例
如果连服务类的构造函数都代价高昂（比如初始化连接池），那就不能依赖 ServiceLoader 默认的即时实例化。你需要绕过它，自己控制类加载与构造时机。
做法是：用 ClassLoader.getResources() 手动读取 META-INF/services/com.example.spi.service.DatabaseDriver，解析出类名，再用 Class.forName(..., false, cl) 加载类（initialize = false），最后仅在 findDriver() 返回对象时才调用 constructor.newInstance()。
- 必须确保服务实现类有 public 无参构造函数（SPI 规范要求）
- 类加载阶段不触发静态块，真正实例化被推迟到业务代码显式调用
- 适合对启动耗时极度敏感的场景，如 Serverless 函数或 Quarkus 原生镜像环境
- 缺点是失去
ServiceLoader的线程安全迭代器保障，需自行同步或使用ConcurrentHashMap缓存已实例化的对象
容易忽略的 ClassLoader 隔离陷阱
在模块化环境（JPMS）或 OSGi 中，ServiceLoader.load(T.class) 默认使用当前线程上下文类加载器（Thread.currentThread().getContextClassLoader()）。如果模块 A 提供服务、模块 B 消费服务，但 B 的上下文类加载器看不到 A 的 JAR，则 load() 返回空迭代器——且不报错。
务必显式传入正确的类加载器：
ClassLoader driverCl = DatabaseDriver.class.getClassLoader(); ServiceLoader.load(DatabaseDriver.class, driverCl);
否则你会遇到“服务明明存在却找不到”的静默失败，排查时容易误判为配置路径写错或 SPI 文件没打包进去。
最麻烦的是混合环境：Spring Boot 应用里嵌套 Quarkus 模块，或 GraalVM 原生镜像中 ServiceLoader 被提前剪裁——这时光靠懒加载不够，必须配合 native-image 的 reflect-config.json 显式注册服务接口和实现类，否则运行时报 NoClassDefFoundError。
