一言不合就贴概念:

SPI 全称为 (Service Provider Interface) ,是JDK内置的一种服务提供发现机制。 目前有不少框架用它来做服务的扩展发现， 简单来说，它就是一种动态替换发现的机制， 举个例子来说， 有个接口，想运行时动态的给它添加实现，你只需要添加一个实现

是不是说了这么多还不知道他究竟是干什么的？我也是。。

不过给我的理解是，我只需要接口就够了，实现类我不去管，也不需要new,有点类似于IOC的模式，至于适用场景嘛，大家可以自己YY一下。。

这时候就会有人问，有了SPI就不需要写实现类了吗？错。为什么呢，且听我一一道来。

 首先引用一张图

那么可以看得出，首先我们需要在Classpath中有一个叫META-INF/services的文件夹，至于为什么是这个，之后在源码中会体现出来，暂时卖个关子

第二步就是创建接口类。

比如我们弄一个叫DemoService的类。

 /**  * SPI Test  * @author Autorun  * Created by Autorun on 2018/1/26.  */ public interface DemoService {      void sayHello(); } 

第三步就是创建该service对应的实现类。

 /**  * SPI Test impl  * @author Autorun  * Created by Autorun on 2018/1/26.  */ public class DemoServiceImpl implements DemoService {     @Override     public void sayHello() {         System.out.println("hello SPI!!!!");     } } 

第四步：我们需要在 META-INF/services 中创建对应的映射文件(暂且叫映射文件吧)， 我觉得也比较形象

文件名称与接口类的全类名保持一致

我这里放到了 org.jdk.demo.java.util.spi.DemoService 这个下面，所以对应的文件名应该是 org.jdk.demo.java.util.spi.DemoService 

然后将实现类的路径配置到该文件中。

我这里对这个接口有2个实现类。那么可以写两个(原则上应该是可以写无数个的)

然后我们写一个对应的测试类，用于测试我们写的方法

/**  * @author Autorun  * Created by Autorun on 2018/1/26.  */ public class DemoServiceTest {      public static void main(String[] args) {         ServiceLoader<DemoService> services = ServiceLoader.load(DemoService.class);         Iterator<DemoService> it = services.iterator();         while (it.hasNext()) {             DemoService service = it.next();             service.sayHello();         }     } }

在这里。我们测试一下。

会发现。他把我们实现的方法全部都调用了一遍。通过迭代器中调用sayHello方法

先贴属性

我们看到了META-INF/services/ 所以，呵呵，知道为什么必须写在这个目录下了吧？

然后我们开始看看ServiceLoader.load(DemoService.class)这一步他到底做了什么，它是如何将我们的每一个实现类的方法执行起来的 

public static <S> ServiceLoader<S> load(Class<S> service) {         // 获取上下文的类加载器。然后调用重载的方法(ServiceClass, ClassLoader)         ClassLoader cl = Thread.currentThread().getContextClassLoader();         return ServiceLoader.load(service, cl);     }

public static <S> ServiceLoader<S> load(Class<S> service,                                             ClassLoader loader)     {         return new ServiceLoader<>(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();     }

可以看得出来，他初始化了ServiceLoader这个对象，并将类加载器和接口类赋值给私有变量并调用了reload方法。我们看看reload方法做了什么

public void reload() {         providers.clear();         lookupIterator = new LazyIterator(service, loader);     }

它又创建了一个内部类，叫lazyIterator，通过名字我们可以看得出他是一个迭代器对象的实现类。顺便说一嘴，这个类才是真正去调用SPI类的地方，我们从上面自己写的测试代码中应该就明白了。

废话不多说，继续贴代码。。

我们while中调用了hasNext方法。我们看看它内部做了什么

public boolean hasNext() {             if (acc == null) {                 return hasNextService();             } else {                 PrivilegedAction<Boolean> action = new PrivilegedAction<Boolean>() {                     public Boolean run() { return hasNextService(); }                 };                 return AccessController.doPrivileged(action, acc);             }         }

第一次进来的时候acc肯定是空的，因为没有看到有给它赋值的地方。

它调用了内部的hasNextService方法。

private boolean hasNextService() {             if (nextName != null) {                 return true;             }             if (configs == null) {                 try {                     // meta-inf/services/xxx.DemoService 全名称                     String fullName = PREFIX + service.getName();                     if (loader == null)                         configs = ClassLoader.getSystemResources(fullName);                     else                         // 实用类加载器加载classpath下的文件。                         configs = loader.getResources(fullName);                 } catch (IOException x) {                     fail(service, "Error locating configuration files", x);                 }             }             while ((pending == null) || !pending.hasNext()) {                 if (!configs.hasMoreElements()) {                     return false;                 }                 pending = parse(service, configs.nextElement());             }             nextName = pending.next();             return true;         }

// 解析文件细节 private Iterator<String> parse(Class<?> service, URL u)         throws ServiceConfigurationError     {         InputStream in = null;         BufferedReader r = null;         ArrayList<String> names = new ArrayList<>();         try {             in = u.openStream();             r = new BufferedReader(new InputStreamReader(in, "utf-8"));             int lc = 1;             while ((lc = parseLine(service, u, r, lc, names)) >= 0);         } catch (IOException x) {             fail(service, "Error reading configuration file", x);         } finally {             try {                 if (r != null) r.close();                 if (in != null) in.close();             } catch (IOException y) {                 fail(service, "Error closing configuration file", y);             }         }         return names.iterator();     }

继续看获取next游标的元素

public S next() {             if (acc == null) {                 return nextService();             } else {                 PrivilegedAction<S> action = new PrivilegedAction<S>() {                     public S run() { return nextService(); }                 };                 return AccessController.doPrivileged(action, acc);             }         }

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 中                 providers.put(cn, p);                 return p;             } catch (Throwable x) {                 fail(service,                      "Provider " + cn + " could not be instantiated",                      x);             }             throw new Error();          // This cannot happen         }

那么可以得出，他会把该文件中所有的行都读到，并且初始化，放入providers 的集合中。然后将该实例返回回去。

我们自行调用sayHello方法。那就执行了对应的实现类代码啦

说到这里，我们应该很清晰的对JDK自己提供的SPI机制有了详细的认知。那么，他有没有什么问题呢？

答案是肯定的，

1：懒加载，这个没毛病。但是只要一调用next方法，就会把所有的实现类都加载进来。对我们来讲是不科学的。这也不是我们需要的，因为在特定场合我们只需要指定的类就够了，而不需要那么多实现类。

2:内部缓存没对外开放，也可以理解，安全。那代价就是我们需要自己去将具体的实现类放入我们的容器中。

总结: 

其实他的SPI做了如下事情：

1.根据对应的接口类去找META-INF/services/下的接口类名

2:通过service获取对应的迭代器，调用hasNext方法去将META-INF/services/下对应全限定名文件中的类解析出来。

3:调用next方法加载类，并将其缓存到provides的map中。

并将其对应的实现类返回

小作业(留给有心的人): 自行实现一套SPI机制，实现根据指定类去加载对应的实现类。并将其缓存起来。

最后欢迎大家加入 JAVA那些事 77174608 一起成长进步。。