serviceloader是jdk原生spi机制，通过meta-inf/services/下接口全限定名配置文件加载实现类，懒加载、无参构造、不支持依赖注入，与spring完全隔离，适用于简单插件场景。
ServiceLoader 本身不能直接和 Spring 容器协同工作，它完全独立于 Spring 生命周期与依赖注入机制；想在 Spring 之外实现可插拔数据库连接池适配引擎，关键不是“怎么集成 Spring”，而是“如何用纯 JDK SPI 控制加载时机、隔离类加载、规避构造限制”。
ServiceLoader.load() 调用后并不立即加载类
很多人误以为 ServiceLoader.load(DataSourceAdapter.class) 会立刻触发类加载和实例化，实际不是。它只初始化一个 LazyIterator，真正加载发生在首次调用 iterator().hasNext() 或 next() 时。
- 这意味着你可以在启动阶段预加载所有候选实现，但延迟到第一次获取连接池时才实例化——适合冷启动优化
- 如果某个实现类依赖未就绪的 native 库或配置文件，
NoClassDefFoundError或ExceptionInInitializerError会在next()时抛出，而不是load()时，调试需注意堆栈位置 - 不要在静态块里做重操作（如读取配置、初始化线程池），否则失败不可恢复；建议把初始化逻辑移到
init(Map<string object> config)</string>方法中，由调用方显式触发
META-INF/services/ 下的配置文件必须严格符合格式
文件路径必须是 META-INF/services/com.example.DataSourceAdapter（接口全限定名），内容每行仅一个实现类名，且不能有空格、注释、空行。
- 常见错误：IDE 自动生成的文件末尾带 BOM 或换行符，Linux 下用
cat -A filename查看是否含^M或^@ - 多个 jar 包提供同名配置文件时，
ClassLoader.getResources("META-INF/services/com.example.DataSourceAdapter")返回的是按 classpath 顺序排列的 URL 列表，**只取第一个匹配项里的全部行**，后续 jar 中同名文件被忽略——没有合并逻辑 - 本地测试时看到 HikariCP 实现，上线后因依赖顺序变化加载了 Druid 实现，行为突变却无日志提示，这是最隐蔽的线上问题之一
实现类必须有 public 无参构造器，且不能依赖 Spring Bean
ServiceLoader 内部用 Class.newInstance()（Java 9+ 改为 Constructor.newInstance()）创建实例，不支持传参，也不走任何容器管理流程。
- 如果你的
HikariDataSourceAdapter需要Logger或MetricsRegistry，不能靠@Autowired，也不能继承InitializingBean；必须自己在init()中查SLF4J或通过ThreadLocal注入上下文 - 避免在构造器中初始化连接池（如调
hikariConfig.setJdbcUrl(...)），因为此时外部配置尚未传入；应把连接池对象声明为volatile DataSource dataSource，延迟到init(config)中构建 - 若需多实例（如不同库用不同连接池），别复用单个
ServiceLoader实例；每次调用ServiceLoader.load(...)都会新建迭代器，但类加载仍共享 JVM 类缓存——注意类卸载风险
如何安全地切换和验证适配器实现
不能靠 try-catch 捕获“找不到实现”的异常来兜底，因为 ServiceLoader.iterator() 返回空迭代器时不会报错，只会静默失败。
- 启动时主动校验：调用
serviceLoader.iterator().hasNext()，为 false 就立刻System.err.println("No DataSourceAdapter found — check META-INF/services/")并退出 - 每个实现类应在
toString()或getVersion()方法中返回明确标识（如"HikariCP v5.0.1"），便于日志追踪实际加载的是哪个版本 - 不要在 hot path（如每次 getConnection()）反复调用
ServiceLoader.load()；应缓存ServiceLoader实例或提前收集所有DataSourceAdapter实例到List中 - 若需运行时热插拔（如动态加载新 jar），必须用自定义
ClassLoader加载，且确保旧类能被 GC —— 这已超出ServiceLoader原生能力，需配合 OSGi 或模块系统
最常被忽略的一点：ServiceLoader 不校验接口方法签名兼容性。假如你在新版本里给 DataSourceAdapter 加了个 setValidationQuery(String)，而老实现没重写，编译期不报错，运行期调用时才抛 NoSuchMethodError。接口演进必须严格遵循语义版本规则，并在文档中标明“SPI 实现必须兼容 X.Y 版本”。
