SpringBoot 3.0之后为何取消spring.factories？原因影响及替代方案揭秘

身为长期留意开发工具演变的技术媒体从业者，在目睹SpringBoot 3.0把spring.factories的消息给取消之际，我的首个反应是这着实是个大胆的突破。虽说这种变动或许会致使部分开发者得花时间去适应，不过从技术演进的层面来讲，这种改变恰好展现了Spring团队对于性能以及现代化部署的严谨态度。尤其是在云原生跟GraalVM原生编译渐渐成为主流的当下，这样的调整确实很有必要。

背景与演进动因

// SpringFactoriesLoader核心代码示例（SpringBoot 2.x）
publicfinalclassSpringFactoriesLoader{
    // ...
    publicstatic <T> List<T> loadFactories(Class 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文件
        // ...
    }
    // ...
}

从SpringBoot问世开始，它就凭借那便利的自动配置机制，深受那些开发者的喜爱。spring.factories身为这一机制的关键体现，靠着声明接口实现类的办法，达成了组件的自动注册以及装配。可是呢，随着技术栈变得复杂起来，以及应用部署环境呈现出多样化，这一机制渐渐暴露出它的局限性。

在模块化支持以及条件化加载这两方面，spring.factories的静态配置方式很难满足动态场景提出的需求，尽管开发者能够借助@Conditional系列注解实现一定程度的条件控制，然而从本质上来说，所有声明在文件里的类依旧会被加载到内存当中用以评估，进而造成不必要的资源消耗。

与GraalVM的兼容挑战

更为重中之要的是，那 spring.factoires 所依循的基于类路径扫描的运行机制，与 GraalVM 的 AOT 编译模式，在架构方面存有冲突。GraalVM 身为新一代具备高性能的 JDK，它能够支持把 Java 应用编译成独立的原生镜像，如此便极大程度地提升了启动的速度以及运行的效率。

然而，其AOT机制有着这样的要求，即所有在运行时会被使用的类，必须在编译时就确切地已知，可是弹簧工厂的动态发现机制却与这一要求完全相反，这就成为了SpringBoot应用朝着原生云应用迈进过程中的一个重大技术障碍。

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

新机制的核心设计

com.example.FooAutoConfiguration
com.example.BarAutoConfiguration

针对上述已经摆出的那些方面的问题，SpringBoot 3.0引入了全新的注册机制，此机制是基于imports文件的。那个文件采用的是类似SPI的格式，它明确地声明了那些需要去导入的配置类，借由这样的方式，能够在编译阶段的时候就确定好所有需要用到的组件，如此一来就可以完美地适配GraalVM的AOT要求啦。

// 原来的自动配置类
@Configuration
@ConditionalOnXxx
publicclassMyAutoConfiguration{
    // ...
}
// 在META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件中添加：
// com.example.MyAutoConfiguration

新机制不但对自动配置类注册予以支持，更给出了更为灵活的条件化加载本领，开发者能够于imports文件里运用条件注释，依据特定的环境变量或者配置参数来判定是否加载某一个组件，达成了切实的按需加载。

// 示例：注册ApplicationListener
// SpringBoot 3.0之前：在spring.factories中配置
// org.springframework.context.ApplicationListener=com.example.MyListener
// SpringBoot 3.0之后：使用@Bean方式注册
@Configuration
publicclassMyConfiguration{
    @Bean
    public MyListener myListener(){
        returnnew MyListener();
    }
}

实战效果与性能提升

于实际项目里，新机制呈现出明显之性能优势，依官方测试数据看，其一典型的中型SpringBoot应用于采用imports文件后，启动时间平均削减了30%以上，且内存占用亦降低了约25% 。

// 自定义扩展点加载器示例
publicclassMyExtensionLoader{
    public List loadExtensions(){
        return SpringFactoriesLoader.loadFactories(MyExtension.class, null);
    }
}
// 迁移到新机制
publicclassMyExtensionLoader{
    public List loadExtensions(){
        List classNames = SpringFactoriesLoader.loadFactoryNames(
            MyExtension.class, null);
        // 或者实现自己的imports文件加载逻辑
        // ...
    }
}

尤其特别是处于GraalVM原生镜像环境里，新的应用启动所耗费的时间，由原本的数秒大大缩短至毫秒的级别，实实在在达成了瞬间启动的效果。此项提升，对于那些有着需要快速进行扩缩容需求的云原生应用场景而言，具备相当显著的革命性意义。

向后兼容性处理

// SpringBoot 3.x中新的SpringFactoriesLoader用法
publicfinalclassSpringFactoriesLoader{
    // 过时的方法
    @Deprecated
    publicstatic  List loadFactories(Class factoryType, @Nullable ClassLoader classLoader){
        // ...
    }
    
    // 新方法
    publicstatic List loadFactoryNames(Class factoryType, @Nullable ClassLoader classLoader){
        // 加载对应的imports文件
        // ...
    }
    
    // ...
}

鉴于生态系统的平稳过渡这一考量因素，SpringBoot的3.0版本运用了渐进式的迁移策略。就原有的spring.factories文件而言，框架依旧给予完全兼容的支持，以此保证现有的第三方库能够持续正常运行。

然而与此同时官方明确给出建议说，新的项目应该要优先去采用新型的注册机制，借此来获取更佳的性能以及更为现代化的特性支持。这样一种既保持着兼容态势又推动着向前进步的做事方法，展现出了Spring团队一直以来所具有的务实风格。

开发者适配建议

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

对那些正运用SpringBoot的开发者来讲，此次变更虽说要耗费一定的学习成本，然而所带来的长期收益却是值得的，建议自新项目起始便径直采用imports机制，一步步去熟悉全新的编程模式。

现有项目，可采取渐进式迁移策略，先于新增加之模块采用新机制，待熟悉之后再逐步改造原有模块。Spring官方给出详细迁移指南与工具支持，极大降低迁移难度。

com.example.MyAutoConfiguration

各位从事开发工作的朋友，你们当处在实际开展的项目里头，而去运用SpringBoot 3.0所具备的新特性之际，碰到了哪些饶有趣味的问题呀，又或者有着什么样特别的实践方面的心得体会呢？欢迎于评论区域分享你们切实有用的见解跟看法～。

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