為什么 SpringBoot 寧可挨罵也要干掉 spring.factories？

作者：AWen_X 2025-07-16 07:10:00

開發

SpringBoot 3.0之后取消了spring.factories，本文將深入探討這一變更的原因、影響以及替代方案。

一、引言

在SpringBoot的演進過程中，3.0版本帶來了一次重大變革——取消了長期以來作為自動配置和擴展機制核心的spring.factories文件。這個改變對于習慣了SpringBoot舊版本開發的工程師來說，需要了解新的機制和遷移策略。

本文將深入探討這一變更的原因、影響以及替代方案。

二、spring.factories是什么

在討論它的取消之前，我們首先需要理解spring.factories文件在SpringBoot中扮演的角色。

1. 基本概念

spring.factories是一個位于META-INF/目錄下的配置文件，它基于Java的SPI(Service Provider Interface)機制的變種實現。這個文件的主要功能是允許開發者聲明接口的實現類，從而實現SpringBoot的自動裝配和擴展點注冊。

2. 主要用途

在SpringBoot 3.0之前，spring.factories文件有以下幾個主要用途：

3. 工作原理

SpringBoot啟動時，會使用SpringFactoriesLoader類掃描類路徑下所有JAR包中的META-INF/spring.factories文件，讀取配置信息并加載對應的類。這種機制使得SpringBoot能夠以"約定優于配置"的方式實現自動裝配。

// SpringFactoriesLoader核心代碼示例（SpringBoot 2.x）
publicfinalclassSpringFactoriesLoader{
    // ...
    publicstatic <T> List<T> loadFactories(Class<T> factoryType, @Nullable ClassLoader classLoader){
        // ... 
        // 加載META-INF/spring.factories中的配置
        Map<String, List<String>> result = loadSpringFactories(classLoader);
        // ...
    }
    
    privatestatic Map<String, List<String>> loadSpringFactories(@Nullable ClassLoader classLoader) {
        // 從類路徑中加載所有META-INF/spring.factories文件
        // ...
    }
    // ...
}

三、為什么要取消spring.factories

SpringBoot團隊決定取消spring.factories機制有幾個關鍵原因：

1. 性能問題

spring.factories機制需要在啟動時掃描所有JAR包中的配置文件，當項目依賴較多時，這個過程會消耗大量時間，影響應用啟動性能。

2. 缺乏模塊化支持

隨著Java 9引入模塊系統(JPMS)，傳統的基于類路徑掃描的方式與模塊化設計理念存在沖突。spring.factories無法很好地支持Java模塊系統。

3. 缺乏條件加載能力

spring.factories文件中的配置是靜態的，無法根據條件動態決定是否加載某個實現。雖然可以在實現類上使用@Conditional注解，但這種方式效率較低，因為所有類都會被加載到內存中進行條件評估。

4. 配置分散難以管理

在大型項目中，spring.factories配置分散在多個JAR包中，難以集中管理和查看全局配置。

5. GraalVM原生鏡像支持

SpringBoot 3.0的一個重要目標是提供對GraalVM原生鏡像的一流支持。而spring.factories基于運行時類路徑掃描的機制與GraalVM的提前編譯(Ahead-of-Time Compilation, AOT)模型存在根本性沖突。具體來說：

靜態分析限制： GraalVM在構建原生鏡像時需要靜態分析代碼，而spring.factories的類路徑掃描是動態執行的，無法在構建時確定。
反射使用問題：spring.factories依賴于反射加載類，而GraalVM需要預先知道所有使用反射的類，這需要額外的配置和處理。
資源訪問限制：在GraalVM原生鏡像中，資源文件的訪問機制與JVM有所不同，spring.factories文件的掃描方式需要特殊處理。

為了更好地支持GraalVM，SpringBoot需要一種在構建時就能確定的靜態配置方式，而不是運行時的動態掃描。

四、替代方案：imports文件

1. 新機制介紹

從SpringBoot 3.0開始，引入了基于imports文件的新機制，作為spring.factories的替代方案。這些文件位于META-INF/spring/目錄下，每種類型的擴展點對應一個專門的文件：

2. 新機制優勢

更好的性能：每種擴展點類型使用單獨的文件，避免了加載不必要的配置
支持Java模塊系統：新機制與Java模塊系統兼容
簡化配置：每行一個全限定類名，無需鍵值對形式，更易讀易寫
更好的組織結構：配置按功能分類到不同文件，結構更清晰

3. 示例對比

舊方式（spring.factories）：

org.springframework.boot.autoconfigure.EnableAutoCnotallow=\
com.example.FooAutoConfiguration,\
com.example.BarAutoConfiguration

新方式（AutoConfiguration.imports）：

com.example.FooAutoConfiguration
com.example.BarAutoConfiguration

五、遷移指南

1. 自動配置類遷移

將原來在spring.factories中注冊的自動配置類移動到META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件中：

// 原來的自動配置類
@Configuration
@ConditionalOnXxx
publicclassMyAutoConfiguration{
    // ...
}

// 在META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件中添加：
// com.example.MyAutoConfiguration

2. 其他擴展點如何遷移

對于其他類型的擴展點，SpringBoot 3.0保留了spring.factories機制，但推薦在新項目中使用新的注冊方式：

// 示例：注冊ApplicationListener
// SpringBoot 3.0之前：在spring.factories中配置
// org.springframework.context.Applicatinotallow=com.example.MyListener

// SpringBoot 3.0之后：使用@Bean方式注冊
@Configuration
publicclassMyConfiguration{
    @Bean
    public MyListener myListener(){
        returnnew MyListener();
    }
}

3. 自定義擴展點遷移

對于自定義的擴展點，需要提供類似的imports文件機制：

// 自定義擴展點加載器示例
publicclassMyExtensionLoader{
    public List<MyExtension> loadExtensions(){
        return SpringFactoriesLoader.loadFactories(MyExtension.class, null);
    }
}

// 遷移到新機制
publicclassMyExtensionLoader{
    public List<MyExtension> loadExtensions(){
        List<String> classNames = SpringFactoriesLoader.loadFactoryNames(
            MyExtension.class, null);
        // 或者實現自己的imports文件加載邏輯
        // ...
    }
}

六、SpringFactoriesLoader的變化

1. API變更

在SpringBoot 3.0中，SpringFactoriesLoader類本身也經歷了重大改變：

// SpringBoot 3.x中新的SpringFactoriesLoader用法
publicfinalclassSpringFactoriesLoader{
    // 過時的方法
    @Deprecated
    publicstatic <T> List<T> loadFactories(Class<T> factoryType, @Nullable ClassLoader classLoader){
        // ...
    }
    
    // 新方法
    publicstatic List<String> loadFactoryNames(Class<?> factoryType, @Nullable ClassLoader classLoader){
        // 加載對應的imports文件
        // ...
    }
    
    // ...
}

2. 兼容性考慮

為了保持向后兼容性，SpringBoot 3.0仍然支持通過spring.factories注冊某些類型的擴展點，但新的項目應該優先考慮使用新機制。

七、實戰示例

1. 創建自定義自動配置

下面是一個完整的示例，展示如何在SpringBoot 3.0中創建和注冊自動配置：

// 1. 創建配置屬性類
@ConfigurationProperties(prefix = "myapp")
publicclassMyProperties{
    privateboolean enabled = true;
    private String name = "default";
    
    // getter和setter方法
    // ...
}

// 2. 創建自動配置類
@AutoConfiguration// 注意這里使用了@AutoConfiguration而非@Configuration
@EnableConfigurationProperties(MyProperties.class)
@ConditionalOnProperty(prefix= "myapp", name = "enabled", havingValue = "true", matchIfMissing = true)
publicclassMyAutoConfiguration{
    
    privatefinal MyProperties properties;
    
    publicMyAutoConfiguration(MyProperties properties){
        this.properties = properties;
    }
    
    @Bean
    @ConditionalOnMissingBean
    public MyService myService(){
        // 根據屬性創建服務
        returnnew MyServiceImpl(properties.getName());
    }
}

2. 注冊自動配置

然后，在META-INF/spring/目錄下創建org.springframework.boot.autoconfigure.AutoConfiguration.imports文件：

com.example.MyAutoConfiguration

3. 項目結構

完整的項目結構如下：

myproject/
├── src/
│   └── main/
│       ├── java/
│       │   └── com/
│       │       └── example/
│       │           ├── MyProperties.java
│       │           ├── MyService.java
│       │           ├── MyServiceImpl.java
│       │           └── MyAutoConfiguration.java
│       └── resources/
│           └── META-INF/
│               └── spring/
│                   └── org.springframework.boot.autoconfigure.AutoConfiguration.imports
└── pom.xml

八、性能對比

在一個典型的中型SpringBoot應用中，使用新機制后的啟動性能對比：

注：實際性能提升取決于項目規模和結構

九、常見問題與解決方案

1. 兼容性問題

問題：現有的依賴庫仍使用spring.factories，會有兼容問題嗎？

解決方案：SpringBoot 3.0保留了對spring.factories的支持，舊的庫仍然可以正常工作。但新的代碼應該使用新機制。

2. 遷移困難

問題：大型項目遷移到新機制工作量大

解決方案：可以分階段遷移，先遷移自動配置類，再逐步遷移其他擴展點。

3. 自定義加載器

問題：自定義的SpringFactoriesLoader使用者如何遷移？

解決方案：參考SpringBoot的新實現，為自定義擴展點提供類似的imports文件加載機制。

十、SpringBoot 3.0與GraalVM集成

SpringBoot 3.0對GraalVM的支持是取消spring.factories的主要原因之一。

1. GraalVM簡介

GraalVM是一個高性能的JDK實現，它的一個重要特性是能夠將Java應用編譯成獨立的原生可執行文件（Native Image）。這些原生鏡像具有以下特點：

快速啟動：啟動時間通常在毫秒級，比傳統JVM應用快10-100倍
低內存占用：內存占用顯著降低，適合云原生和容器環境
無需JVM：可以獨立運行，不需要Java運行時環境
預先編譯：所有代碼在構建時就編譯為機器碼，而非運行時編譯

2. SpringBoot對GraalVM的支持挑戰

SpringBoot框架面臨的主要挑戰是其動態特性與GraalVM靜態分析模型之間的矛盾：

3. imports文件與GraalVM的兼容性

新的imports文件機制解決了與GraalVM集成的關鍵問題：

靜態可分析性： imports文件中明確列出所有配置類，可以在構建時靜態分析
路徑明確性：每種擴展點對應特定的文件路徑，減少了運行時掃描
更少的反射： imports文件的解析機制更簡單，減少了對反射的依賴
構建時處理：可以在AOT編譯階段處理imports文件并生成相應的元數據

4. SpringBoot AOT引擎

為了更好地支持GraalVM，SpringBoot 3.0引入了一個新的AOT引擎，它在構建時執行以下操作：

// SpringBoot 3.0 AOT處理示例
publicclassSpringAotProcessor{
    publicvoidprocess(){
        // 1. 讀取imports文件而非掃描spring.factories
        List<String> configurations = readImportsFiles();
        
        // 2. 預先評估條件而非運行時評估
        List<String> effectiveConfigurations = 
            evaluateConditions(configurations, buildTimeProperties);
        
        // 3. 生成代理類而非運行時動態生成
        generateProxies(effectiveConfigurations);
        
        // 4. 生成反射配置
        generateReflectionConfig(effectiveConfigurations);
        
        // 5. 生成資源配置
        generateResourcesConfig();
    }
}

5. GraalVM集成實例

下面是一個完整的示例，展示如何在SpringBoot 3.0項目中配置和構建GraalVM原生鏡像：

Maven配置：

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.experimental</groupId>
        <artifactId>spring-native</artifactId>
        <version>${spring-native.version}</version>
    </dependency>
</dependencies>

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <configuration>
                <image>
                    <builder>paketobuildpacks/builder:tiny</builder>
                    <env>
                        <BP_NATIVE_IMAGE>true</BP_NATIVE_IMAGE>
                    </env>
                </image>
            </configuration>
        </plugin>
        <plugin>
            <groupId>org.springframework.experimental</groupId>
            <artifactId>spring-aot-maven-plugin</artifactId>
            <executions>
                <execution>
                    <id>generate</id>
                    <goals>
                        <goal>generate</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

自動配置遷移示例：

// 舊的方式 - spring.factories配置:
// META-INF/spring.factories:
// org.springframework.boot.autoconfigure.EnableAutoCnotallow=com.example.MyNativeCompatibleConfig

// 新的方式 - imports文件:
// META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports:
// com.example.MyNativeCompatibleConfig

// 自動配置類
@AutoConfiguration
@NativeHint(options = "--enable-url-protocols=http") // GraalVM特定的提示
publicclassMyNativeCompatibleConfig{
    @Bean
    public MyService myService(){
        returnnew MyNativeCompatibleService();
    }
}

6. 性能對比：傳統JVM vs GraalVM原生鏡像

使用新的imports機制后，SpringBoot應用在GraalVM原生鏡像中的性能表現：

7. GraalVM集成的優秀實踐

減少反射使用：盡量使用構造函數注入而非字段注入
避免動態代理：減少使用需要動態代理的特性
靜態初始化：在構建時初始化靜態數據而非運行時
使用imports文件：確保所有配置類都通過imports文件注冊
添加必要的提示：使用@NativeHint等注解提供GraalVM所需的提示

8. GraalVM集成的限制和注意事項

動態特性受限：諸如運行時生成字節碼、動態加載類等特性在原生鏡像中受限
反射使用：必須明確聲明使用反射的類
構建時間：原生鏡像構建時間較長，需要合理規劃CI/CD流程
調試復雜度：原生鏡像的調試比傳統JVM更復雜
第三方庫兼容性：某些依賴可能尚未針對GraalVM優化

通過取消spring.factories并引入新的imports文件機制，SpringBoot 3.0顯著改善了與GraalVM的集成體驗，讓開發者能夠更容易地構建高性能、低延遲的云原生應用。

責任編輯：趙寧寧來源：碼猿技術專欄

SpringBoot