ServiceLoader-SPI和类SPI机制的场景应用
1.SPI-ServiceLoader
1.1简介
原文："A simple service-provider loading facility."
解释：可以加载指定接口的实现类，最初主要用于加载厂商的实现类或插件使用。工程所依赖的jar包中在指定目录下添加实现类说明后，也可以被装载到JVM中；
理解：JDK内置的一种动态服务提供发现机制，运行时会装载具体的配置；除了spring之外，给我们提供一种原生的类装载和实例化的方式；
1.2简要代码实现与使用场景例举
JDK中的主方法代码实现：
public final class ServiceLoader<S>
implements Iterable<S>
{
//指定加载目录，JDK定死，也没必要改
private static final String PREFIX = "META-INF/services/";
//本地缓存实现类，key是全路径实现类名，value是newInstance出来的实例，同名会以最后一个为准
private LinkedHashMap<String,S> providers = new LinkedHashMap<>();
........
//加载入口，每次都认为是一次reload，所以先清空原来的
public void reload() {
providers.clear();
//被遍历时才进行实际的实例化和装载动作
lookupIterator = new LazyIterator(service, loader);
}
private ServiceLoader(Class<S> svc, ClassLoader cl) {
service = Objects.requireNonNull(svc, "Service interface cannot be null");
loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;
acc = (System.getSecurityManager() != null) ? AccessController.getContext() : null;
reload();
}
........
}
private class LazyIterator
implements Iterator<S>
{
......
private S nextService() {
if (!hasNextService())
throw new NoSuchElementException();
String cn = nextName;
nextName = null;
Class<?> c = null;
try {
c = Class.forName(cn, false, loader);
} catch (ClassNotFoundException x) {
fail(service,
"Provider " + cn + " not found");
}
if (!service.isAssignableFrom(c)) {
fail(service,
"Provider " + cn + " not a subtype");
}
try {
S p = service.cast(c.newInstance());
providers.put(cn, p);
return p;
} catch (Throwable x) {
fail(service,
"Provider " + cn + " could not be instantiated",
x);
}
throw new Error(); // This cannot happen
}
...........
}
ehcache中的使用：
Sentinel流量哨兵中的使用：
JDK中数据库Driver初始化中的使用：
2.类SPI实现：SpringBoot-autoconfigure
2.1 简介
SpringMVC和Springboot在META-INF目录中都提供了spring.factories配置文件，与上述JDK中使用的SPI方式基本一致，只是对具体文件名和内容作了自己的解析和加载逻辑；
以spring-boot-autoconfigure-2.0.0.Release版本为例，配置文件中的那内容大概如下：
主要都是在对@EnableAutoConfiguration进行各类支持，以HttpMessageConvertersAutoConfiguration这个类为例，springboot在容器启动时，已经自动帮我们把一些常用的Converter装载进来，如有Jackson，json-b，gjson的参数解析和绑定：
2.2 加载入口：SpringFactoriesLoader
可以看出其加载的类缓存在了变量cache中，它是一个多层嵌套的KKV结构，value是一个List<String>，正好对应spring.factories中的内容。
springboot项目启动时，会先使用此类寻找供初始化实现类并初始化：
根据这个特性，我们也可以把自定义的一些configuration通过配置EnableAutoConfiguration的实现来触发启动加载。springboot的各类starter包，也是通过这种方式进行快速接入和使用的；
3.类SPI实现：Dubbo-ExtensionLoader
JDK的SPI，新建接口，然后定义不同实现，然后/META-INF/services定义定义接口的全路径的文件，文件中写上接口的全部实现类，最后代码通过ServiceLoader加载，循环迭代得到所有实现类。标准SPI迭代时会加载所有实现，所以只希望加载某个的，就不现实了。
Dubbo的扩展SPI：
- 单例，对于某个扩展，只会有一个ExtensionLoader；
- 延迟加载，可以一次只获取想要的扩展点，一次获取想要的扩展点实现；
- 对于扩展点的Ioc和Aop，就是一个扩展可以注入到另一个扩展中，也可以对一个扩展做wrap包装实现aop的功能；
- 对于扩展点的调用，真正调用的时候才能确认具体使用的是那个实现。
从以上全局变量中也可以大概看出上述的dubbo-SPI的一些特性；
如果对dubbo源码感兴趣可前往此处进行快速了解。
