Java SPI 机制解析
本文以JDBC为例深入讲解 java spi 机制，将帮助你理解：什么是SPI，SPI实现原理，SPI的使用和SPI的优劣。
什么是SPI
SPI，Service Provider Interface，主要用于框架设计。比如java.sql.Driver接口，不同厂商可以针对同一接口做出不同的实现，mysql和oracle都有不同的实现提供给用户，而Java的SPI机制可以为某个接口寻找服务实现。
当服务的提供者提供了一种接口的实现之后，需要在classpath下的META-INF/services/目录里创建一个以服务接口命名的文件，这个文件里的内容就是这个接口的具体的实现类。当其他的程序需要这个服务的时候，就可以通过查找这个jar包（一般都是以jar包做依赖）的META-INF/services/中的配置文件，配置文件中有接口的具体实现类名，可以根据这个类名进行加载实例化，就可以使用该服务了。例如mysql的jar包：
SPI实现原理
下面以JDBC为例深入讲解spi的实现原理：
在JDBC4.0之前，我们开发有连接数据库的时候，通常会用Class.forName("com.mysql.jdbc.Driver")这句先加载数据库相关的驱动，然后再进行获取连接等的操作。而JDBC4.0之后不需要用Class.forName("com.mysql.jdbc.Driver")来加载驱动，直接获取连接就可以了，现在这种方式就是使用了Java的SPI扩展机制来实现。
//1、加载驱动
//Class.forName("com.mysql.jdbc.Driver");
//2、建立连接
Connection connection = DriverManager.getConnection("url", "user", "passport");
//3、写prepareStatement
PreparedStatement preparedStatement = connection.prepareStatement("SELECT * from table where 1=1 limit 1 ");
//4、执行sql
ResultSet resultSet = preparedStatement.executeQuery();
1、进入到DriverManager
DriverManager中有一段静态代码块，用于初始化驱动。
/**
* Load the initial JDBC drivers by checking the System property
* jdbc.properties and then use the {@code ServiceLoader} mechanism
*/
static {
loadInitialDrivers();
println("JDBC DriverManager initialized");
}
为了能够更清晰的看到代码的功能，我们截取部分关键代码分析。
private static void loadInitialDrivers() {
//使用SPI的ServiceLoader来加载接口的实现
ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
//获取迭代器
Iterator driversIterator = loadedDrivers.iterator();
//遍历所有的驱动实现
try{
while(driversIterator.hasNext()) {
driversIterator.next();
}
} catch(Throwable t) {
// Do nothing
}
println("DriverManager.initialize: jdbc.drivers = " + drivers);
for (String aDriver : driversList) {
try {
println("DriverManager.Initialize: loading " + aDriver);
Class.forName(aDriver, true,
ClassLoader.getSystemClassLoader());
} catch (Exception ex) {
println("DriverManager.Initialize: load failed: " + ex);
}
}
}
2、进入到ServiceLoader，ServiceLoader是查找服务的实现工具
ServiceLoaderd定义了查找实现类的目录位置，和实现了Iterator的内部类LazyIterator。LazyIterator重写了hasNext和next方法，将类的加载延迟到了DriverManager调用的时候（也就是所谓的Lazy）。
DriverManager在遍历的时候，首先调用driversIterator.hasNext()方法，这里会搜索classpath下以及jar包中所有的META-INF/services目录下的java.sql.Driver文件，并找到文件中的实现类的名字，此时并没有实例化具体的实现类。然后是调用driversIterator.next();方法，此时就会根据驱动名字具体实例化各个实现类了。现在驱动就被找到并实例化了。
//查找配置文件的目录
private static final String PREFIX = "META-INF/services/";
// The class or interface representing the service being loaded
//表示要被加载的服务的类或接口
private Class<S> service;
// The class loader used to locate, load, and instantiate providers
private ClassLoader loader;
// Cached providers, in instantiation order
// 缓存已经被实例化的服务提供者，按照实例化的顺序存储
private LinkedHashMap<String,S> providers = new LinkedHashMap<>();
// The current lazy-lookup iterator
private LazyIterator lookupIterator;
//为指定的服务使用指定的类加载器来创建一个ServiceLoader，去加载实现了java.sql.Driver接口的类
public static <S> ServiceLoader<S> load(Class<S> service) {
ClassLoader cl = Thread.currentThread().getContextClassLoader();
return ServiceLoader.load(service, cl);
}
private ServiceLoader(Class<S> svc, ClassLoader cl) {
service = svc;
loader = cl;
reload();
}
//重新加载，就相当于重新创建ServiceLoader了，用于新的服务提供者安装到正在运行的Java虚拟机中的情况
public void reload() {
//清空缓存中所有已实例化的服务提供者
providers.clear();
//新建一个迭代器，该迭代器会从头查找和实例化服务提供者
lookupIterator = new LazyIterator(service, loader);
}
ServiceLoader不是实例化以后，就去读取配置文件中的具体实现，并进行实例化。而是等到使用迭代器去遍历的时候，才会加载对应的配置文件去解析，调用hasNext方法的时候会去加载配置文件进行解析，调用next方法的时候进行实例化并缓存。所有的配置文件只会加载一次，服务提供者也只会被实例化一次，重新加载配置文件可使用reload方法。
SPI的使用
SPI的使用可以仿照DriverManager的方式。如下：
ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(xxx.class);
//获取迭代器
Iterator<Driver> driversIterator = loadedDrivers.iterator();
//遍历
while(driversIterator.hasNext()) {
driversIterator.next();
//可以做具体的业务逻辑
}
SPI的缺点
通过上面的分析可以发现，SPI需要把所有的实现都实例化了，即便我们不需要，也都给实例化了。引用dubbo文档的说法是：
- JDK 标准的 SPI 会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，但如果没用上也加载，会很浪费资源。
- 如果扩展点加载失败，连扩展点的名称都拿不到了。比如：JDK 标准的 ScriptEngine，通过 getName() 获取脚本类型的名称，但如果 RubyScriptEngine 因为所依赖的 jruby.jar 不存在，导致 RubyScriptEngine 类加载失败，这个失败原因被吃掉了，和 ruby 对应不起来，当用户执行 ruby 脚本时，会报不支持 ruby，而不是真正失败的原因。
