Java中的SPI原理淺談-有解無憂

　　在面向物件的程式設計中，模塊之間互動采用介面編程，通常情況下呼叫方不需要知道被呼叫方的內部實作細節，因為一旦涉及到了具體實作，如果需要換一種實作就需要修改代碼，這違反了程式設計的"開閉原則"，所以我們一般有兩種選擇：一種是使用API(Application Programming Interface)，另一種是SPI（Service Provider Interface），API通常被應用程式開發人員使用，而SPI通常被框架擴展人員使用，

　　在進入下面學習之前，我們先來再加深一下API和SPI這兩個的印象：

　　API:由實作方制定介面標準并完成對介面的不同實作，這種模式服務介面從概念上更接近于實作方；

　　SPI:由呼叫方制定介面標準，實作方來針對介面提供不同的實作；從前半句話我們來看，SPI其實就是"為介面查找實作"的一種服務發現機制；這種模式，服務介面組織上位于呼叫方所在的包中，實作位于獨立的包中，

　　API和SPI簡略圖示：

　　看完上面的簡單圖示，相信大家對API和SPI的區別有了一個大致的了解，現在我們使用SPI機制來實作我們一個簡單的日志框架：

　　第一步，創建一個maven專案命名為spi-interface，定義一個SPI對外服務介面，用來后續提供給呼叫者使用；

package cn.com.wwh;
/**
 * 
 * @FileName Logger.java
 * @version:1.0
 * @Description: 服務提供者介面
 * @author: wwh
 * @date: 2022年9月19日 上午10:31:53
 */
public interface Logger {
    
    /**
     * 
     * @Description:(功能描述)
     * @param msg
     */
    public void info(String msg);
    
    /**
     * 
     * @Description:(功能描述)
     * @param msg
     */
    public void debug(String msg);
}

package cn.com.wwh;

import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
import java.util.ServiceLoader;

/**
 * 
 * @FileName LoggerService.java
 * @version:1.0
 * @Description: 為服務的呼叫者提供特定的功能，是SPI的核心功能
 * @author: wwh
 * @date: 2022年9月19日 上午10:33:30
 */
public class LoggerService {

    private static final LoggerService INSTANCE = new LoggerService();

    private final Logger logger;                          

    private final List<Logger> loggers = new ArrayList<>();

    private LoggerService() {
　　　　　//ServiceLoader是實作SPI的核心類
        ServiceLoader<Logger> sl = ServiceLoader.load(Logger.class);
        Iterator<Logger> it = sl.iterator();
        while (it.hasNext()) {
            loggers.add(it.next());
        }

        if (!loggers.isEmpty()) {
            logger = loggers.get(0);
        } else {
            logger = null;
        }
    }

    /**
     * @Description:(功能描述)
     * @return
     */
    public static LoggerService getLoggerService() {
        return INSTANCE;
    }

    /**
     * 
     * @Description:(功能描述)
     * @param msg
     */
    public void info(String msg) {
        if (logger == null) {
            System.err.println("在info方法中沒有找到Logger的實作類...");
        } else {
            logger.info(msg);
        }
    }

    /**
     * 
     * @Description:(功能描述)
     * @param msg
     */
    public void debug(String msg) {
        if (logger == null) {
            System.err.println("在debug方法中沒有找到Logger的實作類...");
        } else {
            logger.info(msg);
        }
    }
}

　　將上面這個這個專案打成spi-interface.jar包，

　　第二步，新建一個maven專案并匯入第一步中打出來的spi-interface.jar包，這個專案用來提供服務的實作，定義一個類，實作第一步中定義的cn.com.wwh.Logger介面，示例代碼如下：

package cn.com.wwh;

import cn.com.pep.Logger;

/**
 * 
 * @FileName Logback.java
 * @version:1.0
 * @Description: 服務介面的實作類
 * @author: wwh
 * @date: 2022年9月19日 上午10:50:31
 */
public class Logback implements Logger {

    @Override
    public void debug(String msg) {
        System.err.println("呼叫Logback的debug方法，輸出的日志為：" + msg);
    }

    @Override
    public void info(String msg) {
        System.err.println("呼叫Logback的info方法，輸出的日志為：" + msg);
    }

}

　　同時在當前專案的classpath路徑下建立META-INF/services/檔案夾（至于為什么這么建立目錄，我們一會兒再解釋），并且新建一個名稱為cn.com.wwh.Logger內容為cn.com.wwh.Logback的檔案，這一步是關鍵（具體作用后面再詳細說明），然后將上面第二步這個這個專案打成spi-provider.jar包，供給之后使用，我目前使用的開發工具是Eclipse，目錄結構如下圖所示：

　　第三步，撰寫測驗類，新建一個maven專案，命名為spi-test，匯入前面兩個步驟打的spi-interface.jar和spi-provider.jar這兩個jar包，并撰寫測驗代碼，示例如下：

package cn.com.wwh;

import cn.com.pep.LoggerService;

/**
 * 
 * @FileName SpiTest.java
 * @version:1.0
 * @Description: 
 * @author: wwh
 * @date: 2022年9月19日 上午10:56:31
 */
public class SpiTest {
    
    public static void main(String[] args) {
        LoggerService logger = LoggerService.getLoggerService();
        logger.info("我是中國人");
        logger.debug("白菜多少錢一斤");
    }
}

　　有了SPI我們可以將服務和服務提供者輕松地解耦，假如將來的某一天我們需要將日志保存到資料庫，或者通過網路發送，我們直接只需要替換針對服務介面的實作類即可，別的地方都不用修改，這更符合程式設計中的“開閉原則”，

　　SPI的大致原理是：應用啟動的時候，掃描classpath下面的所有jar包，將jar包下的/META-INF/services/目錄下的檔案加載到記憶體中，進行一系列的決議（檔案的名稱是spi介面的全路徑名稱，檔案內容應該是spi介面實作類的全路徑名，可以用多個實作類，在檔案中換行保存），之后判斷當前類和當前介面是否是同一型別？結果為true，則通過反射生成指定類的實體物件，保存到一個map集合中，可以通過遍歷或者迭代的方式拿出來使用，

　　SPI實質就是一個加載服務實作的工具，核心類是ServiceLoader，其實了解了SPI的原理，我們再接著探究JDK中的原始碼就沒有那么費力了，下面我們開始原始碼分析吧，

　　ServiceLoader類是定義在java.util包下的，使用final定義禁止子類繼承和修改，實作了Iterable介面，使得可以通過迭代或者遍歷的方式獲取SPI介面的不同實作，

從上面的我們所舉的例子中，我們知道SPI的入口是ServiceLoader.load(Class<S> service)方法，我們來看看它都干了什么？　

　　上面的這4步總的來說，就是使用指定的型別和當前執行緒系結的classLoader實體化了一個LazyIterator物件賦值給lookupIterator這個參考，并且清除了原來providers串列中快取的服務的實作，接下來我們呼叫了ServiceLoader實體的iterator（）方法獲取了一個迭代器，代碼如下：

 1 public Iterator<S> iterator() {
 2         //通過匿名內部類方式提供了一個迭代器
 3         return new Iterator<S>() {
 4             //獲取快取的服務實作者的迭代器
 5             Iterator<Map.Entry<String, S>> knownProviders = providers.entrySet().iterator();
 6             
 7             //判斷迭代器中是否還有元素
 8             public boolean hasNext() {
 9                 //快取的服務實作者的迭代器中已經沒有元素了
10                 if (knownProviders.hasNext())
11                     return true;
12                 return lookupIterator.hasNext();//判斷延遲加載的迭代器中是否還有元素
13             }
14 
15             //獲取迭代其中的下一個元素
16             public S next() {
17                 if (knownProviders.hasNext())
18                     return knownProviders.next().getValue();
19                 return lookupIterator.next();//獲取延遲加載的迭代器中的下一個元素
20             }
21 
22             public void remove() {
23                 throw new UnsupportedOperationException();
24             }
25         };
26    }

　　我們接著呼叫上步獲取的迭代器it的hasNext()方法，因為我們在ServiceLoader.load()程序中其實是清除了providers串列中的快取服務實作的，所以其實呼叫的是lookupIterator.hasNext()方法，如下：

 1 public boolean hasNext() {
 2         if (nextName != null) {//存在下一個元素
 3             return true;
 4         }
 5         if (configs == null) {//組態檔為空
 6             try {
 7                 String fullName = PREFIX + service.getName();//獲取組態檔路徑
 8                 if (loader == null)
 9                     configs = ClassLoader.getSystemResources(fullName);
10                 else
11                     configs = loader.getResources(fullName);//加載組態檔
12             } catch (IOException x) {
13                 fail(service, "Error locating configuration files", x);
14             }
15         }
16         //遍歷組態檔內容
17         while ((pending == null) || !pending.hasNext()) {
18             if (!configs.hasMoreElements()) {
19                 return false;
20             }
21             pending = parse(service, configs.nextElement());//組態檔內容決議
22         }
23         nextName = pending.next();//獲取服務實作類的全路徑名
24         return true;
25     }
26

　　假如上部判斷為true,緊接著我們又呼叫了迭代器it的next()方式，同理也呼叫的是lookupIterator.next()方法，原始碼如下：

 1 public S next() {
 2         if (!hasNext()) {
 3             throw new NoSuchElementException();
 4         }
 5         String cn = nextName;//檔案中保存的服務介面實作類的全路徑名
 6         nextName = null;
 7         Class<?> c = null;
 8         try {
 9             //獲取全限定名的Class物件
10             c = Class.forName(cn, false, loader);
11         } catch (ClassNotFoundException x) {
12             fail(service, "Provider " + cn + " not found");
13         }
14             //判斷實作類和服務介面是否是同一型別
15         if (!service.isAssignableFrom(c)) {
16             fail(service, "Provider " + cn + " not a subtype");
17         }
18         try {
19             //通過反射生成服務介面的實作類，并判斷這個實體是否是介面的實作
20             S p = service.cast(c.newInstance());
21             //將服務介面的實作快取起來，并回傳
22             providers.put(cn, p);
23             return p;
24         } catch (Throwable x) {
25             fail(service, "Provider " + cn + " could not be instantiated", x);
26         }
27         throw new Error(); // This cannot happen
28     }

　　其實spi實作的主要流程是：掃描classpath路徑下的所有jar包下的/META-INF/services/目錄（即我們需要將服務介面的具體實作類暴露在這個目錄下，之前我們提到需要在實作類的classpath下面建立一個/META-INF/services/檔案夾就是這個原因，），找到對應的檔案，讀取這個檔案名找到對應的SPI介面，然后通過InputStream流將檔案內容讀出來，獲取到實作類的全路徑名，并得到這個全路徑名所表示的Class物件，判斷其與服務介面是否是同一型別，然后通過反射生成服務介面的實作，并保存在providers串列中，供給后續的使用，

　　SPI這種設計方式為我們的應用擴展提供了極大的便利，但是它的短板也是顯而易見的，Java SPI 在查找擴展實作類的時候遍歷 SPI 的組態檔并且將實作類全部實體化，假設一個實作類初始化程序比較消耗資源且耗時，但是你的代碼里面又用不上它，這就產生了資源的浪費，所以說 Java SPI 無法按需加載實作類，

　　另外，SPI 機制在很多框架中都有應用：slf4j日志框架、Spring 框架的基本原理也是類似的反射，還有 Dubbo 框架提供同樣的 SPI 擴展機制，只不過 Dubbo 和 spring 框架中的 SPI 機制具體實作方式跟咱們今天學得這個有些細微的區別（Dubbo可以實作按需加載實作類），不過整體的原理都是一致的，我們今天先對SPI有個簡單的了解，相信有了今天的基礎理解剩下的那幾個也不是什么難事，

　　好了，今天就到這兒了，文章中有說的不對的地方還請各位大佬批評指正，一起學習，共同進步，謝謝，

本文來自博客園，作者：一只烤鴨朝北走，僅用于技術學習，所有資源都來源于網路，部分是轉發，部分是個人總結，歡迎共同學習和轉載，轉載請在醒目位置標明原文，如有侵權，請留言告知，及時撤除，轉載請注明原文鏈接：https://www.cnblogs.com/wha6239/p/16692713.html

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/509150.html

標籤：設計模式

上一篇：我的設計模式之旅、13 配接器模式

下一篇：新消費時代，零售業的進與退？