目录
- 1 简介
- 缺点
- 源码
- 使用
- 适用场景
- 插件扩展
- 案例
1 简介
SPI，Service Provider Interface，一种服务发现机制。
有了SPI，即可实现服务接口与服务实现的解耦：
- 服务提供者（如 springboot starter）提供出 SPI 接口。身为服务提供者，在你无法形成绝对规范强制时，适度"放权" 比较明智，适当让客户端去自定义实现
- 客户端（普通的 springboot 项目）即可通过本地注册的形式，将实现类注册到服务端，轻松实现可插拔
缺点
- 不能按需加载。
- 虽然 ServiceLoader 做了延迟加载，但是只能通过遍历的方式全部获取。如果其中某些实现类很耗时，而且你也不需要加载它，那么就形成了资源浪费获取某个实现类的方式不够灵活，只能通过迭代器的形式获取
Dubbo SPI 实现方式对以上两点进行了业务优化。
源码
应用程序通过迭代器接口获取对象实例，这里首先会判断 providers 对象中是否有实例对象：
- 有实例，那么就返回
- 没有，执行类的装载步骤，具体类装载实现如下：
LazyIterator#hasNextService 读取 META-INF/services 下的配置文件，获得所有能被实例化的类的名称，并完成 SPI 配置文件的解析
LazyIterator#nextService 负责实例化 hasNextService() 读到的实现类，并将实例化后的对象存放到 providers 集合中缓存
使用
如某接口有3个实现类，那系统运行时，该接口到底选择哪个实现类呢？
这时就需要SPI，根据指定或默认配置，找到对应实现类，加载进来，然后使用该实现类实例。
如下系统运行时，加载配置，用实现A2实例化一个对象来提供服务：
再如，你要通过jar包给某个接口提供实现，就在自己jar包的META-INF/services/目录下放一个接口同名文件，指定接口的实现是自己这个jar包里的某类即可：
别人用这个接口，然后用你的jar包，就会在运行时通过你的jar包指定文件找到这个接口该用哪个实现类。这是JDK内置提供的功能。
我就不定义在 META-INF/services 下面行不行？就想定义在别的地方可以吗？
No！JDK 已经规定好配置路径，你若随便定义，类加载器可就不知道去哪里加载了
假设你有个工程P，有个接口A，A在P无实现类，系统运行时怎么给A选实现类呢?
可以自己搞个jar包，META-INF/services/，放上一个文件，文件名即接口名，接口A的实现类=com.javaedge.service.实现类A2。
让P来依赖你的jar包，等系统运行时，P跑起来了，对于接口A，就会扫描依赖的jar包，看看有没有META-INF/services文件夹：
有，再看看有无名为接口A的文件： 有，在里面查找指定的接口A的实现是你的jar包里的哪个类即可
适用场景
插件扩展
比如你开发了一个开源框架，若你想让别人自己写个插件，安排到你的开源框架里中，扩展功能时。
如JDBC。Java定义了一套JDBC的接口，但并未提供具体实现类，而是在不同云厂商提供的数据库实现包。
但项目运行时，要使用JDBC接口的哪些实现类呢?
一般要根据自己使用的数据库驱动jar包，比如我们最常用的MySQL，其mysql-jdbc-connector.jar 里面就有：
系统运行时碰到你使用JDBC的接口，就会在底层使用你引入的那个jar中提供的实现类。
案例
如sharding-jdbc 数据加密模块，本身支持 AES 和 MD5 两种加密方式。但若客户端不想用内置的两种加密，偏偏想用 RSA 算法呢？难道每加一种算法，sharding-jdbc 就要发个版本？
sharding-jdbc 可不会这么蠢，首先提供出 EncryptAlgorithm 加密算法接口，并引入 SPI 机制，做到服务接口与服务实现分离的效果。
客户端想要使用自定义加密算法，只需在客户端项目 META-INF/services 的路径下定义接口的全限定名称文件，并在文件内写上加密实现类的全限定名
这就显示了SPI的优点：
- 客户端（自己的项目）提供了服务端（sharding-jdbc）的接口自定义实现，但是与服务端状态分离，只有在客户端提供了自定义接口实现时才会加载，其它并没有关联；客户端的新增或删除实现类不会影响服务端
- 如果客户端不想要 RSA 算法，又想要使用内置的 AES 算法，那么可以随时删掉实现类，可扩展性强，插件化架构
到此这篇关于一文搞懂Java的SPI机制的文章就介绍到这了,更多相关Java的SPI机制内容请搜索自由互联以前的文章或继续浏览下面的相关文章希望大家以后多多支持自由互联！