注：該源碼分析對(duì)應(yīng)JDK版本為1.8

?

1 引言

本篇我們來(lái)探究Java的SPI機(jī)制的相關(guān)源碼。

2 什么是SPI機(jī)制

那么，什么是SPI機(jī)制呢？

SPI是Service Provider Interface 的簡(jiǎn)稱，即服務(wù)提供者接口的意思。根據(jù)字面意思我們可能還有點(diǎn)困惑，SPI說(shuō)白了就是一種擴(kuò)展機(jī)制，我們?cè)谙鄳?yīng)配置文件中定義好某個(gè)接口的實(shí)現(xiàn)類，然后再根據(jù)這個(gè)接口去這個(gè)配置文件中加載這個(gè)實(shí)例類并實(shí)例化，其實(shí)SPI就是這么一個(gè)東西。說(shuō)到SPI機(jī)制，我們最常見(jiàn)的就是Java的SPI機(jī)制，此外，還有Dubbo和SpringBoot自定義的SPI機(jī)制。

有了SPI機(jī)制，那么就為一些框架的靈活擴(kuò)展提供了可能，而不必將框架的一些實(shí)現(xiàn)類寫(xiě)死在代碼里面。

那么，某些框架是如何利用SPI機(jī)制來(lái)做到靈活擴(kuò)展的呢？下面舉幾個(gè)栗子來(lái)闡述下：

JDBC驅(qū)動(dòng)加載案例：利用Java的SPI機(jī)制，我們可以根據(jù)不同的數(shù)據(jù)庫(kù)廠商來(lái)引入不同的JDBC驅(qū)動(dòng)包；

SpringBoot的SPI機(jī)制：我們可以在spring.factories中加上我們自定義的自動(dòng)配置類，事件監(jiān)聽(tīng)器或初始化器等；

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？

我們先來(lái)看看如何使用Java自帶的SPI。先定義一個(gè)Developer接口

// Developer.javapackage com.ymbj.spi;public interface Developer {void sayHi(); }

再定義兩個(gè)Developer接口的兩個(gè)實(shí)現(xiàn)類：

// JavaDeveloper.javapackage com.ymbj.spi;public class JavaDeveloper implements Developer {@Overridepublic void sayHi() {System.out.println("Hi, I am a Java Developer.");} } // PythonDeveloper.javapackage com.ymbj.spi;public class PythonDeveloper implements Developer {@Overridepublic 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.javapublic class JdkSPITest {@Testpublic 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ī)制來(lái)實(shí)現(xiàn)擴(kuò)展點(diǎn)加載。

4 Java的SPI機(jī)制的源碼分析

通過(guò)前面擴(kuò)展Developer接口的簡(jiǎn)單Demo，我們看到Java的SPI機(jī)制實(shí)現(xiàn)跟ServiceLoader這個(gè)類有關(guān)，那么我們先來(lái)看下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 loadedprivate final Class<S> service;// The class loader used to locate, load, and instantiate providersprivate final ClassLoader loader;// The access control context taken when the ServiceLoader is createdprivate final AccessControlContext acc;// Cached providers, in instantiation orderprivate LinkedHashMap<String,S> providers = new LinkedHashMap<>();// The current lazy-lookup iteratorprivate 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 lookupprivate class LazyIteratorimplements 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;}// 覆寫(xiě)Iterator接口的hasNext方法public boolean hasNext() {// ...暫時(shí)省略相關(guān)代碼}// 覆寫(xiě)Iterator接口的next方法public S next() {// ...暫時(shí)省略相關(guān)代碼}// 覆寫(xiě)Iterator接口的remove方法public void remove() {// ...暫時(shí)省略相關(guān)代碼}}// 覆寫(xiě)Iterable接口的iterator方法，返回一個(gè)迭代器public Iterator<S> iterator() {// ...暫時(shí)省略相關(guān)代碼}// ...暫時(shí)省略相關(guān)代碼}

可以看到，ServiceLoader實(shí)現(xiàn)了Iterable接口，覆寫(xiě)其iterator方法能產(chǎn)生一個(gè)迭代器；同時(shí)ServiceLoader有一個(gè)內(nèi)部類LazyIterator，而LazyIterator又實(shí)現(xiàn)了Iterator接口，說(shuō)明LazyIterator是一個(gè)迭代器。

4.1 ServiceLoader.load方法，為加載服務(wù)提供者實(shí)現(xiàn)類做前期準(zhǔn)備

那么我們現(xiàn)在開(kāi)始探究Java的SPI機(jī)制的源碼， 先來(lái)看JdkSPITest的第一句代碼ServiceLoader<Developer> serviceLoader = ServiceLoader.load(Developer.class);中的ServiceLoader.load(Developer.class)的源碼：

// ServiceLoader.javapublic 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è)賮?lái)看下ServiceLoader.load(service, cl);方法：

// ServiceLoader.javapublic 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.javaprivate 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.javapublic void reload() {providers.clear();lookupIterator = new LazyIterator(service, loader); }

可以看到在reload方法中又新建了一個(gè)LazyIterator對(duì)象，然后賦值給lookupIterator。

// ServiceLoader$LazyIterator.javaprivate LazyIterator(Class<S> service, ClassLoader loader) {this.service = service;this.loader = loader; }

可以看到在構(gòu)建LazyIterator對(duì)象時(shí)，也只是給其成員變量service和loader屬性賦值呀，我們一路源碼跟下來(lái)，也沒(méi)有看到去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)在再來(lái)看JdkSPITest的第二句代碼serviceLoader.forEach(Developer::sayHi);，執(zhí)行這句代碼后最終會(huì)調(diào)用serviceLoader的iterator方法：

// serviceLoader.javapublic 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方法來(lái)實(shí)現(xiàn)return lookupIterator.hasNext();}public S next() {if (knownProviders.hasNext())return knownProviders.next().getValue();// 調(diào)用lookupIterator即LazyIterator的next方法// 可以看到是委托給LazyIterator的next方法來(lái)實(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è)門面類，其覆寫(xiě)的hasNext和next方法又分別委托LazyIterator的hasNext和next方法來(lái)實(shí)現(xiàn)了。

我們繼續(xù)調(diào)試，發(fā)現(xiàn)接下來(lái)會(huì)進(jìn)入LazyIterator的hasNext方法：

// serviceLoader$LazyIterator.javapublic 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.javaprivate 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的成員變量nextNamenextName = 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.javapublic 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.javaprivate S nextService() {if (!hasNextService())throw new NoSuchElementException();// 還記得在hasNextService方法中為nextName賦值過(guò)服務(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)一的視圖來(lái)遍歷各個(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方法來(lái)遍歷集合元素。

5 JDBC驅(qū)動(dòng)加載源碼解讀

前面分析了Java的SPI機(jī)制的源碼實(shí)現(xiàn)，現(xiàn)在我們?cè)賮?lái)看下Java的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ù)廠商只要編寫(xiě)符合這套JDBC接口規(guī)范的驅(qū)動(dòng)代碼，那么就可以用Java語(yǔ)言來(lái)連接數(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是用來(lái)管理數(shù)據(jù)庫(kù)的驅(qū)動(dòng)類的，值得注意的是DriverManager這個(gè)類有一個(gè)registeredDrivers集合屬性，用來(lái)存儲(chǔ)Mysql的驅(qū)動(dòng)類。

// DriverManager.java// List of registered JDBC drivers private final static CopyOnWriteArrayList<DriverInfo> registeredDrivers = new CopyOnWriteArrayList<>();

這里以加載Mysql驅(qū)動(dòng)為例來(lái)分析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)類

那么接下來(lái)我們就來(lái)探究下JDBC驅(qū)動(dòng)加載的代碼是如何實(shí)現(xiàn)的。

先來(lái)看一下一個(gè)簡(jiǎn)單的JDBC的測(cè)試代碼：

// JdbcTest.javapublic class JdbcTest {public static void main(String[] args) {Connection connection = null;Statement statement = null;ResultSet rs = null;try {// 注意：在JDBC 4.0規(guī)范中，這里可以不用再像以前那樣編寫(xiě)顯式加載數(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語(yǔ)句statement = connection.createStatement();// 執(zhí)行查詢語(yǔ)句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í)行g(shù)etConnection方法，那么先來(lái)看下DriverManager的靜態(tài)代碼塊：

// DriverManager.javastatic {// 加載驅(qū)動(dòng)實(shí)現(xiàn)類loadInitialDrivers(); println("JDBC DriverManager initialized"); }

繼續(xù)跟進(jìn)loadInitialDrivers的代碼：

// DriverManager.javaprivate 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() {// 來(lái)到這里，是不是感覺(jué)似曾相識(shí)，對(duì)，沒(méi)錯(cuò)，我們?cè)谇懊娴腏dkSPITest代碼中執(zhí)行過(guò)下面的兩句代碼// 這句代碼前面已經(jīng)分析過(guò)，這里不會(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來(lái)實(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!");} }

可以看到，原來(lái)就是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.javapublic 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 DriverManagerthrow 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)來(lái)了，那么何時(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方法來(lái)連接數(shù)據(jù)庫(kù)return (getConnection(url, info, Reflection.getCallerClass())); }

繼續(xù)跟進(jìn)getConnection方法：

// DriverManager.javaprivate 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.// 判斷有無(wú)權(quán)限if(isDriverAllowed(aDriver.driver, callerCL)) {try {println(" trying " + aDriver.driver.getClass().getName());// 利用Mysql驅(qū)動(dòng)類來(lái)連接數(shù)據(jù)庫(kù)/*************【主線，重點(diǎn)關(guān)注】*****************/Connection con = aDriver.driver.connect(url, info);// 只要連接上，那么加載的其余驅(qū)動(dòng)類比如FabricMySQLDriver將會(huì)忽略，因?yàn)橄旅嬷苯臃祷亓薸f (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)類來(lái)連接數(shù)據(jù)庫(kù)。

好了，到了這里，JDBC驅(qū)動(dòng)加載的源碼就基本分析完了。

6 線程上下文類加載器

前面基本分析完了JDBC驅(qū)動(dòng)加載的源碼，但是還有一個(gè)很重要的知識(shí)點(diǎn)還沒(méi)講解，那就是破壞類加載機(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)來(lái)加載，所以我們可否"逆向"讓啟動(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è)屬性里面，如果沒(méi)有設(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)類。因此，通過(guò)破壞類加載機(jī)制的雙親委派模型，利用線程上下文類加載器完美的解決了該問(wèn)題。

此時(shí)我們?cè)倩剡^(guò)頭來(lái)看下在加載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ù)淖饔昧?。此?#xff0c;我們應(yīng)該知道，Java的絕大部分涉及SPI的加載都是利用線程上下文類加載器來(lái)完成的，比如JNDI,JCE,JBI等。

擴(kuò)展：打破類加載機(jī)制的雙親委派模型的還有代碼的熱部署等，另外，Tomcat的類加載機(jī)制也值得一讀。

7 擴(kuò)展：Dubbo的SPI機(jī)制

前面也講到Dubbo框架身上處處是SPI機(jī)制的應(yīng)用，可以說(shuō)處處都是擴(kuò)展點(diǎn)，真的是把SPI機(jī)制應(yīng)用的淋漓盡致。但是Dubbo沒(méi)有采用默認(rèn)的Java的SPI機(jī)制，而是自己實(shí)現(xiàn)了一套SPI機(jī)制。

那么，Dubbo為什么沒(méi)有采用Java的SPI機(jī)制呢？

原因主要有兩個(gè)：

Java的SPI機(jī)制會(huì)一次性實(shí)例化擴(kuò)展點(diǎn)所有實(shí)現(xiàn)，如果有擴(kuò)展實(shí)現(xiàn)初始化很耗時(shí)，但如果沒(méi)用上也加載，會(huì)很浪費(fèi)資源;

Java的SPI機(jī)制沒(méi)有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ī)制。

參考：

1，http://dubbo.apache.org/zh-cn/docs/source_code_guide/dubbo-spi.html

2，《深入理解Java虛擬機(jī)》

有道無(wú)術(shù)，術(shù)可成；有術(shù)無(wú)道，止于術(shù)

歡迎大家關(guān)注Java之道公眾號(hào)

好文章，我在看??

總結(jié)

以上是生活随笔為你收集整理的Java是如何实现自己的SPI机制的？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。