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
    implements Iterable
{
    //指定加载目录，JDK定死，也没必要改
    private static final String PREFIX = "META-INF/services/";

    //本地缓存实现类，key是全路径实现类名，value是newInstance出来的实例，同名会以最后一个为准
    private LinkedHashMap providers = new LinkedHashMap<>();

    ........
    
    //加载入口，每次都认为是一次reload，所以先清空原来的
    public void reload() {
            providers.clear();
            //被遍历时才进行实际的实例化和装载动作
            lookupIterator = new LazyIterator(service, loader);
        }

    private ServiceLoader(Class 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
    {
            ......
            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，正好对应spring.factories中的内容。
springboot项目启动时，会先使用此类寻找供初始化实现类并初始化：

根据这个特性，我们也可以把自定义的一些configuration通过配置EnableAutoConfiguration的实现来触发启动加载。springboot的各类starter包，也是通过这种方式进行快速接入和使用的；

3.类SPI实现：Dubbo-ExtensionLoader

JDK的SPI，新建接口，然后定义不同实现，然后/META-INF/services定义定义接口的全路径的文件，文件中写上接口的全部实现类，最后代码通过ServiceLoader加载，循环迭代得到所有实现类。标准SPI迭代时会加载所有实现，所以只希望加载某个的，就不现实了。
Dubbo的扩展SPI：

1. 单例，对于某个扩展，只会有一个ExtensionLoader；
2. 延迟加载，可以一次只获取想要的扩展点，一次获取想要的扩展点实现；
3. 对于扩展点的Ioc和Aop，就是一个扩展可以注入到另一个扩展中，也可以对一个扩展做wrap包装实现aop的功能；
4. 对于扩展点的调用，真正调用的时候才能确认具体使用的是那个实现。

从以上全局变量中也可以大概看出上述的dubbo-SPI的一些特性；
如果对dubbo源码感兴趣可前往此处进行快速了解。