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

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

這里，摘取LazyIterator關鍵代碼

hasNextService 方法：

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

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

• 解析資源文件中的內容，獲取 SPI 接口的實現類的全限定名nextName

nextService 方法：

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

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

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

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

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

雙親委派機制約定了：一個類加載器首先將類加載請求傳送到父類加載器，只有當父類加載器無法完成類加載請求時才嘗試加載。

雙親委派的好處：使得 Java 類伴隨著它的類加載器，天然具備一種帶有優先級的層次關系，從而使得類加載得到統一，不會出現重復加載的問題：

• 系統類防止內存中出現多份同樣的字節碼

• 保證 Java 程序安全穩定運行

例如：java.lang.Object 存放在 rt.jar 中，如果編寫另外一個 java.lang.Object 的類并放到 classpath 中，程序可以編譯通過。因為雙親委派模型的存在，所以在 rt.jar 中的 Object 比在 classpath 中的 Object 優先級更高，因為 rt.jar 中的 Object 使用的是啟動類加載器，而 classpath 中的 Object 使用的是應用程序類加載器。正因為 rt.jar 中的 Object 優先級更高，因為程序中所有的 Object 都是這個 Object。

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

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

• 而 SPI 實現的 Java 類一般是由 AppClassLoader 來加載的。BootstrapClassLoader 是無法找到 SPI 的實現類的，因為它只加載 Java 的核心庫。它也不能代理給 AppClassLoader，因為它是最頂層的類加載器。這也解釋了本節開始的問題——為什么加載 SPI 服務時，需要指定類加載器 ClassLoader 呢？因為如果不指定 ClassLoader，則無法獲取 SPI 服務。

如果不做任何的設置，Java 應用的線程的上下文類加載器默認就是 AppClassLoader。在核心類庫使用 SPI 接口時，傳遞的類加載器使用線程上下文類加載器，就可以成功的加載到 SPI 實現的類。線程上下文類加載器在很多 SPI 的實現中都會用到。

通?？梢酝ㄟ^

Thread.currentThread().getClassLoader()

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

3.4 Java SPI 的不足

Java SPI 存在一些不足：

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

• 獲取某個實現類的方式不夠靈活，只能通過 Iterator 形式獲取，不能根據某個參數來獲取對應的實現類。

• 多個并發多線程使用 ServiceLoader 類的實例是不安全的。

四、SPI 應用場景

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

• TimeZoneNameProvider:為 TimeZone 類提供本地化的時區名稱。

• DateFormatProvider:為指定的語言環境提供日期和時間格式。

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

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

• PersistenceProvider:提供 JPA API 的實現。

• 等等

除此以外，SPI 還有很多應用，下面列舉幾個經典案例。

4.1 SPI 應用案例之 JDBC DriverManager

作為 Java 工程師，尤其是 CRUD 工程師，相必都非常熟悉 JDBC。眾所周知，關系型數據庫有很多種，如：MySQL、Oracle、PostgreSQL 等等。JDBC 如何識別各種數據庫的驅動呢？

4.1.1創建數據庫連接

我們先回顧一下，JDBC 如何創建數據庫連接的呢？

在JDBC4.0 之前，連接數據庫的時候，通常會用 Class.forName(XXX)方法來加載數據庫相應的驅動，然后再獲取數據庫連接，繼而進行 CRUD 等操作。

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

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

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

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

（2）JDBC 接口實現：各個數據庫的驅動自行實現 java.sql.Driver 接口，用于管理數據庫連接。

① MySQL：在 MySQL的 Java 驅動包 mysql-connector-java-XXX.jar 中，可以找到 META-INF/services 目錄，該目錄下會有一個名字為java.sql.Driver 的文件，文件內容是com.mysql.cj.jdbc.Driver。

com.mysql.cj.jdbc.Driver 正是 MySQL 版的 java.sql.Driver 實現。如下圖所示：

②PostgreSQL 實現：在 PostgreSQL 的 Java 驅動包 postgresql-42.0.0.jar 中，也可以找到同樣的配置文件，文件內容是 org.postgresql.Driver，org.postgresql.Driver 正是 PostgreSQL 版的 java.sql.Driver 實現。

（3）創建數據庫連接

以 MySQL 為例，創建數據庫連接代碼如下：

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

從前文，我們已經知道 DriverManager 是創建數據庫連接的關鍵。它究竟是如何工作的呢？

可以看到是加載實例化驅動的，接著看 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 獲取所有實現 java.sql.Driver 的驅動類
  AccessController.doPrivileged(new PrivilegedAction() {
    public Void run() {
            // 利用 SPI，記載所有 Driver 服務
      ServiceLoader loadedDrivers = ServiceLoader.load(Driver.class);
            // 獲取迭代器
      Iterator 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);
    }
  }
}

上面的代碼主要步驟是：

1. 從系統變量中獲取驅動的實現類。

2. 利用 SPI 來獲取所有驅動的實現類。

3. 遍歷所有驅動，嘗試實例化各個實現類。

4. 根據第 1 步獲取到的驅動列表來實例化具體的實現類。

需要關注的是下面這行代碼：

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

這里實際獲取的是

java.util.ServiceLoader.LazyIterator 迭代器。調用其 hasNext 方法時，會搜索 classpath 下以及 jar 包中的 META-INF/services 目錄，查找 java.sql.Driver 文件，并找到文件中的驅動實現類的全限定名。調用其 next 方法時，會根據驅動類的全限定名去嘗試實例化一個驅動類的對象。

4.2SPI 應用案例之 Common-Loggin

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

common-logging 的核心類是入口是 LogFactory，LogFatory 是一個抽象類，它負責加載具體的日志實現。

其入口方法是 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 采用了工廠設計模式，是先調用 getFactory 方法獲取具體日志庫的工廠類，然后根據類名稱或類型創建日志實例。

LogFatory.getFactory 方法負責選出匹配的日志工廠，其源碼如下：

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


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


  // 省略...


    // 決定創建哪個 LogFactory 實例
  // （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 屬性，嘗試實例化具體實現類
    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 機制，嘗試在 classpatch 的 META-INF/services 目錄下尋找 org.apache.commons.logging.LogFactory 實現類
  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）以上情況都不滿足，實例化默認實現類 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，如果指定了具體類，嘗試創建實例。

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

  org.apache.commons.logging.LogFactory 的實現類。

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

  org.apache.commons.logging.LogFactory 屬性，如果指定了具體類，嘗試創建實例。

• 以上情況如果都不滿足，則實例化默認實現類，即

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

4.3 SPI 應用案例之 Spring Boot

Spring Boot 是基于 Spring 構建的框架，其設計目的在于簡化 Spring 應用的配置、運行。在 Spring Boot 中，大量運用了自動裝配來盡可能減少配置。

下面是一個 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 是如何做到寥寥幾行代碼，就可以運行一個 Spring Boot 應用的呢。我們不妨帶著疑問，從源碼入手，一步步探究其原理。

4.3.1 @SpringBootApplication 注解

首先，Spring Boot 應用的啟動類上都會標記一個

@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 這幾個元注解，

@SpringBootApplication 注解的定義中還標記了@SpringBootConfiguration、

@EnableAutoConfiguration、@ComponentScan 三個注解。

4.3.2 @SpringBootConfiguration 注解

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

@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})兩個注解。

4.3.4 @AutoConfigurationPackage 注解

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

4.3.5 SpringFactoriesLoader.loadFactoryNames 方法

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

AutoConfigurationImportSelector。

AutoConfigurationImportSelector 有一個核心方法

getCandidateConfigurations 用于獲取候選配置。該方法調用了

SpringFactoriesLoader.loadFactoryNames 方法，這個方法即為 Spring Boot SPI 的關鍵，它負責加載所有 META-INF/spring.factories 文件，加載的過程由 SpringFactoriesLoader 負責。

Spring Boot 的 META-INF/spring.factories 文件本質上就是一個 properties 文件，數據內容就是一個個鍵值對。

SpringFactoriesLoader.loadFactoryNames 方法的關鍵源碼：

// 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) {
  // 嘗試獲取緩存，如果緩存中有數據，直接返回
  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);
      // 解析文件，得到對應的一組 Properties
      Properties properties = PropertiesLoaderUtils.loadProperties(resource);
      // 遍歷解析出的 properties，組裝數據
      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 負責。

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

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

4.3.6 Spring Boot 的 AutoConfiguration 類

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

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

從 spring-boot-autoconfigure 包的結構來看，它有一個 META-INF/spring.factories ，顯然利用了 Spring Boot SPI，來自動裝配其中的配置類。

下圖是 spring-boot-autoconfigure 的 META-INF/spring.factories 文件的部分內容，可以看到其中注冊了一長串會被自動加載的 AutoConfiguration 類。

以 RedisAutoConfiguration 為例，這個配置類中，會根據@ConditionalXXX 中的條件去決定是否實例化對應的 Bean，實例化 Bean 所依賴的重要參數則通過 RedisProperties 傳入。

RedisProperties 中維護了 Redis 連接所需要的關鍵屬性，只要在 yml 或 properties 配置文件中，指定 spring.redis 開頭的屬性，都會被自動裝載到 RedisProperties 實例中。

通過以上分析，已經一步步解讀出 Spring Boot 自動裝載的原理。

五、SPI 應用案例之 Dubbo

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

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

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

5.1 ExtensionLoader 入口

Dubbo SPI 的相關邏輯被封裝在了 ExtensionLoader 類中，通過 ExtensionLoader，可以加載指定的實現類。

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

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