以mysql驱动为案例，从源码角度深入分析Java的SPI机制

本文将以mysql驱动为案例，深入跟踪源码分析Java的SPI（Service Provider Interface）机制。

环境

java 8，mysql8.0，mysql-connector-java 8.0.20

代码

public class MysqlConnectorTest {public static void main(String[] args) {Connection conn = null;try {Class.forName("com.mysql.cj.jdbc.Driver");conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/xxx", "name", "password");// 业务代码} catch (Exception e) {e.printStackTrace();} finally {if (conn != null) {try {conn.close();} catch (SQLException e) {e.printStackTrace();}}}}
}

分析

在上述代码中，Class.forName("com.mysql.cj.jdbc.Driver");即使去掉依然可以成功运行，这正是因为jdk利用其SPI机制替我们执行了这行代码。假设没有SPI机制，当我们需要切换数据源驱动时，例如从mysql切到oracle，此时不仅要导入oracle的驱动依赖包，还要修改这一行代码。而借助SPI机制，我们可以省去这行代码，从而只需引入依赖包即可实现目的，这便是SPI机制解耦作用的直观体现。

首先分析这行代码为什么需要执行（注意是执行，而不一定是由我们的业务代码触发），这行代码的意思也很简单，即加载指定类com.mysql.cj.jdbc.Driver，而类加载期间是能执行代码的（静态变量赋值、静态代码块等），故查看该类的源码：

public class Driver extends NonRegisteringDriver implements java.sql.Driver {public Driver() throws SQLException {}static {try {DriverManager.registerDriver(new Driver());} catch (SQLException var1) {throw new RuntimeException("Can't register driver!");}}
}

果不其然有静态代码块，但代码并不多，核心代码就一行DriverManager.registerDriver(new Driver());，望文生义得知其目的是向DriverManager类中添加mysql驱动，进一步跟踪源码（期间经过了方法重载）：

public static synchronized void registerDriver(java.sql.Driver driver,DriverAction da)throws SQLException {/* Register the driver if it has not already been added to our list */if(driver != null) {registeredDrivers.addIfAbsent(new DriverInfo(driver, da));} else {// This is for compatibility with the original DriverManagerthrow new NullPointerException();}println("registerDriver: " + driver);}

关键代码registeredDrivers.addIfAbsent(new DriverInfo(driver, da));将驱动（即com.mysql.cj.jdbc.Driver的实例对象）添加到列表registeredDrivers中，供后续获取数据库连接使用。故代码Class.forName("com.mysql.cj.jdbc.Driver");的目的就是创建一个mysql数据库驱动对象，并将其添加到DriverManager类维护的驱动列表中。

接下来分析当我们移除该行代码时，SPI机制是如何帮我们执行的。首先，java.sql.DriverManager并非核心基础类，不会由jvm在启动时加载，而是当业务代码执行到conn = DriverManager.getConnection("url", "name", "password");时，才会去加载DriverManager类，进一步跟踪源码：

static {loadInitialDrivers();println("JDBC DriverManager initialized");
}private static void loadInitialDrivers() {
// 省去其他代码AccessController.doPrivileged(new PrivilegedAction<Void>() {public Void run() {ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);Iterator<Driver> driversIterator = loadedDrivers.iterator();try{while(driversIterator.hasNext()) {driversIterator.next();}} catch(Throwable t) {// Do nothing}return null;}});
// 省去其他代码
}

当DriverManager类加载时，执行了loadInitialDrivers方法，观察核心代码ServiceLoader.load(Driver.class); ，注意此处的Driver并非com.mysql.cj.jdbc.Driver，而是java.sql.Driver，前者是位于jar包mysql-connector-java中的类，后者是位于jdk的rt.jar中的接口，二者是实现的关系，切勿混淆！同样望文生义得知这行代码的目的是加载驱动类，进一步跟踪源码：

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);
}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();
}public void reload() {providers.clear();lookupIterator = new LazyIterator(service, loader);
}private class LazyIteratorimplements Iterator<S> {private LazyIterator(Class<S> service, ClassLoader loader) {this.service = service;this.loader = loader;}
}

链路有点长，但仔细观察得知其全程并没有执行形如Class.forName(xxx)的代码，只是将传入的java.sql.Driver接口的Class对象与当前线程的上下文类加载器存在了ServiceLoader中，并在其内部类LazyIterator中同样拷贝了二者的引用。LazyIterator直译懒惰的迭代器，也即懒加载思想，只有当使用到该类时是再去加载它。

回到DriverManager类的loadInitialDrivers方法，观察核心代码 while(driversIterator.hasNext()) { driversIterator.next(); }，这里的迭代器driversIterator是ServiceLoader类对Iterator接口的实现，本质上是套了个壳子，对已加载的服务提供者（即mysql驱动类的实例）做了缓存，最后依然调用的是LazyIterator中的hasNext()和next()方法，进一步跟踪LazyIterator的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);}
}private boolean hasNextService() {if (nextName != null) {return true;}if (configs == null) {try {String fullName = PREFIX + service.getName();if (loader == null)configs = ClassLoader.getSystemResources(fullName);elseconfigs = 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;
}

首次进来时configs、pending、nextName都是空，故会执行configs = loader.getResources(fullName);逻辑，而String fullName = PREFIX + service.getName();，PREFIX为静态常量，其值为"META-INF/services/"，service.getName()即为字符串“java.sql.Driver”，此处获取了文件“META-INF/services/java.sql.Driver”的URL，并通过后续代码pending = parse(service, configs.nextElement());读取文件内容，pending即为该文件的内容，它是一个字符串迭代器（单行文本为一个元素），这意味着我们可以在该文件中配置多个数据库驱动（以换行分隔）。

这里的代码决定了JAVA SPI机制的使用方法：在ClassPath下新建"META-INF/services/"目录，并在其中新建文件，文件名为接口的全限定类名，文件内容为接口实现类的全限定类名，多个实现类以换行分隔。按这种方式配置后，我们就可以在代码中通过ServiceLoader.load(Xxx.class)的方式加载这些实现类，但请注意其懒加载机制，只有真正遍历该方法返回的迭代器时才会执行类加载！

进一步跟踪ServiceLoader的迭代器源码：

public S next() {if (knownProviders.hasNext())return knownProviders.next().getValue();// lookupIterator为内部类LazyIterator的实例return lookupIterator.next();
}// 内部类LazyIterator的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);}
}// 内部类LazyIterator的nextService方法
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
}

拨开云雾见光明，终于看到了Class.forName(cn, false, loader);，这里的cn即为文件“META-INF/services/java.sql.Driver”中的一行内容，并随着迭代的进行不断变更（见hasNextService方法），在mysql驱动中即为“com.mysql.cj.jdbc.Driver”。同时，代码service.cast(c.newInstance());新建了com.mysql.cj.jdbc.Driver的实例对象，并将其向上转型为java.sql.Driver对象缓存起来。

经过上述的源码分析，整体的流程已经变得清晰起来。若业务代码不主动加载数据库驱动，当执行到DriverManager.getConnection(xxx)时，会先去触发DriverManager的类加载，然后在这个过程中利用SPI机制加载java.sql.Driver的实现类com.mysql.cj.jdbc.Driver（涉及到读取META-INF/services/java.sql.Driver文件），最后在com.mysql.cj.jdbc.Driver的类加载过程中向DriverManager注册mysql驱动实例。

至此，当DriverManager完成类加载时，它已经以静态变量的方式拥有了一个或多个数据库驱动实例，从而供后续获取数据库连接使用。例如通过DriverManager获取连接的源码：

@CallerSensitive
public static Connection getConnection(String url,String user, String password) throws SQLException {java.util.Properties info = new java.util.Properties();if (user != null) {info.put("user", user);}if (password != null) {info.put("password", password);}return (getConnection(url, info, Reflection.getCallerClass()));
}private static Connection getConnection(String url, java.util.Properties info, Class<?> caller) throws SQLException {// 省去其他代码for(DriverInfo aDriver : registeredDrivers) {// If the caller does not have permission to load the driver then// skip it.if(isDriverAllowed(aDriver.driver, callerCL)) {try {println("    trying " + aDriver.driver.getClass().getName());Connection con = aDriver.driver.connect(url, info);if (con != null) {// Success!println("getConnection returning " + aDriver.driver.getClass().getName());return (con);}} catch (SQLException ex) {if (reason == null) {reason = ex;}}} else {println("    skipping: " + aDriver.getClass().getName());}}// 省去其他代码
}

其中，registeredDrivers即为在类加载期间利用SPI机制注册的数据库驱动列表。通过这里的源码可知，DriverManager在获取数据库连接时，会遍历所有的数据库驱动，将数据库配置信息传入这些驱动程序，直到成功获取连接为止。

扩展

上述源码中还有一个细节值得注意，ServiceLoader使用的是线程上下文类加载器，即Thread.currentThread().getContextClassLoader();，为何不是ServiceLoader.class.getClassLoader()这种方式？

public static <S> ServiceLoader<S> load(Class<S> service) {ClassLoader cl = Thread.currentThread().getContextClassLoader();return ServiceLoader.load(service, cl);
}

我们手动打印二者得知，前者输出sun.misc.Launcher$AppClassLoader@14dad5dc，后者输出null。null对应引导类加载器BootstrapClassLoader，AppClassLoader为应用程序类加载器，也即我们自己程序的类加载器。如果用ServiceLoader.class.getClassLoader()的方式，这意味着让引导类加载器去加载三方插件mysql-connector-java包中类，这当然是不行的，因为引导类加载器只负责加载Java的核心类库，并要求包路径前缀为java、javax、sun等。

而Thread.currentThread().getContextClassLoader();会去获取当前线程的上下文加载器，如果不手动设置（通常如此），则会去找父线程的上下文加载器，在我们的案例中没有父线程，仅有main主线程，由我们的应用程序创建，故其类加载器为应用程序类加载器，可以加载三方插件中的类。

类似这种一个类自身的加载器无法加载它想加载的其他类时，往往都会利用线程上下文加载器去打破这种限制（即传统的双亲委派模型），这种行为在Spring、Dubbo等知名开源项目中更是不遑多见（它们都对SPI机制做了某种升级改造），但最终的目的都是为了减少开发者工作量，简单的SPI机制可以让我们少写一行代码，这些复杂的开源框架必会将更多的优秀代码埋藏深处，等待有心人发现。