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依旧是存在缺点和不足的,如下:

  1. 不能按需加载。需要遍历所有的实现,并且进行实例化,某些实现的实例化可能很耗时,这样会造成浪费;
  2. 获取实现类的方式不够灵活,只能通过Iterator获取,不能根据某个参数来获取实现类;
  3. 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)
loadedDrivers.iterator()
driversIterator.hasNext()
driversIterator.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对象中传入一个低级别的类加载器,如系统类加载器,从而来打破双亲委派机制。

博客园精华区
我还没有学会写个人说明!
上一篇

Elasticsearch 多字段查询 best_fields、most_fields、cross_fields,傻傻分不清楚?

下一篇

基于跨端框架项目的内存问题优化

你也可能喜欢

评论已经被关闭。

插入图片