摘要
系统里抽象的各个模块，往往有很多不同的实现方案，比如日志模块的方案，xml解析模块、jdbc模块的方案等。面向的对象的设计里，我们一般推荐模块之间基于接口编程，模块之间不对实现类进行硬编码。一旦代码里涉及具体的实现类，就违反了可拔插的原则，如果需要替换一种实现，就需要修改代码。
为了实现在模块装配的时候能不在程序里动态指明，这就需要一种服务发现机制。java spi就是提供这样的一个机制：为某个接口寻找服务实现的机制。有点类似IOC的思想，就是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要。
什么是SPI
这里先说下SPI的一个概念，SPI英文为Service Provider Interface单从字面可以理解为Service提供者接口，也试试开发者只关心服务提供者接口，无需关心具体实现。服务调用方只关注接口即可。
很多框架都使用了java的SPI机制，如JDBC4中的java.sql.Driver的SPI实现(mysql驱动、oracle驱动等)、common-logging的日志接口实现、dubbo的扩展实现等等框架；
如何编写SPI
当服务的提供者，提供了服务接口的一种实现之后，在jar包的META-INF/services/目录里同时创建一个以服务接口命名的文件。该文件内容就是实现该服务接口的具体实现类。
而当外部程序装配这个模块的时候，就能通过该jar包META-INF/services/里的配置文件找到具体的实现类名，并装载实例化，完成模块的注入。
基于这样一个约定就能很好的找到服务接口的实现类，而不需要再代码里指定。
JDK提供服务实现查找的一个工具类：java.util.ServiceLoader，服务的发现和加载都是通过这个类来调用。
SPI使用Demo
首先创建一个接口类Fruitt·和两个实现类Banana和Apple`，如下：
Fruit.java
package com.spi;
/**
* @Created by IntelliJ IDEA.
* @Author tk
* @Date 2018/8/30
* @Time 上午10:55
*/
public interface Fruit {
void sayHello();
}
Apple.java
package com.spi;
/**
* @Created by IntelliJ IDEA.
* @Author tk
* @Date 2018/8/30
* @Time 上午10:56
*/
public class Apple implements Fruit {
@Override
public void sayHello() {
System.out.println("Hello Apple");
}
}
Banana.java
package com.spi;
/**
* @Created by IntelliJ IDEA.
* @Author tk
* @Date 2018/8/30
* @Time 上午10:56
*/
public class Banana implements Fruit {
@Override
public void sayHello() {
System.out.println("Hello Banana");
}
}
然后在resource目录下创建目录/META-INF/services，这里要严格按照这个结构创建，具体原因后面说明，然后按照Fruit接口的包路径创建文件com.spi.Fruit，文件内容为具体实现类的全路径，例如：
com.spi.Banana
新建测试文件，通过ServiceLoader加载接口类，通过这样的方式调用具体的实现方法，代码如下：
FruitTest.java
package com.spi;
import java.util.Iterator;
import java.util.ServiceLoader;
/**
* @Created by IntelliJ IDEA.
* @Author tk
* @Date 2018/8/30
* @Time 上午10:59
*/
public class FruitTest {
public static void main(String[] args) {
ServiceLoader<Fruit> s = ServiceLoader.load(Fruit.class);
Iterator<Fruit> iterator = s.iterator();
while (iterator.hasNext()) {
Fruit fruit = iterator.next();
fruit.sayHello();
}
}
}
这里通过ServiceLoader.Load()方法加载接口类Fruit.class，然后通过迭代的方式获取到具体实例化了的实现类，最后调用sayHello实现类的方法
输入结果：
Hello Banana
从打印结果来看，是调用的Banana类的sayHello()方法，与com.spi.Fruit中配置的实现类一致，通过这样方式可以把调用方和实现方在程序中结构，只需要关注接口类即可。
源码分析
首先，ServiceLoader实现了Iterable接口，所以他有迭代器的属性，实现了迭代器的hasNext和next方法
public Iterator<S> iterator() {
return new Iterator<S>() {
Iterator<Map.Entry<String,S>> knownProviders
= providers.entrySet().iterator();
public boolean hasNext() {
if (knownProviders.hasNext())
return true;
return lookupIterator.hasNext();
}
public S next() {
if (knownProviders.hasNext())
return knownProviders.next().getValue();
//通过lookupIterator操作
return lookupIterator.next();
}
public void remove() {
throw new UnsupportedOperationException();
}
};
}
不难看出，这里主要都是调用的lookupIterator的相应hasNext和next方法，lookupIterator是什么我们可以从load函数分析
public static <S> ServiceLoader<S> load(Class<S> service) {
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);
}
从load函数的实现看出，实际是返回的 ServiceLoader的实例化对象，ServiceLoader构造函数中又创建了lookupIterator对象，如下：
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();
}
这里主要看下LazyIterator最关键的两个函数
private boolean hasNextService() {
if (nextName != null) {
return true;
}
if (configs == null) {
try {
String fullName = PREFIX + service.getName();
if (loader == null)
configs = ClassLoader.getSystemResources(fullName);
else
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 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
}
这里的fullName就是要加在类的全路径名，静态变量PREFIX就是"META-INF/services/"目录，这也就明白了威慑么要在META-INF/services下创建com.spi.Fruit文件
方法hasNextService主要是判断是否有配置实现类以及复制实现类给nextName，而nextService函数主要通过加载实现类c = Class.forName(cn, false, loader)以及实例化实现类p = service.cast(c.newInstance())，来返回具体的实现类对象，这样再上文测试代码中就能够获取到配置的实现类的实例。
总结一下，通过spi模式能够将接口和实现类灵活的配置，调用方逻辑中无需关心具体实现类是什么，只需要面向接口编程即可。
