SPI机制剖析——基于DriverManager+ServiceLoader的源码分析

我的上一篇博客类加载器与双亲委派中提到，SPI机制是一种上级类加载器调用下级类加载器的情形，因此会打破类加载的双亲委派模型。为了深入理解其中的细节，本博客详细剖析一下SPI机制，并以JDBC为例，基于源码来进行分析。

SPI

原理介绍

SPI（Service Provider Interface），是JDK内置的服务提供发现机制。即JDK内部定义规范的接口，不同厂商基于标准服务接口实现具体的实现类和方法。SPI一般被用来做框架扩展的开发。

下面这张图，很简明扼要地阐释了SPI的机理。

与SPI相对应的，是我们耳熟能详的API。API不需要上图中“标准服务接口”这一环节，而是调用方直接调用服务提供方。按照上一篇博客的分析，“标准服务接口”位于Java核心类库中，使用boot类加载器进行加载，而boot类加载器是无法获取“第三方实现类”的位置的。所以，相较于API而言，SPI需要打破双亲委派模型。

优缺点

好处

但是，我陷入思考，SPI这样的模式有什么好处吗，或者说API有什么缺点吗？

想象一下，如果程序直接调用第三方类库，当第三方类库发生改动时，应用程序代码很可能需要随之改动。但如果在JDK内部定义标准服务接口，要求第三方厂商实现这些接口，那无论实现类如何改动，只要标准接口不变，都不会影响到应用程序。所以我认为SPI机制的根本目的是为了“解耦”。这也就是面向对象中所谓的“接口编程”，把装配的控制权移到程序之外。

许多著名的第三方类库都采纳了SPI机制，JDBC就是其中之一。数据库厂商会基于标准接口来开发相应的连接库。如MySQL何PostgreSql的驱动都实现了标准接口：java.sql.Driver。对于应用程序而言，无需关心是MySQL还是PostgreSql，只需要与标准服务接口打交道即可。SPI正是基于这种模式完成了解耦合。

不足

当然，即便如此，SPI依旧是存在缺点和不足的，如下：

不能按需加载。需要遍历所有的实现，并且进行实例化，某些实现的实例化可能很耗时，这样会造成浪费；
获取实现类的方式不够灵活，只能通过Iterator获取，不能根据某个参数来获取实现类；
ServiceLoader类的实例线程不安全。

JDBC的SPI机制

首先来看一段使用JDBC的简单代码：

@Test

public void testJDBC() throws SQLException, ClassNotFoundException {

    String url = "jdbc:mysql://localhost:3307/mls";

    String userName = "root";

    String password = "123456";

    // Class.forName("com.mysql.cj.jdbc.Driver");

    Connection con = DriverManager.getConnection(url, userName, password);

    Statement statement = con.createStatement();

    String sql = "select * from mlsdb where id=1";

    ResultSet rs = statement.executeQuery(sql);

    while (rs.next()) {

        System.out.println(rs.getString("province"));

    }

}

注意到中间有一行注释的代码Class.forName("com.mysql.cj.jdbc.Driver");，其实这一行可写可不写。

我的倒数第二篇博客类加载时机与过程里提到，Class.forName方法会触发“初始化”，即触发类加载的进行。因此如果写上这行代码，此处则是使用APP类加载器加载mysql的jdbc驱动类。

然而，这一句Class.forName不用写，代码也能正常运行。因为加载DriverManager类时，会将MySQL的Driver对象注册进DriverManager中。具体流程后文会细说。其实这就是SPI思想的一个典型的实现。得益于SPI思想，应用程序中无需指定类似"com.mysql.cj.jdbc.Driver"这种全类名，尽可能地将第三方驱动从应用程序中解耦出来。

下面，通过源码来分析驱动加载以及服务发现的过程，主要涉及到DriverManager和ServiceLoader两个类

源码分析

DriverManager是用于管理Jdbc驱动的基础服务类，位于Java.sql包中，因此是由boot类加载器来进行加载。加载该类时，会执行如下代码块：

/**

 * 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");

}

上述静态代码块会执行loadInitialDrivers()方法，该方法用于加载各个数据库驱动。代码如下：

private static void loadInitialDrivers() {

    String drivers;

    try {

        drivers = AccessController.doPrivileged(new PrivilegedAction<String>() {

            public String run() {

                return System.getProperty("jdbc.drivers");

            }

        });

    } catch (Exception ex) {

        drivers = null;

    }

    AccessController.doPrivileged(new PrivilegedAction<Void>() {

        public Void run() {

            ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);//实例化ServiceLoader对象，并注入线程上下文类加载器和Driver.class

            Iterator<Driver> driversIterator = loadedDrivers.iterator();//获得迭代器

            try{

                while(driversIterator.hasNext()) {

                    driversIterator.next();//进行类加载

         `       }

         `   } catch(Throwable t) {

            // Do nothing

            }

            return null;

        }

    });

    println("DriverManager.initialize: jdbc.drivers = " + drivers);

    if (drivers == null || drivers.equals("")) {

        return;

    }

    String[] driversList = drivers.split(":");

    println("number of Drivers:" + driversList.length);

    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);

        }

    }

}

ServiceLoader.load(Driver.class)此方法会把实例化一个ServiceLoader对象，并且向其注入线程上下文类加载器和Driver.class；
loadedDrivers.iterator()：获得ServiceLoader对象的迭代器；
driversIterator.hasNext()：查找Driver类；
driversIterator.next()：在实现的“next()”方法中进行类加载，使用上面的线程上下文类加载器。

ServiceLoader.load(Driver.class);的代码及相关调用方法如下：

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);

}

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();

}

经过上述过程，用成员变量private final ClassLoader loader;引用传入的类加载器，用service接收Driver.class。同时，上述过程中实例化了一个LazyIterator对象，并用成员变量lookupIterator来引用。

执行ServiceLoader的“hasNext()”方法时最终会调用lookupIterator迭代器的“hasNext()”方法（此处暂且省略调用过程），如下：

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;

}

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);

    }

}

上述过程通过configs = loader.getResources(fullName)来查找实现Driver接口的类。

同样，ServiceLoader的迭代器的“next()”方法最终会调用lookupIterator迭代器的“next()”方法，如下：

private S nextService() {

    if (!hasNextService())

        throw new NoSuchElementException();

    String cn = nextName;

    nextName = null;

    Class<?> c = null;

    try {

        c = Class.forName(cn, false, loader);//使用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

}

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);

    }

}

可以看到，next()会最终调用到nextService()方法，并在此方法中通过c = Class.forName(cn, false, loader);执行类加载。此处的loader也是由ServiceLoader中的loader传入的，即为前文提到的线程上下文类加载器。

经历了上述ServiceLoader类中一系列操作之后（包括服务发现和类加载），位于mysql驱动包中的Driver类会被初始化。该类如下所示

package com.mysql.cj.jdbc;

import java.sql.DriverManager;

import java.sql.SQLException;

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!");

        }

    }

}

上述Driver类加载时，会执行静态代码块，即执行DriverManager.registerDriver(new Driver());方法向DriverManager中注册一个Driver实例。

我们再回到DriverManager类中，看看registerDriver方法：

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 DriverManager

        throw new NullPointerException();

    }

    println("registerDriver: " + driver);

}

会将该MySQL驱动添加到成员变量registeredDrivers中，该成员变量存放已注册的jdbc驱动列表，如下：

// List of registered JDBC drivers

private final static CopyOnWriteArrayList<DriverInfo> registeredDrivers = new CopyOnWriteArrayList<>();

如此一来，服务发现、类加载、驱动注册便到此结束。接下来，应用程序执行数据库连接操作时，会调用“getConnection”方法，遍历registeredDrivers，获取驱动，建立数据库连接。

总结

以上便是JDBC的SPI机制总结，最核心的地方在于，ServiceLoader中使用低级别的加载器发现Driver类，并进行类加载。这些工作是BootStrap类加载器所办不到的。由于DriverManager和ServiceLoader都位于Java核心类库中，使用BootStrap类加载器来加载，所以需要通过线程上下文类加载器向ServiceLoader对象中传入一个低级别的类加载器，如系统类加载器，从而来打破双亲委派机制。

巴特西

SPI机制剖析——基于DriverManager+ServiceLoader的源码分析

SPI

原理介绍

优缺点

好处

不足

JDBC的SPI机制

源码分析

总结

最新文章

热门文章