源碼級(jí)深度理解Java SPI

（3）懶加載迭代器的工作流程

上面的源碼中提到了，lookupIterator 是 LazyIterator 實(shí)例，而 LazyIterator 用于懶加載 SPI 實(shí)例。那么， LazyIterator 是如何工作的呢？

這里，摘取LazyIterator關(guān)鍵代碼

hasNextService 方法：

• 拼接META-INF/services/+ SPI 接口全限定名

• 通過類加載器，嘗試加載資源文件

• 解析資源文件中的內(nèi)容，獲取 SPI 接口的實(shí)現(xiàn)類的全限定名nextName

nextService 方法：

• hasNextService()方法解析出了 SPI 實(shí)現(xiàn)類的的全限定名 nextName，通過反射，獲取 SPI 實(shí)現(xiàn)類的類定義 Class。

• 然后，嘗試通過 Class 的 newInstance 方法實(shí)例化一個(gè) SPI 服務(wù)對(duì)象。如果成功，則將這個(gè)對(duì)象加入到緩存 providers 中并返回該對(duì)象。

private boolean hasNextService() {
  if (nextName != null) {
    return true;
  }
  if (configs == null) {
    try {
            // 1.拼接 META-INF/services/ + SPI 接口全限定名
            // 2.通過類加載器，嘗試加載資源文件
            // 3.解析資源文件中的內(nèi)容
      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;
}


private S nextService() {
  if (!hasNextService())
    throw new NoSuchElementException();
  String cn = nextName;
  nextName = null;
  Class c = null;
  try {
    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 s");
  }
  try {
    S p = service.cast(c.newInstance());
    providers.put(cn, p);
    return p;
  } catch (Throwable x) {
    fail(service,
       "Provider " + cn + " could not be instantiated",
       x);
  }
  throw new Error();          // This cannot happen
}

3.3 SPI 和類加載器

通過上面兩個(gè)章節(jié)中，走讀 ServiceLoader 代碼，我們已經(jīng)大致了解 Java SPI 的工作原理，即通過 ClassLoader 加載 SPI 配置文件，解析 SPI 服務(wù)，然后通過反射，實(shí)例化 SPI 服務(wù)實(shí)例。我們不妨思考一下，為什么加載 SPI 服務(wù)時(shí)，需要指定類加載器 ClassLoader 呢？

學(xué)習(xí)過 JVM 的讀者，想必都了解過類加載器的雙親委派模型（Parents Delegation Model）。雙親委派模型要求除了頂層的 BootstrapClassLoader 外，其余的類加載器都應(yīng)有自己的父類加載器。這里類加載器之間的父子關(guān)系一般通過組合（Composition）關(guān)系來實(shí)現(xiàn)，而不是通過繼承（Inheritance）的關(guān)系實(shí)現(xiàn)。

雙親委派機(jī)制約定了：一個(gè)類加載器首先將類加載請(qǐng)求傳送到父類加載器，只有當(dāng)父類加載器無法完成類加載請(qǐng)求時(shí)才嘗試加載。

雙親委派的好處：使得 Java 類伴隨著它的類加載器，天然具備一種帶有優(yōu)先級(jí)的層次關(guān)系，從而使得類加載得到統(tǒng)一，不會(huì)出現(xiàn)重復(fù)加載的問題：

• 系統(tǒng)類防止內(nèi)存中出現(xiàn)多份同樣的字節(jié)碼

• 保證 Java 程序安全穩(wěn)定運(yùn)行

例如：java.lang.Object 存放在 rt.jar 中，如果編寫另外一個(gè) java.lang.Object 的類并放到 classpath 中，程序可以編譯通過。因?yàn)殡p親委派模型的存在，所以在 rt.jar 中的 Object 比在 classpath 中的 Object 優(yōu)先級(jí)更高，因?yàn)?rt.jar 中的 Object 使用的是啟動(dòng)類加載器，而 classpath 中的 Object 使用的是應(yīng)用程序類加載器。正因?yàn)?rt.jar 中的 Object 優(yōu)先級(jí)更高，因?yàn)槌绦蛑兴械?Object 都是這個(gè) Object。

雙親委派的限制：子類加載器可以使用父類加載器已經(jīng)加載的類，而父類加載器無法使用子類加載器已經(jīng)加載的?！@就導(dǎo)致了雙親委派模型并不能解決所有的類加載器問題。Java SPI 就面臨著這樣的問題：

• SPI 的接口是 Java 核心庫的一部分，是由 BootstrapClassLoader 加載的；

• 而 SPI 實(shí)現(xiàn)的 Java 類一般是由 AppClassLoader 來加載的。BootstrapClassLoader 是無法找到 SPI 的實(shí)現(xiàn)類的，因?yàn)樗患虞d Java 的核心庫。它也不能代理給 AppClassLoader，因?yàn)樗亲铐攲拥念惣虞d器。這也解釋了本節(jié)開始的問題——為什么加載 SPI 服務(wù)時(shí)，需要指定類加載器 ClassLoader 呢？因?yàn)槿绻恢付?ClassLoader，則無法獲取 SPI 服務(wù)。

如果不做任何的設(shè)置，Java 應(yīng)用的線程的上下文類加載器默認(rèn)就是 AppClassLoader。在核心類庫使用 SPI 接口時(shí)，傳遞的類加載器使用線程上下文類加載器，就可以成功的加載到 SPI 實(shí)現(xiàn)的類。線程上下文類加載器在很多 SPI 的實(shí)現(xiàn)中都會(huì)用到。

通?？梢酝ㄟ^

Thread.currentThread().getClassLoader()

和 Thread.currentThread().getContextClassLoader()獲取線程上下文類加載器。

3.4 Java SPI 的不足

Java SPI 存在一些不足：

• 不能按需加載，需要遍歷所有的實(shí)現(xiàn)，并實(shí)例化，然后在循環(huán)中才能找到我們需要的實(shí)現(xiàn)。如果不想用某些實(shí)現(xiàn)類，或者某些類實(shí)例化很耗時(shí)，它也被載入并實(shí)例化了，這就造成了浪費(fèi)。

• 獲取某個(gè)實(shí)現(xiàn)類的方式不夠靈活，只能通過 Iterator 形式獲取，不能根據(jù)某個(gè)參數(shù)來獲取對(duì)應(yīng)的實(shí)現(xiàn)類。

• 多個(gè)并發(fā)多線程使用 ServiceLoader 類的實(shí)例是不安全的。

四、SPI 應(yīng)用場景

SPI 在 Java 開發(fā)中應(yīng)用十分廣泛。首先，在 Java 的 java.util.spi package 中就約定了很多 SPI 接口。下面，列舉一些 SPI 接口：

• TimeZoneNameProvider:為 TimeZone 類提供本地化的時(shí)區(qū)名稱。

• DateFormatProvider:為指定的語言環(huán)境提供日期和時(shí)間格式。

• NumberFormatProvider:為 NumberFormat 類提供貨幣、整數(shù)和百分比值。

• Driver:從 4.0 版開始，JDBC API 支持 SPI 模式。舊版本使用 Class.forName() 方法加載驅(qū)動(dòng)程序。

• PersistenceProvider:提供 JPA API 的實(shí)現(xiàn)。

• 等等

除此以外，SPI 還有很多應(yīng)用，下面列舉幾個(gè)經(jīng)典案例。

4.1 SPI 應(yīng)用案例之 JDBC DriverManager

作為 Java 工程師，尤其是 CRUD 工程師，相必都非常熟悉 JDBC。眾所周知，關(guān)系型數(shù)據(jù)庫有很多種，如：MySQL、Oracle、PostgreSQL 等等。JDBC 如何識(shí)別各種數(shù)據(jù)庫的驅(qū)動(dòng)呢？

4.1.1創(chuàng)建數(shù)據(jù)庫連接

我們先回顧一下，JDBC 如何創(chuàng)建數(shù)據(jù)庫連接的呢？

在JDBC4.0 之前，連接數(shù)據(jù)庫的時(shí)候，通常會(huì)用 Class.forName(XXX)方法來加載數(shù)據(jù)庫相應(yīng)的驅(qū)動(dòng)，然后再獲取數(shù)據(jù)庫連接，繼而進(jìn)行 CRUD 等操作。

Class.forName("com.mysql.jdbc.Driver")

而 JDBC4.0 之后，不再需要用

Class.forName(XXX)方法來加載數(shù)據(jù)庫驅(qū)動(dòng)，直接獲取連接就可以了。顯然，這種方式很方便，但是如何做到的呢？

（1）JDBC 接口：首先，Java 中內(nèi)置了接口 java.sql.Driver。

（2）JDBC 接口實(shí)現(xiàn)：各個(gè)數(shù)據(jù)庫的驅(qū)動(dòng)自行實(shí)現(xiàn) java.sql.Driver 接口，用于管理數(shù)據(jù)庫連接。

① MySQL：在 MySQL的 Java 驅(qū)動(dòng)包 mysql-connector-java-XXX.jar 中，可以找到 META-INF/services 目錄，該目錄下會(huì)有一個(gè)名字為java.sql.Driver 的文件，文件內(nèi)容是com.mysql.cj.jdbc.Driver。

com.mysql.cj.jdbc.Driver 正是 MySQL 版的 java.sql.Driver 實(shí)現(xiàn)。如下圖所示：

②PostgreSQL 實(shí)現(xiàn)：在 PostgreSQL 的 Java 驅(qū)動(dòng)包 postgresql-42.0.0.jar 中，也可以找到同樣的配置文件，文件內(nèi)容是 org.postgresql.Driver，org.postgresql.Driver 正是 PostgreSQL 版的 java.sql.Driver 實(shí)現(xiàn)。

（3）創(chuàng)建數(shù)據(jù)庫連接

以 MySQL 為例，創(chuàng)建數(shù)據(jù)庫連接代碼如下：

final String DB_URL = String.format("jdbc//%s:%s/%s", DB_HOST, DB_PORT, DB_SCHEMA);
connection = DriverManager.getConnection(DB_URL, DB_USER, DB_PASSWORD);

4.1.2 DriverManager

從前文，我們已經(jīng)知道 DriverManager 是創(chuàng)建數(shù)據(jù)庫連接的關(guān)鍵。它究竟是如何工作的呢？

可以看到是加載實(shí)例化驅(qū)動(dòng)的，接著看 loadInitialDrivers 方法：

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;
  }
  // 通過 classloader 獲取所有實(shí)現(xiàn) java.sql.Driver 的驅(qū)動(dòng)類
  AccessController.doPrivileged(new PrivilegedAction() {
    public Void run() {
            // 利用 SPI，記載所有 Driver 服務(wù)
      ServiceLoader loadedDrivers = ServiceLoader.load(Driver.class);
            // 獲取迭代器
      Iterator driversIterator = loadedDrivers.iterator();
      try{
                // 遍歷迭代器
        while(driversIterator.hasNext()) {
          driversIterator.next();
        }
      } catch(Throwable t) {
      // Do nothing
      }
      return null;
    }
  });


    // 打印數(shù)據(jù)庫驅(qū)動(dòng)信息
  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);
            // 嘗試實(shí)例化驅(qū)動(dòng)
      Class.forName(aDriver, true,
          ClassLoader.getSystemClassLoader());
    } catch (Exception ex) {
      println("DriverManager.Initialize: load failed: " + ex);
    }
  }
}

上面的代碼主要步驟是：

1. 從系統(tǒng)變量中獲取驅(qū)動(dòng)的實(shí)現(xiàn)類。

2. 利用 SPI 來獲取所有驅(qū)動(dòng)的實(shí)現(xiàn)類。

3. 遍歷所有驅(qū)動(dòng)，嘗試實(shí)例化各個(gè)實(shí)現(xiàn)類。

4. 根據(jù)第 1 步獲取到的驅(qū)動(dòng)列表來實(shí)例化具體的實(shí)現(xiàn)類。

需要關(guān)注的是下面這行代碼：

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

這里實(shí)際獲取的是

java.util.ServiceLoader.LazyIterator 迭代器。調(diào)用其 hasNext 方法時(shí)，會(huì)搜索 classpath 下以及 jar 包中的 META-INF/services 目錄，查找 java.sql.Driver 文件，并找到文件中的驅(qū)動(dòng)實(shí)現(xiàn)類的全限定名。調(diào)用其 next 方法時(shí)，會(huì)根據(jù)驅(qū)動(dòng)類的全限定名去嘗試實(shí)例化一個(gè)驅(qū)動(dòng)類的對(duì)象。

4.2SPI 應(yīng)用案例之 Common-Loggin

common-logging（也稱 Jakarta Commons Logging，縮寫 JCL）是常用的日志門面工具包。

common-logging 的核心類是入口是 LogFactory，LogFatory 是一個(gè)抽象類，它負(fù)責(zé)加載具體的日志實(shí)現(xiàn)。

其入口方法是 LogFactory.getLog 方法，源碼如下：

public static Log getLog(Class clazz) throws LogConfigurationException {
  return getFactory().getInstance(clazz);
}


public static Log getLog(String name) throws LogConfigurationException {
  return getFactory().getInstance(name);
}

從以上源碼可知，getLog 采用了工廠設(shè)計(jì)模式，是先調(diào)用 getFactory 方法獲取具體日志庫的工廠類，然后根據(jù)類名稱或類型創(chuàng)建日志實(shí)例。

LogFatory.getFactory 方法負(fù)責(zé)選出匹配的日志工廠，其源碼如下：

public static LogFactory getFactory() throws LogConfigurationException {
  // 省略...


  // 加載 commons-logging.properties 配置文件
  Properties props = getConfigurationFile(contextClassLoader, FACTORY_PROPERTIES);


  // 省略...


    // 決定創(chuàng)建哪個(gè) LogFactory 實(shí)例
  // （1）嘗試讀取全局屬性 org.apache.commons.logging.LogFactory
  if (isDiagnosticsEnabled()) {
    logDiagnostic("[LOOKUP] Looking for system property [" + FACTORY_PROPERTY +
            "] to define the LogFactory subclass to use...");
  }


  try {
        // 如果指定了 org.apache.commons.logging.LogFactory 屬性，嘗試實(shí)例化具體實(shí)現(xiàn)類
    String factoryClass = getSystemProperty(FACTORY_PROPERTY, null);
    if (factoryClass != null) {
      if (isDiagnosticsEnabled()) {
        logDiagnostic("[LOOKUP] Creating an instance of LogFactory class '" + factoryClass +
                "' as specified by system property " + FACTORY_PROPERTY);
      }
      factory = newFactory(factoryClass, baseClassLoader, contextClassLoader);
    } else {
      if (isDiagnosticsEnabled()) {
        logDiagnostic("[LOOKUP] No system property [" + FACTORY_PROPERTY + "] defined.");
      }
    }
  } catch (SecurityException e) {
      // 異常處理
  } catch (RuntimeException e) {
      // 異常處理
  }


    // （2）利用 Java SPI 機(jī)制，嘗試在 classpatch 的 META-INF/services 目錄下尋找 org.apache.commons.logging.LogFactory 實(shí)現(xiàn)類
  if (factory == null) {
    if (isDiagnosticsEnabled()) {
      logDiagnostic("[LOOKUP] Looking for a resource file of name [" + SERVICE_ID +
              "] to define the LogFactory subclass to use...");
    }
    try {
      final InputStream is = getResourceAsStream(contextClassLoader, SERVICE_ID);


      if( is != null ) {
        // This code is needed by EBCDIC and other strange systems.
        // It's a fix for bugs reported in xerces
        BufferedReader rd;
        try {
          rd = new BufferedReader(new InputStreamReader(is, "UTF-8"));
        } catch (java.io.UnsupportedEncodingException e) {
          rd = new BufferedReader(new InputStreamReader(is));
        }


        String factoryClassName = rd.readLine();
        rd.close();


        if (factoryClassName != null && ! "".equals(factoryClassName)) {
          if (isDiagnosticsEnabled()) {
            logDiagnostic("[LOOKUP]  Creating an instance of LogFactory class " +
                    factoryClassName +
                    " as specified by file '" + SERVICE_ID +
                    "' which was present in the path of the context classloader.");
          }
          factory = newFactory(factoryClassName, baseClassLoader, contextClassLoader );
        }
      } else {
        // is == null
        if (isDiagnosticsEnabled()) {
          logDiagnostic("[LOOKUP] No resource file with name '" + SERVICE_ID + "' found.");
        }
      }
    } catch (Exception ex) {
      // note: if the specified LogFactory class wasn't compatible with LogFactory
      // for some reason, a ClassCastException will be caught here, and attempts will
      // continue to find a compatible class.
      if (isDiagnosticsEnabled()) {
        logDiagnostic(
          "[LOOKUP] A security exception occurred while trying to create an" +
          " instance of the custom factory class" +
          ": [" + trim(ex.getMessage()) +
          "]. Trying alternative implementations...");
      }
      // ignore
    }
  }


  // （3）嘗試從 classpath 目錄下的 commons-logging.properties 文件中查找 org.apache.commons.logging.LogFactory 屬性


  if (factory == null) {
    if (props != null) {
      if (isDiagnosticsEnabled()) {
        logDiagnostic(
          "[LOOKUP] Looking in properties file for entry with key '" + FACTORY_PROPERTY +
          "' to define the LogFactory subclass to use...");
      }
      String factoryClass = props.getProperty(FACTORY_PROPERTY);
      if (factoryClass != null) {
        if (isDiagnosticsEnabled()) {
          logDiagnostic(
            "[LOOKUP] Properties file specifies LogFactory subclass '" + factoryClass + "'");
        }
        factory = newFactory(factoryClass, baseClassLoader, contextClassLoader);


        // TODO: think about whether we need to handle exceptions from newFactory
      } else {
        if (isDiagnosticsEnabled()) {
          logDiagnostic("[LOOKUP] Properties file has no entry specifying LogFactory subclass.");
        }
      }
    } else {
      if (isDiagnosticsEnabled()) {
        logDiagnostic("[LOOKUP] No properties file available to determine" + " LogFactory subclass from..");
      }
    }
  }


  // （4）以上情況都不滿足，實(shí)例化默認(rèn)實(shí)現(xiàn)類 org.apache.commons.logging.impl.LogFactoryImpl


  if (factory == null) {
    if (isDiagnosticsEnabled()) {
      logDiagnostic(
        "[LOOKUP] Loading the default LogFactory implementation '" + FACTORY_DEFAULT +
        "' via the same classloader that loaded this LogFactory" +
        " class (ie not looking in the context classloader).");
    }


    factory = newFactory(FACTORY_DEFAULT, thisClassLoader, contextClassLoader);
  }


  if (factory != null) {
    /**
     * Always cache using context class loader.
     */
    cacheFactory(contextClassLoader, factory);


    if (props != null) {
      Enumeration names = props.propertyNames();
      while (names.hasMoreElements()) {
        String name = (String) names.nextElement();
        String value = props.getProperty(name);
        factory.setAttribute(name, value);
      }
    }
  }


  return factory;
}

從 getFactory 方法的源碼可以看出，其核心邏輯分為 4 步：

• 首先，嘗試查找全局屬性

  org.apache.commons.logging.LogFactory，如果指定了具體類，嘗試創(chuàng)建實(shí)例。

• 利用 Java SPI 機(jī)制，嘗試在 classpatch 的 META-INF/services 目錄下尋找

  org.apache.commons.logging.LogFactory 的實(shí)現(xiàn)類。

• 嘗試從 classpath 目錄下的 commons-logging.properties 文件中查找

  org.apache.commons.logging.LogFactory 屬性，如果指定了具體類，嘗試創(chuàng)建實(shí)例。

• 以上情況如果都不滿足，則實(shí)例化默認(rèn)實(shí)現(xiàn)類，即

  org.apache.commons.logging.impl.LogFactoryImpl。

4.3 SPI 應(yīng)用案例之 Spring Boot

Spring Boot 是基于 Spring 構(gòu)建的框架，其設(shè)計(jì)目的在于簡化 Spring 應(yīng)用的配置、運(yùn)行。在 Spring Boot 中，大量運(yùn)用了自動(dòng)裝配來盡可能減少配置。

下面是一個(gè) Spring Boot 入口示例，可以看到，代碼非常簡潔。

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;


@SpringBootApplication
@RestController
public class DemoApplication {


    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }


    @GetMapping("/hello")
    public String hello(@RequestParam(value = "name", defaultValue = "World") String name) {
        return String.format("Hello %s!", name);
    }
}

那么，Spring Boot 是如何做到寥寥幾行代碼，就可以運(yùn)行一個(gè) Spring Boot 應(yīng)用的呢。我們不妨帶著疑問，從源碼入手，一步步探究其原理。

4.3.1 @SpringBootApplication 注解

首先，Spring Boot 應(yīng)用的啟動(dòng)類上都會(huì)標(biāo)記一個(gè)

@SpringBootApplication 注解。

@SpringBootApplication 注解定義如下：

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(
    excludeFilters = {@Filter(
    type = FilterType.CUSTOM,
    classes = {TypeExcludeFilter.class}
), @Filter(
    type = FilterType.CUSTOM,
    classes = {AutoConfigurationExcludeFilter.class}
)}
)
public @interface SpringBootApplication {
    // 略
}

除了@Target、@Retention、@Documented、@Inherited 這幾個(gè)元注解，

@SpringBootApplication 注解的定義中還標(biāo)記了@SpringBootConfiguration、

@EnableAutoConfiguration、@ComponentScan 三個(gè)注解。

4.3.2 @SpringBootConfiguration 注解

從@SpringBootConfiguration 注解的定義來看，@SpringBootConfiguration 注解本質(zhì)上就是一個(gè)@Configuration 注解，這意味著被@SpringBootConfiguration 注解修飾的類會(huì)被 Spring Boot 識(shí)別為一個(gè)配置類。

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Configuration
public @interface SpringBootConfiguration {
    @AliasFor(
        annotation = Configuration.class
    )
    boolean proxyBeanMethods() default true;
}

4.3.3 @EnableAutoConfiguration 注解

@EnableAutoConfiguration 注解定義如下：

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@AutoConfigurationPackage
@Import({AutoConfigurationImportSelector.class})
public @interface EnableAutoConfiguration {
    String ENABLED_OVERRIDE_PROPERTY = "spring.boot.enableautoconfiguration";


    Class[] exclude() default {};


    String[] excludeName() default {};
}

@EnableAutoConfiguration 注解包含了@AutoConfigurationPackage

與@Import({AutoConfigurationImportSelector.class})兩個(gè)注解。

4.3.4 @AutoConfigurationPackage 注解

@AutoConfigurationPackage 會(huì)將被修飾的類作為主配置類，該類所在的 package 會(huì)被視為根路徑，Spring Boot 默認(rèn)會(huì)自動(dòng)掃描根路徑下的所有 Spring Bean（被@Component 以及繼承@Component 的各個(gè)注解所修飾的類）?！@就是為什么 Spring Boot 的啟動(dòng)類一般要置于根路徑的原因。這個(gè)功能等同于在 Spring xml 配置中通過 context:component-scan 來指定掃描路徑。@Import 注解的作用是向 Spring 容器中直接注入指定組件。@AutoConfigurationPackage 注解中注明了@Import({Registrar.class})。Registrar 類用于保存 Spring Boot 的入口類、根路徑等信息。

4.3.5 SpringFactoriesLoader.loadFactoryNames 方法

@Import(AutoConfigurationImportSelector.class)表示直接注入

AutoConfigurationImportSelector。

AutoConfigurationImportSelector 有一個(gè)核心方法

getCandidateConfigurations 用于獲取候選配置。該方法調(diào)用了

SpringFactoriesLoader.loadFactoryNames 方法，這個(gè)方法即為 Spring Boot SPI 的關(guān)鍵，它負(fù)責(zé)加載所有 META-INF/spring.factories 文件，加載的過程由 SpringFactoriesLoader 負(fù)責(zé)。

Spring Boot 的 META-INF/spring.factories 文件本質(zhì)上就是一個(gè) properties 文件，數(shù)據(jù)內(nèi)容就是一個(gè)個(gè)鍵值對(duì)。

SpringFactoriesLoader.loadFactoryNames 方法的關(guān)鍵源碼：

// spring.factories 文件的格式為：key=value1,value2,value3
// 遍歷所有 META-INF/spring.factories 文件
// 解析文件，獲得 key=factoryClass 的類名稱
public static List<String> loadFactoryNames(Class factoryType, @Nullable ClassLoader classLoader) {
  String factoryTypeName = factoryType.getName();
  return loadSpringFactories(classLoader).getOrDefault(factoryTypeName, Collections.emptyList());
}


private static Map<String, List<String>> loadSpringFactories(@Nullable ClassLoader classLoader) {
  // 嘗試獲取緩存，如果緩存中有數(shù)據(jù)，直接返回
  MultiValueMap<String, String> result = cache.get(classLoader);
  if (result != null) {
    return result;
  }


  try {
    // 獲取資源文件路徑
    Enumeration urls = (classLoader != null ?
        classLoader.getResources(FACTORIES_RESOURCE_LOCATION) :
        ClassLoader.getSystemResources(FACTORIES_RESOURCE_LOCATION));
    result = new LinkedMultiValueMap<>();
    // 遍歷所有路徑
    while (urls.hasMoreElements()) {
      URL url = urls.nextElement();
      UrlResource resource = new UrlResource(url);
      // 解析文件，得到對(duì)應(yīng)的一組 Properties
      Properties properties = PropertiesLoaderUtils.loadProperties(resource);
      // 遍歷解析出的 properties，組裝數(shù)據(jù)
      for (Map.Entry entry : properties.entrySet()) {
        String factoryTypeName = ((String) entry.getKey()).trim();
        for (String factoryImplementationName : StringUtils.commaDelimitedListToStringArray((String) entry.getValue())) {
          result.add(factoryTypeName, factoryImplementationName.trim());
        }
      }
    }
    cache.put(classLoader, result);
    return result;
  }
  catch (IOException ex) {
    throw new IllegalArgumentException("Unable to load factories from location [" +
        FACTORIES_RESOURCE_LOCATION + "]", ex);
  }
}

歸納上面的方法，主要作了這些事：

加載所有 META-INF/spring.factories 文件，加載過程有 SpringFactoriesLoader 負(fù)責(zé)。

• 在 CLASSPATH 中搜尋所有 META-INF/spring.factories 配置文件。

• 然后，解析 spring.factories 文件，獲取指定自動(dòng)裝配類的全限定名。

4.3.6 Spring Boot 的 AutoConfiguration 類

Spring Boot 有各種 starter 包，可以根據(jù)實(shí)際項(xiàng)目需要，按需取材。在項(xiàng)目開發(fā)中，只要將 starter 包引入，我們就可以用很少的配置，甚至什么都不配置，即可獲取相關(guān)的能力。通過前面的 Spring Boot SPI 流程，只完成了自動(dòng)裝配工作的一半，剩下的工作如何處理呢 ？

以 spring-boot-starter-web 的 jar 包為例，查看其 maven pom，可以看到，它依賴于 spring-boot-starter，所有 Spring Boot 官方 starter 包都會(huì)依賴于這個(gè) jar 包。而 spring-boot-starter 又依賴于 spring-boot-autoconfigure，Spring Boot 的自動(dòng)裝配秘密，就在于這個(gè) jar 包。

從 spring-boot-autoconfigure 包的結(jié)構(gòu)來看，它有一個(gè) META-INF/spring.factories ，顯然利用了 Spring Boot SPI，來自動(dòng)裝配其中的配置類。

下圖是 spring-boot-autoconfigure 的 META-INF/spring.factories 文件的部分內(nèi)容，可以看到其中注冊(cè)了一長串會(huì)被自動(dòng)加載的 AutoConfiguration 類。

以 RedisAutoConfiguration 為例，這個(gè)配置類中，會(huì)根據(jù)@ConditionalXXX 中的條件去決定是否實(shí)例化對(duì)應(yīng)的 Bean，實(shí)例化 Bean 所依賴的重要參數(shù)則通過 RedisProperties 傳入。

RedisProperties 中維護(hù)了 Redis 連接所需要的關(guān)鍵屬性，只要在 yml 或 properties 配置文件中，指定 spring.redis 開頭的屬性，都會(huì)被自動(dòng)裝載到 RedisProperties 實(shí)例中。

通過以上分析，已經(jīng)一步步解讀出 Spring Boot 自動(dòng)裝載的原理。

五、SPI 應(yīng)用案例之 Dubbo

Dubbo 并未使用 Java SPI，而是自己封裝了一套新的 SPI 機(jī)制。Dubbo SPI 所需的配置文件需放置在 META-INF/dubbo 路徑下，配置內(nèi)容形式如下：

optimusPrime = org.apache.spi.OptimusPrime
bumblebee = org.apache.spi.Bumblebee

與 Java SPI 實(shí)現(xiàn)類配置不同，Dubbo SPI 是通過鍵值對(duì)的方式進(jìn)行配置，這樣可以按需加載指定的實(shí)現(xiàn)類。Dubbo SPI 除了支持按需加載接口實(shí)現(xiàn)類，還增加了 IOC 和 AOP 等特性。

5.1 ExtensionLoader 入口

Dubbo SPI 的相關(guān)邏輯被封裝在了 ExtensionLoader 類中，通過 ExtensionLoader，可以加載指定的實(shí)現(xiàn)類。

ExtensionLoader 的 getExtension 方法是其入口方法，其源碼如下：

public T getExtension(String name) {
    if (name == null || name.length() == 0)
        throw new IllegalArgumentException("Extension name == null");
    if ("true".equals(name)) {
        // 獲取默認(rèn)的拓展實(shí)現(xiàn)類
        return getDefaultExtension();
    }
    // Holder，顧名思義，用于持有目標(biāo)對(duì)象
    Holder