Java是如何實(shí)現(xiàn)自己的SPI機(jī)制的? JDK源碼(一)
注:該源碼分析對(duì)應(yīng)JDK版本為1.8
1 引言
這是【源碼筆記】的JDK源碼解讀的第一篇文章,本篇我們來探究Java的SPI機(jī)制的相關(guān)源碼。
2 什么是SPI機(jī)制
那么,什么是SPI機(jī)制呢?
SPI是Service Provider Interface 的簡(jiǎn)稱,即服務(wù)提供者接口的意思。根據(jù)字面意思我們可能還有點(diǎn)困惑,SPI說白了就是一種擴(kuò)展機(jī)制,我們?cè)谙鄳?yīng)配置文件中定義好某個(gè)接口的實(shí)現(xiàn)類,然后再根據(jù)這個(gè)接口去這個(gè)配置文件中加載這個(gè)實(shí)例類并實(shí)例化,其實(shí)SPI就是這么一個(gè)東西。說到SPI機(jī)制,我們最常見的就是Java的SPI機(jī)制,此外,還有Dubbo和SpringBoot自定義的SPI機(jī)制。
有了SPI機(jī)制,那么就為一些框架的靈活擴(kuò)展提供了可能,而不必將框架的一些實(shí)現(xiàn)類寫死在代碼里面。
那么,某些框架是如何利用SPI機(jī)制來做到靈活擴(kuò)展的呢?下面舉幾個(gè)栗子來闡述下:
-
JDBC驅(qū)動(dòng)加載案例:利用Java的SPI機(jī)制,我們可以根據(jù)不同的數(shù)據(jù)庫(kù)廠商來引入不同的JDBC驅(qū)動(dòng)包; -
SpringBoot的SPI機(jī)制:我們可以在 spring.factories
中加上我們自定義的自動(dòng)配置類,事件監(jiān)聽器或初始化器等; -
Dubbo的SPI機(jī)制:Dubbo更是把SPI機(jī)制應(yīng)用的 淋漓盡致,Dubbo基本上自身的每個(gè)功能點(diǎn)都提供了擴(kuò)展點(diǎn),比如提供了集群擴(kuò)展,路由擴(kuò)展和負(fù)載均衡擴(kuò)展等差不多接近30個(gè)擴(kuò)展點(diǎn)。如果Dubbo的某個(gè)內(nèi)置實(shí)現(xiàn)不符合我們的需求,那么我們只要利用其SPI機(jī)制將我們的實(shí)現(xiàn)替換掉Dubbo的實(shí)現(xiàn)即可。
上面的三個(gè)栗子先讓我們直觀感受下某些框架利用SPI機(jī)制是如何做到靈活擴(kuò)展的。
3 如何使用Java的SPI?
我們先來看看如何使用Java自帶的SPI。先定義一個(gè)Developer
接口
// Developer.java
package com.ymbj.spi;
public interface Developer {
void sayHi();
}
再定義兩個(gè)Developer
接口的兩個(gè)實(shí)現(xiàn)類:
// JavaDeveloper.java
package com.ymbj.spi;
public class JavaDeveloper implements Developer {
@Override
public void sayHi() {
System.out.println("Hi, I am a Java Developer.");
}
}
// PythonDeveloper.java
package com.ymbj.spi;
public class PythonDeveloper implements Developer {
@Override
public void sayHi() {
System.out.println("Hi, I am a Python Developer.");
}
}
然后再在項(xiàng)目resources
目錄下新建一個(gè)META-INF/services
文件夾,然后再新建一個(gè)以Developer
接口的全限定名命名的文件,文件內(nèi)容為:
// com.ymbj.spi.Developer文件
com.ymbj.spi.JavaDeveloper
com.ymbj.spi.PythonDeveloper
最后我們?cè)傩陆ㄒ粋€(gè)測(cè)試類JdkSPITest
:
// JdkSPITest.java
public class JdkSPITest {
@Test
public void testSayHi() throws Exception {
ServiceLoader<Developer> serviceLoader = ServiceLoader.load(Developer.class);
serviceLoader.forEach(Developer::sayHi);
}
}
運(yùn)行上面那個(gè)測(cè)試類,運(yùn)行成功結(jié)果如下截圖所示:
由上面簡(jiǎn)單的Demo我們知道了如何使用Java的SPI機(jī)制來實(shí)現(xiàn)擴(kuò)展點(diǎn)加載,下面推薦一篇文章JAVA拾遺--關(guān)于SPI機(jī)制,通過這篇文章,相信大家對(duì)Java的SPI會(huì)有一個(gè)比較深刻的理解,特別是JDBC加載驅(qū)動(dòng)這方面。
4 Java的SPI機(jī)制的源碼分析
通過前面擴(kuò)展Developer
接口的簡(jiǎn)單Demo,我們看到Java的SPI機(jī)制實(shí)現(xiàn)跟ServiceLoader
這個(gè)類有關(guān),那么我們先來看下ServiceLoader
的類結(jié)構(gòu)代碼:
// ServiceLoader實(shí)現(xiàn)了【Iterable】接口
public final class ServiceLoader<S>
implements Iterable<S>{
private static final String PREFIX = "META-INF/services/";
// The class or interface representing the service being loaded
private final Class<S> service;
// The class loader used to locate, load, and instantiate providers
private final ClassLoader loader;
// The access control context taken when the ServiceLoader is created
private final AccessControlContext acc;
// Cached providers, in instantiation order
private LinkedHashMap<String,S> providers = new LinkedHashMap<>();
// The current lazy-lookup iterator
private LazyIterator lookupIterator;
// 構(gòu)造方法
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();
}
// ...暫時(shí)省略相關(guān)代碼
// ServiceLoader的內(nèi)部類LazyIterator,實(shí)現(xiàn)了【Iterator】接口
// Private inner class implementing fully-lazy provider lookup
private class LazyIterator
implements Iterator<S>{
Class<S> service;
ClassLoader loader;
Enumeration<URL> configs = null;
Iterator<String> pending = null;
String nextName = null;
private LazyIterator(Class<S> service, ClassLoader loader) {
this.service = service;
this.loader = loader;
}
// 覆寫Iterator接口的hasNext方法
public boolean hasNext() {
// ...暫時(shí)省略相關(guān)代碼
}
// 覆寫Iterator接口的next方法
public S next() {
// ...暫時(shí)省略相關(guān)代碼
}
// 覆寫Iterator接口的remove方法
public void remove() {
// ...暫時(shí)省略相關(guān)代碼
}
}
// 覆寫Iterable接口的iterator方法,返回一個(gè)迭代器
public Iterator<S> iterator() {
// ...暫時(shí)省略相關(guān)代碼
}
// ...暫時(shí)省略相關(guān)代碼
}
可以看到,ServiceLoader
實(shí)現(xiàn)了Iterable
接口,覆寫其iterator
方法能產(chǎn)生一個(gè)迭代器;同時(shí)ServiceLoader
有一個(gè)內(nèi)部類LazyIterator
,而LazyIterator
又實(shí)現(xiàn)了Iterator
接口,說明LazyIterator
是一個(gè)迭代器。
4.1 ServiceLoader.load方法,為加載服務(wù)提供者實(shí)現(xiàn)類做前期準(zhǔn)備
那么我們現(xiàn)在開始探究Java的SPI機(jī)制的源碼, 先來看JdkSPITest
的第一句代碼ServiceLoader<Developer> serviceLoader = ServiceLoader.load(Developer.class);
中的ServiceLoader.load(Developer.class)
的源碼:
// ServiceLoader.java
public static <S> ServiceLoader<S> load(Class<S> service) {
//獲取當(dāng)前線程上下文類加載器
ClassLoader cl = Thread.currentThread().getContextClassLoader();
// 將service接口類和線程上下文類加載器作為參數(shù)傳入,繼續(xù)調(diào)用load方法
return ServiceLoader.load(service, cl);
}
我們?cè)賮砜聪?code style="font-size: 14px;overflow-wrap: break-word;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;background-color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;color: rgb(53, 179, 120);">ServiceLoader.load(service, cl);方法:
// ServiceLoader.java
public static <S> ServiceLoader<S> load(Class<S> service,
ClassLoader loader)
{
// 將service接口類和線程上下文類加載器作為構(gòu)造參數(shù),新建了一個(gè)ServiceLoader對(duì)象
return new ServiceLoader<>(service, loader);
}
繼續(xù)看new ServiceLoader<>(service, loader);
是如何構(gòu)建的?
// ServiceLoader.java
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();
}
可以看到在構(gòu)建ServiceLoader
對(duì)象時(shí)除了給其成員屬性賦值外,還調(diào)用了reload
方法:
// ServiceLoader.java
public void reload() {
providers.clear();
lookupIterator = new LazyIterator(service, loader);
}
可以看到在reload
方法中又新建了一個(gè)LazyIterator
對(duì)象,然后賦值給lookupIterator
。
// ServiceLoader$LazyIterator.java
private LazyIterator(Class<S> service, ClassLoader loader) {
this.service = service;
this.loader = loader;
}
可以看到在構(gòu)建LazyIterator
對(duì)象時(shí),也只是給其成員變量service
和loader
屬性賦值呀,我們一路源碼跟下來,也沒有看到去META-INF/services
文件夾加載Developer
接口的實(shí)現(xiàn)類!這就奇怪了,我們都被ServiceLoader
的load
方法名騙了。
還記得分析前面的代碼時(shí)新建了一個(gè)LazyIterator
對(duì)象嗎?Lazy
顧名思義是懶的意思,Iterator
就是迭代的意思。我們此時(shí)猜測(cè)那么LazyIterator
對(duì)象的作用應(yīng)該就是在迭代的時(shí)候再去加載Developer
接口的實(shí)現(xiàn)類了。
4.2 ServiceLoader.iterator方法,實(shí)現(xiàn)服務(wù)提供者實(shí)現(xiàn)類的懶加載
我們現(xiàn)在再來看JdkSPITest
的第二句代碼serviceLoader.forEach(Developer::sayHi);
,執(zhí)行這句代碼后最終會(huì)調(diào)用serviceLoader
的iterator
方法:
// serviceLoader.java
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;
// 調(diào)用lookupIterator即LazyIterator的hasNext方法
// 可以看到是委托給LazyIterator的hasNext方法來實(shí)現(xiàn)
return lookupIterator.hasNext();
}
public S next() {
if (knownProviders.hasNext())
return knownProviders.next().getValue();
// 調(diào)用lookupIterator即LazyIterator的next方法
// 可以看到是委托給LazyIterator的next方法來實(shí)現(xiàn)
return lookupIterator.next();
}
public void remove() {
throw new UnsupportedOperationException();
}
};
}
可以看到調(diào)用serviceLoader
的iterator
方法會(huì)返回一個(gè)匿名的迭代器對(duì)象,而這個(gè)匿名迭代器對(duì)象其實(shí)相當(dāng)于一個(gè)門面類,其覆寫的hasNext
和next
方法又分別委托LazyIterator
的hasNext
和next
方法來實(shí)現(xiàn)了。
我們繼續(xù)調(diào)試,發(fā)現(xiàn)接下來會(huì)進(jìn)入LazyIterator
的hasNext
方法:
// serviceLoader$LazyIterator.java
public boolean hasNext() {
if (acc == null) {
// 調(diào)用hasNextService方法
return hasNextService();
} else {
PrivilegedAction<Boolean> action = new PrivilegedAction<Boolean>() {
public Boolean run() { return hasNextService(); }
};
return AccessController.doPrivileged(action, acc);
}
}
繼續(xù)跟進(jìn)hasNextService
方法:
// serviceLoader$LazyIterator.java
private boolean hasNextService() {
if (nextName != null) {
return true;
}
if (configs == null) {
try {
// PREFIX = "META-INF/services/"
// service.getName()即接口的全限定名
// 還記得前面的代碼構(gòu)建LazyIterator對(duì)象時(shí)已經(jīng)給其成員屬性service賦值嗎
String fullName = PREFIX + service.getName();
// 加載META-INF/services/目錄下的接口文件中的服務(wù)提供者類
if (loader == null)
configs = ClassLoader.getSystemResources(fullName);
else
// 還記得前面的代碼構(gòu)建LazyIterator對(duì)象時(shí)已經(jīng)給其成員屬性loader賦值嗎
configs = loader.getResources(fullName);
} catch (IOException x) {
fail(service, "Error locating configuration files", x);
}
}
while ((pending == null) || !pending.hasNext()) {
if (!configs.hasMoreElements()) {
return false;
}
// 返回META-INF/services/目錄下的接口文件中的服務(wù)提供者類并賦值給pending屬性
pending = parse(service, configs.nextElement());
}
// 然后取出一個(gè)全限定名賦值給LazyIterator的成員變量nextName
nextName = pending.next();
return true;
}
可以看到在執(zhí)行LazyIterator
的hasNextService
方法時(shí)最終將去META-INF/services/
目錄下加載接口文件的內(nèi)容即加載服務(wù)提供者實(shí)現(xiàn)類的全限定名,然后取出一個(gè)服務(wù)提供者實(shí)現(xiàn)類的全限定名賦值給LazyIterator
的成員變量nextName
。到了這里,我們就明白了LazyIterator
的作用真的是懶加載,在用到的時(shí)候才會(huì)真正去加載服務(wù)提供者實(shí)現(xiàn)類。
思考:為何這里要用懶加載呢?懶加載的思想是怎樣的呢?懶加載有啥好處呢?你還能舉出其他懶加載的案例嗎?
同樣,執(zhí)行完LazyIterator
的hasNext
方法后,會(huì)繼續(xù)執(zhí)行LazyIterator
的next
方法:
// serviceLoader$LazyIterator.java
public S next() {
if (acc == null) {
// 調(diào)用nextService方法
return nextService();
} else {
PrivilegedAction<S> action = new PrivilegedAction<S>() {
public S run() { return nextService(); }
};
return AccessController.doPrivileged(action, acc);
}
}
我們繼續(xù)跟進(jìn)nextService
方法:
// serviceLoader$LazyIterator.java
private S nextService() {
if (!hasNextService())
throw new NoSuchElementException();
// 還記得在hasNextService方法中為nextName賦值過服務(wù)提供者實(shí)現(xiàn)類的全限定名嗎
String cn = nextName;
nextName = null;
Class<?> c = null;
try {
// 【1】去classpath中根據(jù)傳入的類加載器和服務(wù)提供者實(shí)現(xiàn)類的全限定名去加載服務(wù)提供者實(shí)現(xiàn)類
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 {
// 【2】實(shí)例化剛才加載的服務(wù)提供者實(shí)現(xiàn)類,并進(jìn)行轉(zhuǎn)換
S p = service.cast(c.newInstance());
// 【3】最終將實(shí)例化后的服務(wù)提供者實(shí)現(xiàn)類放進(jìn)providers集合
providers.put(cn, p);
return p;
} catch (Throwable x) {
fail(service,
"Provider " + cn + " could not be instantiated",
x);
}
throw new Error(); // This cannot happen
}
可以看到LazyIterator
的nextService
方法最終將實(shí)例化之前加載的服務(wù)提供者實(shí)現(xiàn)類,并放進(jìn)providers
集合中,隨后再調(diào)用服務(wù)提供者實(shí)現(xiàn)類的方法(比如這里指JavaDeveloper
的sayHi
方法)。注意,這里是加載一個(gè)服務(wù)提供者實(shí)現(xiàn)類后,若main
函數(shù)中有調(diào)用該服務(wù)提供者實(shí)現(xiàn)類的方法的話,緊接著會(huì)調(diào)用其方法;然后繼續(xù)實(shí)例化下一個(gè)服務(wù)提供者類。
因此,我們看到了ServiceLoader.iterator
方法真正承擔(dān)了加載并實(shí)例化META-INF/services/
目錄下的接口文件里定義的服務(wù)提供者實(shí)現(xiàn)類。
設(shè)計(jì)模式:可以看到,Java的SPI機(jī)制實(shí)現(xiàn)代碼中應(yīng)用了迭代器模式,迭代器模式屏蔽了各種存儲(chǔ)對(duì)象的內(nèi)部結(jié)構(gòu)差異,提供一個(gè)統(tǒng)一的視圖來遍歷各個(gè)存儲(chǔ)對(duì)象(存儲(chǔ)對(duì)象可以為集合,數(shù)組等)。
java.util.Iterator
也是迭代器模式的實(shí)現(xiàn):同時(shí)Java的各個(gè)集合類一般實(shí)現(xiàn)了Iterable
接口,實(shí)現(xiàn)了其iterator
方法從而獲得Iterator
接口的實(shí)現(xiàn)類對(duì)象(一般為集合內(nèi)部類),然后再利用Iterator
對(duì)象的實(shí)現(xiàn)類的hasNext
和next
方法來遍歷集合元素。
5 JDBC驅(qū)動(dòng)加載源碼解讀
前面分析了Java的SPI機(jī)制的源碼實(shí)現(xiàn),現(xiàn)在我們?cè)賮砜聪翵ava的SPI機(jī)制的實(shí)際案例的應(yīng)用。
我們都知道,JDBC驅(qū)動(dòng)加載是Java的SPI機(jī)制的典型應(yīng)用案例。JDBC主要提供了一套接口規(guī)范,而這套規(guī)范的api在java的核心庫(kù)(rt.jar
)中實(shí)現(xiàn),而不同的數(shù)據(jù)庫(kù)廠商只要編寫符合這套JDBC接口規(guī)范的驅(qū)動(dòng)代碼,那么就可以用Java語言來連接數(shù)據(jù)庫(kù)了。
java的核心庫(kù)(rt.jar
)中跟JDBC驅(qū)動(dòng)加載的最核心的接口和類分別是java.sql.Driver
接口和java.sql.DriverManager
類,其中java.sql.Driver
是各個(gè)數(shù)據(jù)庫(kù)廠商的驅(qū)動(dòng)類要實(shí)現(xiàn)的接口,而DriverManager
是用來管理數(shù)據(jù)庫(kù)的驅(qū)動(dòng)類的,值得注意的是DriverManager
這個(gè)類有一個(gè)registeredDrivers
集合屬性,用來存儲(chǔ)Mysql的驅(qū)動(dòng)類。
// DriverManager.java
// List of registered JDBC drivers
private final static CopyOnWriteArrayList<DriverInfo> registeredDrivers = new CopyOnWriteArrayList<>();
這里以加載Mysql驅(qū)動(dòng)為例來分析JDBC驅(qū)動(dòng)加載的源碼。
我們的項(xiàng)目引入mysql-connector-java
依賴(這里的版本是5.1.47
)后,那么Mysql的驅(qū)動(dòng)實(shí)現(xiàn)類文件如下圖所示:
可以看到Mysql的驅(qū)動(dòng)包中有兩個(gè)Driver
驅(qū)動(dòng)類,分別是com.mysql.jdbc.Driver
和com.mysql.fabric.jdbc.FabricMySQLDriver
,默認(rèn)情況下一般我們只用到前者。
5.1 利用Java的SPI加載Mysql的驅(qū)動(dòng)類
那么接下來我們就來探究下JDBC驅(qū)動(dòng)加載的代碼是如何實(shí)現(xiàn)的。
先來看一下一個(gè)簡(jiǎn)單的JDBC的測(cè)試代碼:
// JdbcTest.java
public class JdbcTest {
public static void main(String[] args) {
Connection connection = null;
Statement statement = null;
ResultSet rs = null;
try {
// 注意:在JDBC 4.0規(guī)范中,這里可以不用再像以前那樣編寫顯式加載數(shù)據(jù)庫(kù)的代碼了
// Class.forName("com.mysql.jdbc.Driver");
// 獲取數(shù)據(jù)庫(kù)連接,注意【這里將會(huì)加載mysql的驅(qū)動(dòng)包】
/***************【主線,切入點(diǎn)】****************/
connection = DriverManager.getConnection("jdbc:mysql://localhost:3306/jdbc", "root", "123456");
// 創(chuàng)建Statement語句
statement = connection.createStatement();
// 執(zhí)行查詢語句
rs = statement.executeQuery("select * from user");
// 遍歷查詢結(jié)果集
while(rs.next()){
String name = rs.getString("name");
System.out.println(name);
}
} catch(Exception e) {
e.printStackTrace();
} finally {
// ...省略釋放資源的代碼
}
}
}
在JdbcTest
的main
函數(shù)調(diào)用DriverManager
的getConnection
方法時(shí),此時(shí)必然會(huì)先執(zhí)行DriverManager
類的靜態(tài)代碼塊的代碼,然后再執(zhí)行getConnection
方法,那么先來看下DriverManager
的靜態(tài)代碼塊:
// DriverManager.java
static {
// 加載驅(qū)動(dòng)實(shí)現(xiàn)類
loadInitialDrivers();
println("JDBC DriverManager initialized");
}
繼續(xù)跟進(jìn)loadInitialDrivers
的代碼:
// DriverManager.java
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() {
// 來到這里,是不是感覺似曾相識(shí),對(duì),沒錯(cuò),我們?cè)谇懊娴腏dkSPITest代碼中執(zhí)行過下面的兩句代碼
// 這句代碼前面已經(jīng)分析過,這里不會(huì)真正加載服務(wù)提供者實(shí)現(xiàn)類
// 而是實(shí)例化一個(gè)ServiceLoader對(duì)象且實(shí)例化一個(gè)LazyIterator對(duì)象用于懶加載
ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
// 調(diào)用ServiceLoader的iterator方法,在迭代的同時(shí),也會(huì)去加載并實(shí)例化META-INF/services/java.sql.Driver文件
// 的com.mysql.jdbc.Driver和com.mysql.fabric.jdbc.FabricMySQLDriver兩個(gè)驅(qū)動(dòng)類
/****************【主線,重點(diǎn)關(guān)注】**********************/
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);
}
}
}
在上面的代碼中,我們可以看到Mysql的驅(qū)動(dòng)類加載主要是利用Java的SPI機(jī)制實(shí)現(xiàn)的,即利用ServiceLoader
來實(shí)現(xiàn)加載并實(shí)例化Mysql的驅(qū)動(dòng)類。
5.2 注冊(cè)Mysql的驅(qū)動(dòng)類
那么,上面的代碼只是Mysql驅(qū)動(dòng)類的加載和實(shí)例化,那么,驅(qū)動(dòng)類又是如何被注冊(cè)進(jìn)DriverManager
的registeredDrivers
集合的呢?
這時(shí),我們注意到com.mysql.jdbc.Driver
類里面也有個(gè)靜態(tài)代碼塊,即實(shí)例化該類時(shí)肯定會(huì)觸發(fā)該靜態(tài)代碼塊代碼的執(zhí)行,那么我們直接看下這個(gè)靜態(tài)代碼塊做了什么事情:
// com.mysql.jdbc.Driver.java
// Register ourselves with the DriverManager
static {
try {
// 將自己注冊(cè)進(jìn)DriverManager類的registeredDrivers集合
java.sql.DriverManager.registerDriver(new Driver());
} catch (SQLException E) {
throw new RuntimeException("Can't register driver!");
}
}
可以看到,原來就是Mysql驅(qū)動(dòng)類com.mysql.jdbc.Driver
在實(shí)例化的時(shí)候,利用執(zhí)行其靜態(tài)代碼塊的時(shí)機(jī)時(shí)將自己注冊(cè)進(jìn)DriverManager
的registeredDrivers
集合中。
好,繼續(xù)跟進(jìn)DriverManager
的registerDriver
方法:
// DriverManager.java
public static synchronized void registerDriver(java.sql.Driver driver)
throws SQLException {
// 繼續(xù)調(diào)用registerDriver方法
registerDriver(driver, null);
}
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) {
// 將driver驅(qū)動(dòng)類實(shí)例注冊(cè)進(jìn)registeredDrivers集合
registeredDrivers.addIfAbsent(new DriverInfo(driver, da));
} else {
// This is for compatibility with the original DriverManager
throw new NullPointerException();
}
println("registerDriver: " + driver);
}
分析到了這里,我們就明白了Java的SPI機(jī)制是如何加載Mysql的驅(qū)動(dòng)類的并如何將Mysql的驅(qū)動(dòng)類注冊(cè)進(jìn)DriverManager
的registeredDrivers
集合中的。
5.3 使用之前注冊(cè)的Mysql驅(qū)動(dòng)類連接數(shù)據(jù)庫(kù)
既然Mysql的驅(qū)動(dòng)類已經(jīng)被注冊(cè)進(jìn)來了,那么何時(shí)會(huì)被用到呢?
我們要連接Mysql數(shù)據(jù)庫(kù),自然需要用到Mysql的驅(qū)動(dòng)類,對(duì)吧。此時(shí)我們回到JDBC的測(cè)試代碼JdbcTest
類的connection = DriverManager.getConnection("jdbc:mysql://localhost:3306/jdbc", "root", "123456");
這句代碼中,看一下getConnection
的源碼:
// DriverManager.java
@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);
}
// 繼續(xù)調(diào)用getConnection方法來連接數(shù)據(jù)庫(kù)
return (getConnection(url, info, Reflection.getCallerClass()));
}
繼續(xù)跟進(jìn)getConnection
方法:
// DriverManager.java
private static Connection getConnection(
String url, java.util.Properties info, Class<?> caller) throws SQLException {
ClassLoader callerCL = caller != null ? caller.getClassLoader() : null;
synchronized(DriverManager.class) {
// synchronize loading of the correct classloader.
if (callerCL == null) {
callerCL = Thread.currentThread().getContextClassLoader();
}
}
if(url == null) {
throw new SQLException("The url cannot be null", "08001");
}
println("DriverManager.getConnection(\"" + url + "\")");
// Walk through the loaded registeredDrivers attempting to make a connection.
// Remember the first exception that gets raised so we can reraise it.
SQLException reason = null;
// 遍歷registeredDrivers集合,注意之前加載的Mysql驅(qū)動(dòng)類實(shí)例被注冊(cè)進(jìn)這個(gè)集合
for(DriverInfo aDriver : registeredDrivers) {
// If the caller does not have permission to load the driver then
// skip it.
// 判斷有無權(quán)限
if(isDriverAllowed(aDriver.driver, callerCL)) {
try {
println(" trying " + aDriver.driver.getClass().getName());
// 利用Mysql驅(qū)動(dòng)類來連接數(shù)據(jù)庫(kù)
/*************【主線,重點(diǎn)關(guān)注】*****************/
Connection con = aDriver.driver.connect(url, info);
// 只要連接上,那么加載的其余驅(qū)動(dòng)類比如FabricMySQLDriver將會(huì)忽略,因?yàn)橄旅嬷苯臃祷亓?/span>
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());
}
}
// if we got here nobody could connect.
if (reason != null) {
println("getConnection failed: " + reason);
throw reason;
}
println("getConnection: no suitable driver found for "+ url);
throw new SQLException("No suitable driver found for "+ url, "08001");
}
可以看到,DriverManager
的getConnection
方法會(huì)從registeredDrivers
集合中拿出剛才加載的Mysql驅(qū)動(dòng)類來連接數(shù)據(jù)庫(kù)。
好了,到了這里,JDBC驅(qū)動(dòng)加載的源碼就基本分析完了。
6 線程上下文類加載器
前面基本分析完了JDBC驅(qū)動(dòng)加載的源碼,但是還有一個(gè)很重要的知識(shí)點(diǎn)還沒講解,那就是破壞類加載機(jī)制的雙親委派模型的線程上下文類加載器。
我們都知道,JDBC規(guī)范的相關(guān)類(比如前面的java.sql.Driver
和java.sql.DriverManager
)都是在Jdk的rt.jar
包下,意味著這些類將由啟動(dòng)類加載器(BootstrapClassLoader)加載;而Mysql的驅(qū)動(dòng)類由外部數(shù)據(jù)庫(kù)廠商實(shí)現(xiàn),當(dāng)驅(qū)動(dòng)類被引進(jìn)項(xiàng)目時(shí)也是位于項(xiàng)目的classpath
中,此時(shí)啟動(dòng)類加載器肯定是不可能加載這些驅(qū)動(dòng)類的呀,此時(shí)該怎么辦?
由于類加載機(jī)制的雙親委派模型在這方面的缺陷,因此只能打破雙親委派模型了。因?yàn)轫?xiàng)目classpath
中的類是由應(yīng)用程序類加載器(AppClassLoader)來加載,所以我們可否"逆向"讓啟動(dòng)類加載器委托應(yīng)用程序類加載器去加載這些外部數(shù)據(jù)庫(kù)廠商的驅(qū)動(dòng)類呢?如果可以,我們?cè)鯓硬拍茏龅阶寙?dòng)類加載器委托應(yīng)用程序類加載器去加載classpath
中的類呢?
答案肯定是可以的,我們可以將應(yīng)用程序類加載器設(shè)置進(jìn)線程里面,即線程里面新定義一個(gè)類加載器的屬性contextClassLoader
,然后在某個(gè)時(shí)機(jī)將應(yīng)用程序類加載器設(shè)置進(jìn)線程的contextClassLoader
這個(gè)屬性里面,如果沒有設(shè)置的話,那么默認(rèn)就是應(yīng)用程序類加載器。然后啟動(dòng)類加載器去加載java.sql.Driver
和java.sql.DriverManager
等類時(shí),同時(shí)也會(huì)從當(dāng)前線程中取出contextClassLoader
即應(yīng)用程序類加載器去classpath
中加載外部廠商提供的JDBC驅(qū)動(dòng)類。因此,通過破壞類加載機(jī)制的雙親委派模型,利用線程上下文類加載器完美的解決了該問題。
此時(shí)我們?cè)倩剡^頭來看下在加載Mysql驅(qū)動(dòng)時(shí)是什么時(shí)候獲取的線程上下文類加載器呢?
答案就是在DriverManager
的loadInitialDrivers
方法調(diào)用了ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
這句代碼,而取出線程上下文類加載器就是在ServiceLoader
的load
方法中取出:
public static <S> ServiceLoader<S> load(Class<S> service) {
// 取出線程上下文類加載器取出的是contextClassLoader,而contextClassLoader裝的應(yīng)用程序類加載器
ClassLoader cl = Thread.currentThread().getContextClassLoader();
// 把剛才取出的線程上下文類加載器作為參數(shù)傳入,用于后去加載classpath中的外部廠商提供的驅(qū)動(dòng)類
return ServiceLoader.load(service, cl);
}
因此,到了這里,我們就明白了線程上下文類加載器在加載JDBC驅(qū)動(dòng)包中充當(dāng)?shù)淖饔昧恕4送?,我們?yīng)該知道,Java的絕大部分涉及SPI的加載都是利用線程上下文類加載器來完成的,比如JNDI,JCE,JBI等。
擴(kuò)展:打破類加載機(jī)制的雙親委派模型的還有代碼的熱部署等,另外,Tomcat的類加載機(jī)制也值得一讀。
注:若有些小伙伴對(duì)類加載機(jī)制的雙親委派模型不清楚的話,推薦完全理解雙親委派模型與自定義 ClassLoader這篇文了解下。
7 擴(kuò)展:Dubbo的SPI機(jī)制
前面也講到Dubbo框架身上處處是SPI機(jī)制的應(yīng)用,可以說處處都是擴(kuò)展點(diǎn),真的是把SPI機(jī)制應(yīng)用的淋漓盡致。但是Dubbo沒有采用默認(rèn)的Java的SPI機(jī)制,而是自己實(shí)現(xiàn)了一套SPI機(jī)制。
那么,Dubbo為什么沒有采用Java的SPI機(jī)制呢?
原因主要有兩個(gè):
-
Java的SPI機(jī)制會(huì)一次性實(shí)例化擴(kuò)展點(diǎn)所有實(shí)現(xiàn),如果有擴(kuò)展實(shí)現(xiàn)初始化很耗時(shí),但如果沒用上也加載,會(huì)很浪費(fèi)資源; -
Java的SPI機(jī)制沒有Ioc和AOP的支持,因此Dubbo用了自己的SPI機(jī)制:增加了對(duì)擴(kuò)展點(diǎn)IoC和AOP的支持,一個(gè)擴(kuò)展點(diǎn)可以直接setter注入其它擴(kuò)展點(diǎn)。
由于以上原因,Dubbo自定義了一套SPI機(jī)制,用于加載自己的擴(kuò)展點(diǎn)。關(guān)于Dubbo的SPI機(jī)制這里不再詳述,感興趣的小伙伴們可以去Dubbo官網(wǎng)看看是如何擴(kuò)展Dubbo的SPI的?還有其官網(wǎng)也有Duboo的SPI的源碼分析文章。
8 小結(jié)
好了,Java的SPI機(jī)制就解讀到這里了,先將前面的知識(shí)點(diǎn)再總結(jié)下:
1,Java的SPI機(jī)制的使用;
2,Java的SPI機(jī)制的原理;
3,JDBC驅(qū)動(dòng)的加載原理;
4,簡(jiǎn)述了Duboo的SPI機(jī)制。
原創(chuàng)不易,幫忙點(diǎn)個(gè)贊唄!
由于筆者水平有限,若文中有錯(cuò)誤還請(qǐng)指出,謝謝。
參考:
1,http://dubbo.apache.org/zh-cn/docs/source_code_guide/dubbo-spi.html
2,《深入理解Java虛擬機(jī)》
特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容,還沒關(guān)注的小伙伴,可以長(zhǎng)按關(guān)注一下:
長(zhǎng)按訂閱更多精彩▼
如有收獲,點(diǎn)個(gè)在看,誠(chéng)摯感謝
免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn),不代表本平臺(tái)立場(chǎng),如有問題,請(qǐng)聯(lián)系我們,謝謝!