Java中的SPI动态扩展（下）

4、服务发现

现在两个服务提供方都实现了接口，下面关键的一步就是服务发现，这一步java中的spi发现机制已经帮我们实现好了。

创建一个新项目aircondition-app，引入上面打好的两个jar包。

<dependencies>
    <dependency>
        <groupId>com.cn.hydra<span class="hljs-name"groupId>
        <artifactId>aircondition-hanging-type<span class="hljs-name"artifactId>
        <version>1.0-SNAPSHOT<span class="hljs-name"version>
    <span class="hljs-name"dependency>

    <dependency>
        <groupId>com.cn.hydra<span class="hljs-name"groupId>
        <artifactId>aircondition-vertical-type<span class="hljs-name"artifactId>
        <version>1.0-SNAPSHOT<span class="hljs-name"version>
    <span class="hljs-name"dependency>
<span class="hljs-name"dependencies>

按照上面的说法，虽然每个服务提供者对于接口都有不同的实现，但是作为调用者来说，它并不需要关心具体的实现类，我们要做的是通过接口来调用服务提供者实现的方法。

下面，就是关键的服务发现环节，我们写一个方法，根据型号去调用对应空调的开关方法。

public class AirconditionApp {
    public static void main(String[] args) {
        new AirconditionApp().turnOn("VerticalType");
    }

    public void turnOn(String type){
        ServiceLoader

测试结果：

可以看到，测试过程中，通过定义的接口IAircondition发现了两个实现类，并通过参数，调用了特定实现类的某个方法。整段代码中没有出现过具体的服务实现类，操作都是通过接口调用。

5、原理

了解了spi的工作流程，我们再来看看它的实现，其实最关键的就是上面代码中出现的ServiceLoader这个类。

上面的示例代码中，对于ServiceLoader的load()方法的结果，我们用for循环进行了遍历，这一点我们看一下源码就能明白，因为ServiceLoader实现了Iterable这一接口，而整个服务发现的核心，就在它的iterator()方法中。

注意这里面有两个关键的东西，找一下在源码中定义的地方：

注释写的非常明白，providers就是一个缓存，在迭代器中如果先从这里面进行查找，如果里面有就继续往下找，没有了的话就用这个懒加载的lookupIterator查找。

那么就简单了，接着往下看LazyIterator，看看它里面的hasNext()和next()两个方法是怎么实现的。

这个acc是一个安全管理器，在前面通过System.getSecurityManager()判断并赋值，debug看一下这里都是null，所以直接看hasNextService()和nextService()方法就可以了。

在hasNextService()方法中，会取出接口取出实现类的类名放到nextName中：

接下来，在nextService()方法中，则会先加载这个实现类，然后实例化对象，最终放入缓存中去。

在迭代器的迭代过程中，会完成所有实现类的实例化，其实归根结底，还是基于java反射去实现的。

6、应用

要说spi的实际应用，大家最常见的应该就是日志框架slf4j了，它利用spi实现了插槽式接入其他具体的日志框架。

说白了，slf4j本身就是个日志门面，并不提供具体的实现，需要绑定其他具体实现才能真正的引入日志功能。

例如我们可使用log4j2作为具体的绑定器，只需要在pom中引入slf4j-log4j12，就可以使用具体功能。

org.slf4j
    slf4j-api
    2.0.3


    org.slf4j
    slf4j-log4j12
    2.0.3

引入项目后，点开它的jar包看一下具体结构：

有没有发现一个彩蛋，先说为什么我们pom中引入的明明是slf4j-log4j12，实际上引入的是slf4j-reload4j？翻一下官网的文档：

大意就是在2015年和2022年，log4j1.x就已经宣布end of life终止了，原因也不难猜，估计是因为频繁爆出的漏洞。在那之后，slf4j-log4j在构建阶段就会自动重定向到slf4j-reload4j了，并且官方也强烈建议使用slf4j-reload4j作为替代。

再回头看一下jar包的META-INF.services里面，通过spi注入了Reload4jServiceProvider这个实现类，它实现了SLF4JServiceProvider这一接口，在它的初始化方法initialize()中，会完成初始化等工作，后续可以继续获取到LoggerFactory和Logger等具体日志对象。

7、总结

Java中的SPI提供了一种比较特别的服务发现和调用机制，通过接口灵活的将服务调用与服务提供者分离，用于提供给第三方实现扩展时还是很方便的。但是也有缺点，比方说一旦加载一个接口，就会把所有实现类都加载进来，可能会加载到不需要的冗余服务。不过站在整体角度上，还是给我们提供了一种非常不错的框架扩展、集成的思路。