SPI机制

1. SPI机制概述

SPI（Service Provider Interface）是一种服务提供发现机制，主要由JDK内置实现，用于解耦接口和具体实现。
核心思想：将装配的控制权移到程序之外，允许框架或应用在运行时根据需要加载不同的实现。
模块解耦
- 在面向对象设计中，提倡模块之间基于接口编程。
- 调用方只依赖接口，不直接引用具体实现类，避免了硬编码问题。
可插拔与扩展
- SPI 允许在模块装配时动态选择具体实现，而无需修改调用代码。
- 实现替换非常简单，只需提供新实现并在外部配置中声明即可。
与 IOC 思想的异同
- 类似于控制反转（IOC）：将装配控制权移至外部。
- SPI 强调“为接口寻找服务实现”，使得服务提供者（Provider）与调用者（Consumer）之间实现松耦合。

定义标准（接口）
- 在调用方所在包中定义接口，如 java.sql.Driver
具体实现
- 不同厂商或开发者提供接口的具体实现，如文件搜索（FileSearch）或数据库搜索（DatabaseSearch）。
- 在相应的 JAR 包中，在 META-INF/services/ 目录下创建一个以服务接口全限定名命名的文件，文件内容为具体实现类的全限定名。
使用
- 应用使用 ServiceLoader.load(接口.class) 来加载所有实现，然后通过迭代器遍历使用。

JDBC驱动
- JDBC4.0后，数据库驱动通过SPI机制自动加载，无需显式调用 Class.forName()。
- 不同数据库（如 MySQL、PostgreSQL）通过各自 JAR 包中配置实现 java.sql.Driver 接口。
日志体系（Jakarta Commons Logging）
- 利用SPI机制，通过配置和查找资源，实现日志门面的具体实现解耦。
Spring Boot自动装配
- 利用 META-INF/spring.factories 文件，在所有 JAR 包中扫描并加载自动装配的实现类。
插件体系（如Eclipse）
- 通过OSGi框架实现插件的动态加载和卸载，同样遵循SPI思想。
ServiceLoader 机制
- JDK6 引入了 ServiceLoader，它会扫描 META-INF/services/ 目录中以接口全限定名命名的文件，加载对应的实现类。
- 例如：一个 Search 接口可以有多种实现（文件搜索、数据库搜索），只需在配置文件中列出具体的实现类。
Spring 自动装配与组件扫描
- 通过 component-scan 和注解（如 @Service、@Controller）来动态识别并加载实现，降低耦合。
Spring 扩展机制
- Spring 提供插件化扩展入口，如自定义 Scope、自定义标签和属性编辑器，框架通过预定义规则让用户提供具体实现，而不感知其内部细节。

SPI
- 定位：接口定义在调用方或框架中，而具体实现由外部（服务提供者）实现。
- 特点：
  - 实现位于独立的包或 JAR 中
  - 通过配置文件（例如 META-INF/services）指定实现
  - 支持动态发现和替换
  - 常用于插件模式或服务扩展机制。
API
- 定位：接口和它的实现都由实现方提供，作为整体对外使用。
- 特点：
  - 接口与实现通常打包在一起
  - 更倾向于直接使用，适用于较为固定的功能实现，不强调动态替换