Java SPI機制總結系列之萬字最詳細圖解Java SPI機制源碼分析

原創/朱季謙

我在《Java SPI機制總結系列之開發入門實例》一文當中，分享了Java SPI的玩法，但是這只是基於表面的應用。若要明白其中的原理實現，還需深入到底層源碼，分析一番。

這裏再重溫一下SPI機制的概念：SPI，是Service Provider Interface的縮寫，即服務提供者接口，單從字面上看，可以這樣理解，該機制提供了一種可根據接口類型去動態加載出接口實現類對象的功能。打一個比喻，該機制就類似Spring容器，通過IOC將對象的創建交給Spring容器處理，若需要獲取某個類的對象，就從Spring容器裏取出使用即可。同理，在SPI機制當中，提供了一個類似Spring容器的角色，叫【服務提供者】，在代碼運行過程中，若要使用到實現了某個接口的服務實現類對象，只需要將對應的接口類型交給服務提供者，服務提供者將會動態加載出所有實現了該接口的服務實現類對象，最後給到服務使用者使用。

接着前文的分享，可從以下三個步驟目錄去深入分析Java SPI機制源碼實現——

創建服務提供者ServiceLoader對象，其內部生成一個可延遲加載接口對應實現類對象的迭代器LazyIterator，主要作用是讀取並解析META-INF/services/目錄下的配置文件中service類名字，進而通過反射加載生成service類對象。
調用serviceLoader.iterator()返回一個內部實際是調用LazyIterator迭代器的匿名迭代器對象。
遍歷迭代器，逐行解析接口全類名所對應配置文件中的service實現類的名字，通過反射生成對象緩存到鏈表，最後返回。

//step 1 創建ServiceLoader對象，其內部生成一個可延遲加載接口對應實現類對象的迭代器LazyIterator，主要作用是讀取並解析META-INF/services/目錄下的配置文件中service類名字，進而通過反射加載生成service類對象。
ServiceLoader<UserService> serviceLoader = ServiceLoader.load(UserService.class);
//step 2 調用serviceLoader.iterator()返回一個內部實際是調用LazyIterator迭代器的匿名迭代器對象。
Iterator<UserService> serviceIterator = serviceLoader.iterator();
//step 3 遍歷迭代器，逐行解析接口全類名所對應配置文件中的service實現類的名字，通過反射生成對象緩存到鏈表，最後返回。
    UserService service = serviceIterator.next();
    service.getName();
    }
}

整個過程這裏先做一個全面概括——ServiceLoader類會延遲加載UserService接口全名對應的META-INF/services/目錄下的配置文件com.zhu.service.UserService。當找到對應接口全名文件後，會逐行讀取文件裏Class類名的字符串，假如存儲的是“com.zhu.service.impl.AUserServiceImpl”和“com.zhu.service.impl.BUserServiceImpl”這兩個類名，那麼就會逐行取出，再通過反射【“Class類名”.newInstance()】，就可以創建出UserService接口對應的服務提供者對象。這些對象會以結構爲<實現類名, 實現類對象>的Map形式，存儲到LinkedHashMap鏈表裏。該鏈表將由迭代器循環遍歷，取出每一個實現類對象。

畫一個流程圖說明，大概如下——

接下來，基於該全貌流程圖，分別對源碼作分析。

一、創建服務提供者ServiceLoader對象，其內部生成一個可延遲加載接口對應實現類對象的迭代器LazyIterator，主要作用是讀取並解析META-INF/services/目錄下的配置文件中service類名字，進而通過反射加載生成service類對象。

先看第一部分代碼——

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

進入到ServiceLoader.load(UserService.class)方法裏，裏面基於當前線程通Thread.currentThread().getContextClassLoader()創建一個當前上下文的類加載器ClassLoader，該加載器在這裏主要是用來加載META-INF.services目錄下的文件。

在load方法裏，將UserService.class和類加載器ClassLoader當作參數，交給ServiceLoader中的另一個重載方法ServiceLoader.load(service, cl)去做進一步具體實現。

public static <S> ServiceLoader<S> load(Class<S> service) {
    ClassLoader cl = Thread.currentThread().getContextClassLoader();
    return ServiceLoader.load(service, cl);
}

進入到ServiceLoader.load(service, cl)，該方法裏創建了一個ServiceLoader對象，該對象默認執行了參數值分別爲UserService.class和ClassLoader的帶參構造方法。

public static <S> ServiceLoader<S> load(Class<S> service,
                                        ClassLoader loader)
{
    return new ServiceLoader<>(service, loader);
}

根據字面意義，可以看出，ServiceLoader是一個專門負責加載服務的對象，在SPI機制裏，它充當專門提供接口實現服務對象的角色。

這裏就有兩個問題，它怎麼提供服務對象，它提供的是哪個接口的服務？

針對這兩個問題，基於傳進來的參數值UserService.class和類加載器ClassLoader，就已經能猜出答案裏，它將通過類加載器ClassLoader去加載實現UserService接口的具體服務類對象。

進入到ServiceLoader的帶參構造函數——

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

這裏暫時只需要關注loader和 reload()，而acc是專門用在服務實現類的安全權限訪問方面的，本文暫未涉及到acc，後續會考慮專門寫一篇文分享下SPI下，如何實現服務實現類的安全權限訪問。

傳進來的loader如果爲空，那麼就使用ClassLoader.getSystemClassLoader()，即系統類加載器，可以簡單理解，無論如何，都會得到一個非空的類加載器。

接着進入到reload()方法裏——

/**
 * Clear this loader's provider cache so that all providers will be reloaded.
 * 清除此加載器的提供程序緩存，以便重新加載所有提供程序。
 * <p> After invoking this method, subsequent invocations of the {@link
 * #iterator() iterator} method will lazily look up and instantiate providers from scratch, 
   just as is done by a newly-created loader.
   調用此方法後，後續調用{@link #iterator() iterator}方法將從零開始惰性查找並實例化提供商，
   就像新創建的加載器一樣。
 *
 * <p> This method is intended for use in situations in which new providers
 * can be installed into a running Java virtual machine.
   此方法旨在用於新提供者可以安裝到正在運行的Java虛擬機中。
 */
public void reload() {
    providers.clear();
    lookupIterator = new LazyIterator(service, loader);
}

根據reload() 方法的註釋說明，可以看到，該方法做了兩件事：

providers是一個Map結構的鏈表LinkedHashMap，專門存儲服務實例（在這裏是存儲UserService接口實現類對象）的集合，通過clear()方法做了清除，即清空了裏面的所有記錄。
LazyIterator實現了Iterator迭代器接口，根據類名可以看出，這是一個Lazy懶加載形式的迭代器。

需要額外解釋一下延遲加載是什麼意思。延遲加載，說明項目啓動時不會立馬加載，而是需要被用到的時候，纔會動態去加載。實現了Iterator迭代器接口的LazyIterator對象，就具備延遲加載的功能。

簡單看一下，該LazyIterator的結構——

private class LazyIterator implements Iterator<S>
{
    //存儲服務接口的Class類型
    Class<S> service;
    //存儲類加載器。
    ClassLoader loader;
    //存儲服務接口全類名所對應在META-INF.services目錄中的配置文件資源路徑
    Enumeration<URL> configs = null;
    //存儲裏配置文件中服務類名的迭代器
    Iterator<String> pending = null;
    //存儲下一個返回的服務提供者類名
    String nextName = null;

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

總結這部分源碼，主要是創建一個可加載接口服務提供者實例的ServiceLoader類對象，其內部創建一個具有延遲加載功能的迭代器LazyIterator。該LazyIterator迭代器能夠延遲去逐行遍歷解析出接口全類名所對應配置文件中的Class類名字符串，再將Class類名字符串通過反射生成服務提供者對象，存儲到鏈表，用於外部迭代遍歷。

接下來，會基於該延遲加載LazyIterator迭代器，做進一步處理。

到目前爲止，只是在ServiceLoader類對象的內部，創建了一個存儲接口UserService.class，類加載器loader的LazyIterator迭代器，暫時還沒涉及到如何獲取接口對應的服務提供者。

簡單理解成，菜刀和鍋都準備好了，就等切菜和煮菜了。

二、調用serviceLoader.iterator()返回一個內部實際是調用LazyIterator迭代器的匿名迭代器對象

這裏通過serviceLoader.iterator()得到了一個類型爲UserService的迭代器。

Iterator<UserService> serviceIterator = serviceLoader.iterator();

先進入到serviceLoader.iterator()內部——

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;
            return lookupIterator.hasNext();
        }

        public S next() {
            if (knownProviders.hasNext())
                return knownProviders.next().getValue();
            return lookupIterator.next();
        }

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

    };
}

該方法裏，return new Iterator() { ... }表示創建一個實現了Iterator接口的匿名內部類實例對象，並返回該實例對象作爲一個迭代器。

至於這個匿名對象是叫張三還是李四，都不重要。重要的是，其內部具有能被外部正常調用的hasNext()和next()就可以了。

我畫了一幅簡單的漫畫，舉例說明一下，這裏爲何可以直接返回一個實現Iterator接口的匿名內部類實例對象。

故事是這樣的，有一個老闆，想要招一個工具人，哦，不對，是打工人（反正都一樣......）——

故事到這裏就結束了，這個return new Iterator() { ... }返回的匿名內部類，就像無數籍籍無名的底層打工人一樣，或許自始自終都無人知道他們的名字，但他們用自己辛勤的手（hasNext()方法）腳（next()方法），在平凡的崗位上，默默做着不平凡的工作，提供着可以幫助其他人（服務使用者）的服務。

接下來，讓我們看看這些打工人那佈滿皺紋的手和腳——

Iterator<Map.Entry<String,S>> knownProviders
    = providers.entrySet().iterator();

public boolean hasNext() {
    if (knownProviders.hasNext())
        return true;
    return lookupIterator.hasNext();
}

public S next() {
    if (knownProviders.hasNext())
        return knownProviders.next().getValue();
    return lookupIterator.next();
}

knownProviders是一個包裝了LinkedHashMap providers = new LinkedHashMap<>()鏈表的迭代器。

當調用hasNext()或者next()時，都會判斷providers裏是否還有可以遍歷獲取的值，如果空了，就會調用lookupIterator.hasNext()或者lookupIterator.next()。

這個lookupIterator，正是前文創建的LazyIterator迭代器對象的引用。

匿名迭代器對象中的這兩個方法，分別是以下兩種功能：

hasNext()判斷迭代器是否存在下一個元素。
next()獲取迭代器中的下一個元素。

可見，這部分源碼調用serviceLoader.iterator()返回一個提供hasNext()和next()方法的匿名迭代器對象，實際上，hasNext()和next()方法內真實調用的是迭代器LazyIterator的hasNext()和next()方法。

三、遍歷迭代器，逐行解析接口全類名所對應配置文件中的service實現類的名字，通過反射生成對象緩存到鏈表，最後返回。

該分析最後的代碼了，這裏已經到遍歷循環迭代器，通過serviceIterator.next()取出存儲接口服務提供者對象——

while (serviceIterator.hasNext()) {
    UserService service = serviceIterator.next();
    service.getName();
    }
}

這裏的hasNext()和next()，正是前文return new Iterator() { ... }匿名對象裏的hasNext()和next()方法。故而在執行serviceIterator.hasNext()或者serviceIterator.next()，將跳轉到#ServiceLoader類#iterator() 中，執行該匿名內部類的hasNext()和next()方法。

先來看hasNext()方法——

public boolean hasNext() {
    if (knownProviders.hasNext())
        return true;
    return lookupIterator.hasNext();
}

若是第一次執行時，knownProviders迭代器裏的LinkedHashMap鏈表必定是空的，這時候，就會執行lookupIterator.hasNext()——

public boolean hasNext() {
    if (acc == null) {
    //acc爲空，執行的是這一步代碼
        return hasNextService();
    } else {
        PrivilegedAction<Boolean> action = new PrivilegedAction<Boolean>() {
            public Boolean run() { return hasNextService(); }
        };
        return AccessController.doPrivileged(action, acc);
    }
}

這裏acc爲空，故而執行的是return hasNextService()語句——

private boolean hasNextService() {
    if (nextName != null) {
        return true;
    }
    if (configs == null) {
        try {
            //"META-INF/services/" + 接口全類名
            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;
}

初次調用，configs是null，而類加載器loader非空，故而會執行configs = loader.getResources(fullName)這行代碼。

基於該執行步驟，分析一下這裏的configs作用是什麼，先看以下兩個邏輯——

PREFIX的值爲private static final String PREFIX = "META-INF/services/"，表示正是目錄META-INF/services/路徑。
service.getName()是獲取Class的name值，我們傳進來的是UserService.class，故而這裏service.getName()獲取到的，便是接口全名com.zhu.service.UserService。

兩者結合，即代碼String fullName = PREFIX + service.getName()得到的，便是“METAINF/services/com.zhu.service.UserService”字符串，表示文件路徑名。

這時候，我們的類加載器就開始派上用場了——

configs = loader.getResources(fullName);

沒錯，到這裏已經拿到UserService接口全類名對應的文件路徑，就可以通過類加載器讀取到該文件資源了。

讀取到該文件之後，之後就可以解析存放在文件裏的接口的服務實現類信息了，故而具體實現在pending =parse(service, configs.nextElement())這行代碼裏——

while ((pending == null) || !pending.hasNext()) {
    if (!configs.hasMoreElements()) {
        return false;
    }
    //逐行解析讀取配置文件類名，將讀取到的類名存儲到ArrayList,最後包裝成iterator返回賦值給pending
    pending = parse(service, configs.nextElement());
}

進入到parse方法裏，可以看到，這裏開始通過while((lc =parseLine(service, u, r, lc, names))>=0)對文件內容逐行讀取，同時創建一個ArrayList names，用來緩存讀取出來的類名，具體實現就在parseLine(service, u, r, lc, names))方法裏——

private Iterator<String> parse(Class<?> service, URL u)
    throws ServiceConfigurationError
{
    InputStream in = null;
    BufferedReader r = null;
    //用來緩存從文件裏讀取出來的類名
    ArrayList<String> names = new ArrayList<>();
    try {
        in = u.openStream();
        r = new BufferedReader(new InputStreamReader(in, "utf-8"));
        int lc = 1;
        //遍歷文件每一行字符串
        while ((lc = parseLine(service, u, r, lc, names)) >= 0);
    } catch (IOException x) {
        fail(service, "Error reading configuration file", x);
    } finally {
        try {
            if (r != null) r.close();
            if (in != null) in.close();
        } catch (IOException y) {
            fail(service, "Error closing configuration file", y);
        }
    }
    //將ArrayList包裝成迭代器返回
    return names.iterator();
}

進入到parseLine(service, u, r, lc, names))方法，代碼String ln = r.readLine()表示讀取出文件每一行的字符串賦值給ln。

若遇到有#註釋符號的就跳過，只讀取非#號註釋的類名字符串，以names.add(ln)保存到一個ArrayList裏。

private int parseLine(Class<?> service, URL u, BufferedReader r, int lc,
                      List<String> names)
    throws IOException, ServiceConfigurationError
{
    String ln = r.readLine();
    if (ln == null) {
        return -1;
    }

    int ci = ln.indexOf('#');
    if (ci >= 0) ln = ln.substring(0, ci);
    ln = ln.trim();
    int n = ln.length();
    //過濾掉帶有#字符的
    if (n != 0) {
        if ((ln.indexOf(' ') >= 0) || (ln.indexOf('\t') >= 0))
            fail(service, u, lc, "Illegal configuration-file syntax");
        int cp = ln.codePointAt(0);
        if (!Character.isJavaIdentifierStart(cp))
            fail(service, u, lc, "Illegal provider-class name: " + ln);
        for (int i = Character.charCount(cp); i < n; i += Character.charCount(cp)) {
            cp = ln.codePointAt(i);
            if (!Character.isJavaIdentifierPart(cp) && (cp != '.'))
                fail(service, u, lc, "Illegal provider-class name: " + ln);
        }
        //讀取文件裏的類名字符串存儲到names這個ArrayList裏
        if (!providers.containsKey(ln) && !names.contains(ln))
            names.add(ln);
    }
    return lc + 1;
}

將讀取文件裏的類名存到ArrayList後，最後return names.iterator()返回一個iterator迭代器，可debug打印看一下，可以看到該ArrayList緩存了從文件裏讀取出來的類名——

該迭代器在解析完成後，會執行一次nextName = pending.next()，表示通過迭代器方式取出ArrayList中的第一個字符串，即“com.zhu.service.impl.AUserServiceImpl”，同時return true。

這裏nextName = pending.next()和return true就呼應了外部服務使用者的調用，可見serviceIterator.hasNext()內部，若迭代器下一個元素不爲空，那麼就將下一個元素通過取出，賦值給nextName，同時返回true，讓while循環正常遍歷下去——

前面的nextName = pending.next()將會在serviceIterator.next()裏有所體現。

接下來，在next()中，第一次調用，也是lookupIterator.next()方法——

public S next() {
    if (knownProviders.hasNext())
        return knownProviders.next().getValue();
    return lookupIterator.next();
}

進入到lookupIterator.next()方法——

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

同樣，實現的是nextService()——

private S nextService() {
    if (!hasNextService())
        throw new NoSuchElementException();
    String cn = nextName;
    nextName = null;
    Class<?> c = null;
    try {
        /**
        *nextName即將前文的com.zhu.service.impl.AUserServiceImpl
        *String cn = nextName
        *通過Class.forName(cn, false, loader)，即可生成AUserServiceImpl的Class類對象
        */
        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 {
        //既然已經拿到AUserServiceImpl的Class類對象，通過反射c.newInstance()便能生成相應對象
        S p = service.cast(c.newInstance());
        //生成的對象會以結構爲<實現類名, 實現類對象>的Map形式，存儲到LinkedHashMap鏈表裏
        providers.put(cn, p);
        return p;
    } catch (Throwable x) {
        fail(service,
             "Provider " + cn + " could not be instantiated",
             x);
    }
    throw new Error();          // This cannot happen
}

在這裏面，主要做了這樣幾件事：

將nextName字符串賦值給cn，首次調用時，這裏的nextName值爲“com.zhu.service.impl.AUserServiceImpl”；
通過 c = Class.forName(cn,false, loader)生成AUserServiceImpl類的Class對象；
通過反射通過c.newInstance()生成AUserServiceImpl類實例對象；
生成的對象會以結構爲<實現類名, 實現類對象>的Map形式，存儲到LinkedHashMap鏈表裏；
將生成的對象返回；

因此，在第一次調用完UserService service = serviceIterator.next()後，就能拿到了接口UserService的第一個實現類對象com.zhu.service.impl.AUserServiceImpl，進而就可以執行相應的重寫方法service.getName()。

到while的第二次遍歷時，執行serviceIterator.hasNext()後，會取出ArrayList中的第二個緩存類名“com.zhu.service.impl.BUserServiceImpl”賦值給nextName，這樣在執行UserService service = serviceIterator.next()時，就會重複執行nextService()裏的邏輯。一直迭代遍歷，直到將配置裏的類名都遍歷完，serviceIterator才最終結束該UserService接口的服務提供功能。

首次調用就是以上流程，值得提的一個地方是，在反射創建完成的對象後，將以結構爲<實現類名, 實現類對象>的Map形式。存儲到LinkedHashMap鏈表裏。

這個LinkedHashMap鏈表緩存的作用是什麼呢？

這時回頭去看下這行代碼，還記得它裏面創建了一個匿名內部類嗎——

這個匿名內部類裏，其hasNext()和next()方法，會判斷knownProviders是否爲空，不爲空纔去調用knownProviders裏的方法。

這裏的knownProviders正是使用到了LinkedHashMap鏈表緩存裏的對象。

這個鏈表的作用，就是方便出現重複創建一個匿名迭代器去後去獲取接口的服務對象時，直接從LinkedHashMap鏈表緩存裏讀取即可，無需再次去解析接口對應的配置文件，起到了查詢優化的作用。

類似這樣的場景，第二次生成一個迭代器去提供接口的服務功能時，就直接從從LinkedHashMap鏈表緩存裏讀取了。

以上，就是Java SPI的完整源碼分析。

Java SPI機制總結系列之萬字最詳細圖解Java SPI機制源碼分析

一、創建服務提供者ServiceLoader對象，其內部生成一個可延遲加載接口對應實現類對象的迭代器LazyIterator，主要作用是讀取並解析META-INF/services/目錄下的配置文件中service類名字，進而通過反射加載生成service類對象。

二、調用serviceLoader.iterator()返回一個內部實際是調用LazyIterator迭代器的匿名迭代器對象

三、遍歷迭代器，逐行解析接口全類名所對應配置文件中的service實現類的名字，通過反射生成對象緩存到鏈表，最後返回。

AI模型 Llama 3體驗筆記

【面試準備】又一次失敗的面試經歷，題目離譜～資深軟件測試工程師

dotnet 8 版本與銀河麒麟V10和UOS系統的 glibc 兼容性

kafka源碼閱讀之MacBook Pro M1搭建Kafka2.7版本源碼運行環境

Docker部署系列之Docker Compose安裝Redis三主三從集羣

基於源碼理解通透Iterator迭代器的Fail-Fast快速失敗與Fail-Safe安全失敗機制

[2023年度回顧總結]凡是過往,皆爲序章

Java SPI機制總結系列之萬字最詳細圖解Java SPI機制源碼分析

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結