当我们封装了一套接口，其它项目想要调用我们的接口只需要引入我们写好的包，但是其它项目如果想要对我们的接口进行扩展，由于接口是被封装在依赖包中的，想要扩展并不容易，这时就需要依赖于Java为我们提供的SPI机制。
SPI的全称是Service Provider Interface，服务提供者接口，而与之最接近的概念就是API，全称Application Programming Interface，应用程序编程接口。那么这两者主要的区别是什么呢？
API的调用方只能依赖使用提供方已有的实现，而SPI就是可定制化的API，调用方可以自定义实现替换API提供的默认实现。
SPI机制是非常重要的，尤其是对于框架来说，它可以用来启用框架扩展和替换组件，我们在读框架源码时也会看到大量的SPI的应用。
SPI的作用就是为这些被扩展的API寻找服务实现。
2 SPI 案例创建一个工程，一个做SPI的服务提供者，一个做SPI服务引入扩展的测试，此案例构建最简单的Maven子父工程即可，在spi-test工程引入spi-provider的依赖。
spi-test添加依赖
在spi-provider中，提供接口和一个默认的实现类
在资源文件中加上如下图文件，并在改文件中指定接口的默认实现类
spi-test中构建可执行的测试方法，直接执行，会拿到默认的实现
我们可以在spi-test中扩展，这个接口，如下图所示：
这时我们的扩展并不能生效，我们仍需要在资源文件下，为接口指定我们扩展的实现类，这时在运行上述测试方法即可得到我们扩展后的结果，这就是SPI机制。
3 SPI 的原理剖析ServiceLoader这个类包含了SPI的核心原理，从开头指定的路径前缀，我们就能猜到为什么我们必须将文件放入这个路径下才会生效。
通过load方法，创建一个ServiceLoader的对象，进入其构造方法，进行reload， 会创建一个新的LazyIterator迭代器，LazyIterator是一个内部类，它负责扫描META-INF/services/下的配置文件，并parse所有接口的名字，然后通过全限定类名通过反射进行实现类的加载。
从上面的源码中，我们不难发现ServiceLoader并没有额外的加锁机制，所以会存在并发问题，再就是获取对应的实现类不够灵活，需要使用迭代器的方式获取已知接口的所有具体实现类，所以每次都要加载和实例化所有的实现类，扩展如果依赖了其它的扩展，做不到自动注入和装配，扩展很难和其它框架集成。
也正是基于这种种原因，许多框架中不会去直接使用ServiceLoader这种原生的SPI机制而是会去基于这种思想进行一定的扩展，使其的功能更加强大，典型的案例就是dubbo的SPI，SpringBoot的SPI。
小编的这篇文章《SpringBoot借助spring.factories文件跨模块实例化Bean》就是讲SpringBoot中的SPI机制，感兴趣的同学可以阅读一下。
到此这篇关于Java中的SPI机制案例分享的文章就介绍到这了,更多相关Java中的SPI机制内容请搜索七叶笔记以前的文章或继续浏览下面的相关文章希望大家以后多多支持七叶笔记！
