注：該源碼分析對應JDK版本為1.8

1 引言

這是【源碼筆記】的JDK源碼解讀的第一篇文章，本篇我們來探究Java的SPI機制的相關源碼。

2 什麼是SPI機制

那麼，什麼是SPI機制呢？

SPI是Service Provider Interface 的簡稱，即服務提供者接口的意思。根據字面意思我們可能還有點困惑，SPI說白了就是一種擴充機制，我們在相應配置檔案中定義好某個接口的實作類，然後再根據這個接口去這個配置檔案中加載這個執行個體類并執行個體化，其實SPI就是這麼一個東西。說到SPI機制，我們最常見的就是Java的SPI機制，此外，還有Dubbo和SpringBoot自定義的SPI機制。

有了SPI機制，那麼就為一些架構的靈活擴充提供了可能，而不必将架構的一些實作類寫死在代碼裡面。

那麼，某些架構是如何利用SPI機制來做到靈活擴充的呢？下面舉幾個栗子來闡述下：

JDBC驅動加載案例：利用Java的SPI機制，我們可以根據不同的資料庫廠商來引入不同的JDBC驅動包；
SpringBoot的SPI機制：我們可以在 spring.factories 中加上我們自定義的自動配置類，事件監聽器或初始化器等；
Dubbo的SPI機制：Dubbo更是把SPI機制應用的淋漓盡緻，Dubbo基本上自身的每個功能點都提供了擴充點，比如提供了叢集擴充，路由擴充和負載均衡擴充等差不多接近30個擴充點。如果Dubbo的某個内置實作不符合我們的需求，那麼我們隻要利用其SPI機制将我們的實作替換掉Dubbo的實作即可。

上面的三個栗子先讓我們直覺感受下某些架構利用SPI機制是如何做到靈活擴充的。

3 如何使用Java的SPI？

我們先來看看如何使用Java自帶的SPI。

先定義一個

Developer

接口

// Developer.java

package com.ymbj.spi;

public interface Developer {
    void sayHi();
}

再定義兩個

Developer

接口的兩個實作類：

// 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.");
    }
}

然後再在項目

resources

目錄下建立一個

META-INF/services

檔案夾，然後再建立一個以

Developer

接口的全限定名命名的檔案，檔案内容為：

// com.ymbj.spi.Developer檔案

com.ymbj.spi.JavaDeveloper
com.ymbj.spi.PythonDeveloper

最後我們再建立一個測試類

JdkSPITest

：

// JdkSPITest.java

public class JdkSPITest {

    @Test
    public void testSayHi() throws Exception {
        ServiceLoader<Developer> serviceLoader = ServiceLoader.load(Developer.class);
        serviceLoader.forEach(Developer::sayHi);
    }
}

運作上面那個測試類，運作成功結果如下截圖所示：

由上面簡單的Demo我們知道了如何使用Java的SPI機制來實作擴充點加載，下面推薦一篇文章

JAVA拾遺--關于SPI機制

,通過這篇文章,相信大家對Java的SPI會有一個比較深刻的了解，特别是JDBC加載驅動這方面。

4 Java的SPI機制的源碼解讀

通過前面擴充

Developer

接口的簡單Demo，我們看到Java的SPI機制實作跟

ServiceLoader

這個類有關，那麼我們先來看下

ServiceLoader

的類結構代碼：

// ServiceLoader實作了【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;
    // 構造方法
    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();
    }
    
    // ...暫時省略相關代碼
    
    // ServiceLoader的内部類LazyIterator,實作了【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() {
            // ...暫時省略相關代碼
        }
        // 覆寫Iterator接口的next方法
        public S next() {
            // ...暫時省略相關代碼
        }
        // 覆寫Iterator接口的remove方法
        public void remove() {
            // ...暫時省略相關代碼
        }

    }

    // 覆寫Iterable接口的iterator方法，傳回一個疊代器
    public Iterator<S> iterator() {
        // ...暫時省略相關代碼
    }

    // ...暫時省略相關代碼

}

可以看到，

ServiceLoader

實作了

Iterable

接口，覆寫其

iterator

方法能産生一個疊代器；同時

ServiceLoader

有一個内部類

LazyIterator

，而

LazyIterator

又實作了

Iterator

接口，說明

LazyIterator

是一個疊代器。

4.1 ServiceLoader.load方法，為加載服務提供者實作類做前期準備

那麼我們現在開始探究Java的SPI機制的源碼，

先來看

JdkSPITest

的第一句代碼

ServiceLoader<Developer> serviceLoader = ServiceLoader.load(Developer.class);

中的

ServiceLoader.load(Developer.class);

的源碼：

// ServiceLoader.java

public static <S> ServiceLoader<S> load(Class<S> service) {
    //擷取目前線程上下文類加載器 
    ClassLoader cl = Thread.currentThread().getContextClassLoader();
    // 将service接口類和線程上下文類加載器作為參數傳入，繼續調用load方法
    return ServiceLoader.load(service, cl);
}

我們再來看下

ServiceLoader.load(service, cl);

方法：

// ServiceLoader.java

public static <S> ServiceLoader<S> load(Class<S> service,
                                        ClassLoader loader)
{
    // 将service接口類和線程上下文類加載器作為構造參數，建立了一個ServiceLoader對象
    return new ServiceLoader<>(service, loader);
}

繼續看

new ServiceLoader<>(service, loader);

是如何建構的？

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

可以看到在建構

ServiceLoader

對象時除了給其成員屬性指派外，還調用了

reload

// ServiceLoader.java

public void reload() {
    providers.clear();
    lookupIterator = new LazyIterator(service, loader);
}

可以看到在

reload

方法中又建立了一個

LazyIterator

對象，然後指派給

lookupIterator

。

// ServiceLoader$LazyIterator.java

private LazyIterator(Class<S> service, ClassLoader loader) {
    this.service = service;
    this.loader = loader;
}

LazyIterator

對象時，也隻是給其成員變量

service

和

loader

屬性指派呀，我們一路源碼跟下來，也沒有看到去

META-INF/services

檔案夾加載

Developer

接口的實作類！這就奇怪了，我們都被

ServiceLoader

的

load

方法名騙了。

還記得分析前面的代碼時建立了一個

LazyIterator

對象嗎？

Lazy

顧名思義是懶的意思，

Iterator

就是疊代的意思。我們此時猜測那麼

LazyIterator

對象的作用應該就是在疊代的時候再去加載

Developer

接口的實作類了。

4.2 ServiceLoader.iterator方法，實作服務提供者實作類的懶加載

我們現在再來看

JdkSPITest

的第二句代碼

serviceLoader.forEach(Developer::sayHi);

，執行這句代碼後最終會調用

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;
            // 調用lookupIterator即LazyIterator的hasNext方法
            // 可以看到是委托給LazyIterator的hasNext方法來實作
            return lookupIterator.hasNext();
        }

        public S next() {
            if (knownProviders.hasNext())
                return knownProviders.next().getValue();
            // 調用lookupIterator即LazyIterator的next方法
            // 可以看到是委托給LazyIterator的next方法來實作
            return lookupIterator.next();
        }

        public void remove() {
            throw new UnsupportedOperationException();
        }

    };
}

可以看到調用

serviceLoader

iterator

方法會傳回一個匿名的疊代器對象，而這個匿名疊代器對象其實相當于一個門面類，其覆寫的

hasNext

next

方法又分别委托

LazyIterator

hasNext

next

方法來實作了。

我們繼續調試，發現接下來會進入

LazyIterator

hasNext

// serviceLoader$LazyIterator.java

public boolean hasNext() {
    if (acc == null) {
        // 調用hasNextService方法
        return hasNextService();
    } else {
        PrivilegedAction<Boolean> action = new PrivilegedAction<Boolean>() {
            public Boolean run() { return hasNextService(); }
        };
        return AccessController.doPrivileged(action, acc);
    }
}

繼續跟進

hasNextService

// serviceLoader$LazyIterator.java

private boolean hasNextService() {
    if (nextName != null) {
        return true;
    }
    if (configs == null) {
        try {
            // PREFIX = "META-INF/services/"
            // service.getName()即接口的全限定名
            // 還記得前面的代碼建構LazyIterator對象時已經給其成員屬性service指派嗎
            String fullName = PREFIX + service.getName();
            // 加載META-INF/services/目錄下的接口檔案中的服務提供者類
            if (loader == null)
                configs = ClassLoader.getSystemResources(fullName);
            else
                // 還記得前面的代碼建構LazyIterator對象時已經給其成員屬性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/目錄下的接口檔案中的服務提供者類并指派給pending屬性
        pending = parse(service, configs.nextElement());
    }
    // 然後取出一個全限定名指派給LazyIterator的成員變量nextName
    nextName = pending.next();
    return true;
}

可以看到在執行

LazyIterator

hasNextService

方法時最終将去

META-INF/services/

目錄下加載接口檔案的内容即加載服務提供者實作類的全限定名，然後取出一個服務提供者實作類的全限定名指派給

LazyIterator

的成員變量

nextName

。到了這裡，我們就明白了

LazyIterator

的作用真的是懶加載，在用到的時候才會去加載。

思考：為何這裡要用懶加載呢？懶加載的思想是怎樣的呢？懶加載有啥好處呢？你還能舉出其他懶加載的案例嗎？

同樣，執行完

LazyIterator

hasNext

方法後，會繼續執行

LazyIterator

next

// serviceLoader$LazyIterator.java

public S next() {
    if (acc == null) {
        // 調用nextService方法
        return nextService();
    } else {
        PrivilegedAction<S> action = new PrivilegedAction<S>() {
            public S run() { return nextService(); }
        };
        return AccessController.doPrivileged(action, acc);
    }
}

我們繼續跟進

nextService

// serviceLoader$LazyIterator.java

private S nextService() {
    if (!hasNextService())
        throw new NoSuchElementException();
    // 還記得在hasNextService方法中為nextName指派過服務提供者實作類的全限定名嗎
    String cn = nextName;
    nextName = null;
    Class<?> c = null;
    try {
        // 【1】去classpath中根據傳入的類加載器和服務提供者實作類的全限定名去加載服務提供者實作類
        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】執行個體化剛才加載的服務提供者實作類，并進行轉換
        S p = service.cast(c.newInstance());
        // 【3】最終将執行個體化後的服務提供者實作類放進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

方法最終将執行個體化之前加載的服務提供者實作類，并放進

providers

集合中，随後再調用服務提供者實作類的方法（比如這裡指

JavaDeveloper

sayHi

方法）。注意，這裡是加載一個服務提供者實作類後，若

main

函數中有調用該服務提供者實作類的方法的話，緊接着會調用其方法；然後繼續執行個體化下一個服務提供者類。

設計模式：可以看到，Java的SPI機制實作代碼中應用了疊代器模式，疊代器模式屏蔽了各種存儲對象的内部結構差異，提供一個統一的視圖來周遊各個存儲對象（存儲對象可以為集合，數組等）。 java.util.Iterator 也是疊代器模式的實作：同時Java的各個集合類一般實作了 Iterable 接口，實作了其 iterator 方法進而獲得 Iterator 接口的實作類對象（一般為集合内部類），然後再利用 Iterator 對象的實作類的 hasNext next 方法來周遊集合元素。

5 JDBC驅動加載源碼解讀

前面分析了Java的SPI機制的源碼實作，現在我們再來看下Java的SPI機制的實際案例的應用。

我們都知道，JDBC驅動加載是Java的SPI機制的典型應用案例。JDBC主要提供了一套接口規範，而這套規範的api在java的核心庫（

rt.jar

）中實作，而不同的資料庫廠商隻要編寫符合這套JDBC接口規範的驅動代碼，那麼就可以用Java語言來連接配接資料庫了。

java的核心庫（

rt.jar

）中跟JDBC驅動加載的最核心的接口和類分别是

java.sql.Driver

接口和

java.sql.DriverManager

類，其中

java.sql.Driver

是各個資料庫廠商的驅動類要實作的接口，而

DriverManager

是用來管理資料庫的驅動類的，值得注意的是

DriverManager

這個類有一個

registeredDrivers

集合屬性，用來存儲資料庫的驅動類。

// DriverManager.java

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

這裡以加載Mysql驅動為例來分析JDBC驅動加載的源碼。

我們的項目引入

mysql-connector-java

依賴（這裡的版本是

5.1.47

）後，那麼Mysql的驅動實作類檔案如下圖所示：

可以看到Mysql的驅動包中有兩個

Driver

驅動類，分别是

com.mysql.jdbc.Driver

com.mysql.fabric.jdbc.FabricMySQLDriver

，預設情況下一般我們隻用到前者。

5.1 利用Java的SPI加載Mysql的驅動類

那麼接下來我們就來探究下JDBC驅動加載的代碼是如何實作的。

先來看一下一個簡單的JDBC的測試代碼：

// JdbcTest.java

public class JdbcTest {
    public static void main(String[] args) {
        Connection connection = null;  
        Statement statement = null;
        ResultSet rs = null;

        try {
            // 注意：在JDBC 4.0規範中，這裡可以不用再像以前那樣編寫顯式加載資料庫的代碼了
            // Class.forName("com.mysql.jdbc.Driver");
            // 擷取資料庫連接配接，注意【這裡将會加載mysql的驅動包】
            /***************【主線，切入點】****************/
            connection = DriverManager.getConnection("jdbc:mysql://localhost:3306/jdbc", "root", "123456");
            // 建立Statement語句
            statement = connection.createStatement();
            // 執行查詢語句
            rs = statement.executeQuery("select * from user");
            // 周遊查詢結果集
            while(rs.next()){
                String name = rs.getString("name");
                System.out.println(name);
            }
        } catch(Exception e) {
            e.printStackTrace();
        } finally {
            // ...省略釋放資源的代碼
        }
    }
}

在

JdbcTest

main

函數調用

DriverManager

getConnection

方法時，此時必然會先執行

DriverManager

類的靜态代碼塊的代碼，然後再執行

getConnection

方法，那麼先來看下

DriverManager

的靜态代碼塊：

// DriverManager.java

static {
    // 加載驅動實作類
    loadInitialDrivers();
    println("JDBC DriverManager initialized");
}

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() {
            // 來到這裡，是不是感覺似曾相識，對，沒錯，我們在前面的JdkSPITest代碼中執行過下面的兩句代碼
            // 這句代碼前面已經分析過，這裡不會真正加載服務提供者實作類
            // 而是執行個體化一個ServiceLoader對象且執行個體化一個LazyIterator對象用于懶加載
            ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
            // 調用ServiceLoader的iterator方法，在疊代的同時，也會去加載并執行個體化META-INF/services/java.sql.Driver檔案
            // 的com.mysql.jdbc.Driver和com.mysql.fabric.jdbc.FabricMySQLDriver兩個驅動類
            /****************【主線，重點關注】**********************/
            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的驅動類加載主要是利用Java的SPI機制實作的，即利用

ServiceLoader

來實作加載并執行個體化Mysql的驅動類。

5.2 注冊Mysql的驅動類

那麼，上面的代碼隻是Mysql驅動類的加載和執行個體化，那麼，驅動類又是如何被注冊進

DriverManager

registeredDrivers

集合的呢？

這時，我們注意到

com.mysql.jdbc.Driver

類裡面也有個靜态代碼塊，即執行個體化該類時肯定會觸發該靜态代碼塊代碼的執行，那麼我們直接看下這個靜态代碼塊做了什麼事情：

// com.mysql.jdbc.Driver.java

// Register ourselves with the DriverManager
static {
    try {
        // 将自己注冊進DriverManager類的registeredDrivers集合
        java.sql.DriverManager.registerDriver(new Driver());
    } catch (SQLException E) {
        throw new RuntimeException("Can't register driver!");
    }
}

可以看到，原來就是Mysql驅動類

com.mysql.jdbc.Driver

在執行個體化的時候，利用執行其靜态代碼塊的時機時将自己注冊進

DriverManager

registeredDrivers

集合中。

好，繼續跟進

DriverManager

registerDriver

// DriverManager.java

public static synchronized void registerDriver(java.sql.Driver driver)
    throws SQLException {
    // 繼續調用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驅動類執行個體注冊進registeredDrivers集合
        registeredDrivers.addIfAbsent(new DriverInfo(driver, da));
    } else {
        // This is for compatibility with the original DriverManager
        throw new NullPointerException();
    }
    println("registerDriver: " + driver);
}

分析到了這裡，我們就明白了Java的SPI機制是如何加載Mysql的驅動類的并如何将Mysql的驅動類注冊進

DriverManager

registeredDrivers

集合中的。

5.3 使用之前注冊的Mysql驅動類連接配接資料庫

既然Mysql的驅動類已經被注冊進來了，那麼何時會被用到呢？

我們要連接配接Mysql資料庫，自然需要用到Mysql的驅動類，對吧。此時我們回到JDBC的測試代碼

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);
    }
    // 繼續調用getConnection方法來連接配接資料庫
    return (getConnection(url, info, Reflection.getCallerClass()));
}

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驅動類執行個體被注冊進這個集合
        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());
                    // 利用Mysql驅動類來連接配接資料庫
                    /*************【主線，重點關注】*****************/
                    Connection con = aDriver.driver.connect(url, info);
                    // 隻要連接配接上，那麼加載的其餘驅動類比如FabricMySQLDriver将會忽略，因為下面直接傳回了
                    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

方法會從

registeredDrivers

集合中拿出剛才加載的Mysql驅動類來連接配接資料庫。

好了，到了這裡，JDBC驅動加載的源碼就基本分析完了。

6 線程上下文類加載器

前面基本分析完了JDBC驅動加載的源碼，但是還有一個很重要的知識點還沒講解，那就是破壞類加載機制的雙親委派模型的線程上下文類加載器。

我們都知道，JDBC規範的相關類（比如前面的

java.sql.Driver

java.sql.DriverManager

）都是在Jdk的

rt.jar

包下，意味着這些類将由啟動類加載器(BootstrapClassLoader)加載；而Mysql的驅動類由外部資料庫廠商實作，當驅動類被引進項目時也是位于項目的

classpath

中,此時啟動類加載器肯定是不可能加載這些驅動類的呀，此時該怎麼辦？

由于類加載機制的雙親委派模型在這方面的缺陷，是以隻能打破雙親委派模型了。因為項目

classpath

中的類是由應用程式類加載器(AppClassLoader)來加載，是以我們可否"逆向"讓啟動類加載器委托應用程式類加載器去加載這些外部資料庫廠商的驅動類呢？如果可以，我們怎樣才能做到讓啟動類加載器委托應用程式類加載器去加載

classpath

中的類呢？

答案肯定是可以的，我們可以将應用程式類加載器設定進線程裡面，即線程裡面新定義一個類加載器的屬性

contextClassLoader

，然後在某個時機将應用程式類加載器設定進線程的

contextClassLoader

這個屬性裡面，如果沒有設定的話，那麼預設就是應用程式類加載器。然後啟動類加載器去加載

java.sql.Driver

java.sql.DriverManager

等類時，同時也會從目前線程中取出

contextClassLoader

即應用程式類加載器去

classpath

中加載外部廠商提供的JDBC驅動類。是以，通過破壞類加載機制的雙親委派模型，利用線程上下文類加載器完美的解決了該問題。

此時我們再回過頭來看下在加載Mysql驅動時是什麼時候擷取的線程上下文類加載器呢？

答案就是在

DriverManager

loadInitialDrivers

方法調用了

ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);

這句代碼，而取出線程上下文類加載器就是在

ServiceLoader

load

方法中取出：

public static <S> ServiceLoader<S> load(Class<S> service) {
    // 取出線程上下文類加載器取出的是contextClassLoader，而contextClassLoader裝的應用程式類加載器
    ClassLoader cl = Thread.currentThread().getContextClassLoader();
    // 把剛才取出的線程上下文類加載器作為參數傳入，用于後去加載classpath中的外部廠商提供的驅動類
    return ServiceLoader.load(service, cl);
}

是以，到了這裡，我們就明白了線程上下文類加載器在加載JDBC驅動包中充當的作用了。此外，我們應該知道，Java的絕大部分涉及SPI的加載都是利用線程上下文類加載器來完成的，比如JNDI,JCE,JBI等。

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

注：若有些小夥伴對類加載機制的雙親委派模型不清楚的話，推薦

完全了解雙親委派模型與自定義 ClassLoader

這篇文了解下。

7 擴充：Dubbo的SPI機制

前面也講到Dubbo架構身上處處是SPI機制的應用，可以說處處都是擴充點，真的是把SPI機制應用的淋漓盡緻。但是Dubbo沒有采用預設的Java的SPI機制，而是自己實作了一套SPI機制。

那麼，Dubbo為什麼沒有采用Java的SPI機制呢？

原因主要有兩個：

Java的SPI機制會一次性執行個體化擴充點所有實作，如果有擴充實作初始化很耗時，但如果沒用上也加載，會很浪費資源;
Java的SPI機制沒有Ioc和AOP的支援，是以Dubbo用了自己的SPI機制：增加了對擴充點IoC和AOP的支援，一個擴充點可以直接setter注入其它擴充點。

由于以上原因，Dubbo自定義了一套SPI機制，用于加載自己的擴充點。關于Dubbo的SPI機制這裡不再詳述，感興趣的小夥伴們可以去Dubbo官網看看是如何擴充Dubbo的SPI的？還有其官網也有Duboo的SPI的源碼分析文章。

8 小結

好了，Java的SPI機制就解讀到這裡了，先将前面的知識點再總結下：

Java的SPI機制的使用；
Java的SPI機制的原理；
JDBC驅動的加載原理；
線程上下文類加載器在JDBC驅動加載中的作用；
簡述了Duboo的SPI機制。

原創不易，幫忙點個贊呗！

由于筆者水準有限，若文中有錯誤還請指出，謝謝。

參考：

1，

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

2，《深入了解Java虛拟機》

Java是如何實作自己的SPI機制的？ JDK源碼（一）1 引言2 什麼是SPI機制3 如何使用Java的SPI？4 Java的SPI機制的源碼解讀5 JDBC驅動加載源碼解讀6 線程上下文類加載器7 擴充：Dubbo的SPI機制8 小結

1 引言

2 什麼是SPI機制

3 如何使用Java的SPI？

4 Java的SPI機制的源碼解讀

4.1 ServiceLoader.load方法，為加載服務提供者實作類做前期準備

4.2 ServiceLoader.iterator方法，實作服務提供者實作類的懶加載

5 JDBC驅動加載源碼解讀

5.1 利用Java的SPI加載Mysql的驅動類

5.2 注冊Mysql的驅動類

5.3 使用之前注冊的Mysql驅動類連接配接資料庫

6 線程上下文類加載器

7 擴充：Dubbo的SPI機制

8 小結

繼續閱讀

【python】【資料處理】畫多元資料分布圖

NOSQL安全攻擊

mybatis_入門程式Mybatis入門

mysql使用source指令導入.sql檔案

AOP程式設計_Android優雅權限架構(1)概念基礎，2021金三銀四前言正文大綱正文

登入plsql 報錯 the account is locked --使用者被鎖

Effective Java 8:通用程式設計

SequoiaDB巨杉資料庫C++驅動概述

OOM三種類型

工廠模式-三種類型

【python】netconf協定對接管理裝置

「Python 網絡自動化」NETCONF —— Python 使用 NETCONF 管理配置 H3C 網絡裝置

【遞歸】高效率求2的n次幂

win10本地scala和spark安裝安裝scala安裝spark

scala (3) Function 和 Method

在python中建立excel并寫入