4、服务发现
现在两个服务提供方都实现了接口，下面关键的一步就是服务发现，这一步 java 中的 spi 发现机制已经帮我们实现好了。
创建一个新项目aircondition-app，引入上面打好的两个 jar 包。
<dependencies> <dependency> <groupId>com.cn.hydra</groupId> <artifactId>aircondition-hanging-type</artifactId> <version>1.0-SNAPSHOT</version> </dependency> <dependency> <groupId>com.cn.hydra</groupId> <artifactId>aircondition-vertical-type</artifactId> <version>1.0-SNAPSHOT</version> </dependency> </dependencies>
按照上面的说法，虽然每个服务提供者对于接口都有不同的实现，但是作为调用者来说，它并不需要关心具体的实现类，我们要做的是通过接口来调用服务提供者实现的方法。
下面，就是关键的服务发现环节，我们写一个方法，根据型号去调用对应空调的开关方法。
public class AirconditionApp { public static void main(String[] args) { new AirconditionApp().turnOn("VerticalType"); } public void turnOn(String type){ ServiceLoader<IAircondition> load = ServiceLoader .load(IAircondition.class); for (IAircondition iAircondition : load) { System.out.println("检测到:"+iAircondition.getClass().getSimpleName()); if (type.equals(iAircondition.getType())){ iAircondition.turnOnOff(); } } } }
测试结果：
可以看到，测试过程中，通过定义的接口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，就可以使用具体功能。
<dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>2.0.3</version> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> <version>2.0.3</version> </dependency>
引入项目后，点开它的 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 提供了一种比较特别的服务发现和调用机制，通过接口灵活的将服务调用与服务提供者分离，用于提供给第三方实现扩展时还是很方便的。但是也有缺点，比方说一旦加载一个接口，就会把所有实现类都加载进来，可能会加载到不需要的冗余服务。不过站在整体角度上，还是给我们提供了一种非常不错的框架扩展、集成的思路。
