Spring Boot 自动配置（组件扫描、自动配置、SPI机制与条件注解）

Spring Boot自动配置关键机制剖析
最新推荐文章于 2025-08-15 22:30:10 发布
原创 最新推荐文章于 2025-08-15 22:30:10 发布 · 946 阅读 · 12 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#spring boot #后端

Spring Boot 自动配置

Spring Boot的核心理念"约定优于配置"（Convention over Configuration）通过其自动配置机制得到充分展现。该机制能智能识别项目依赖、环境变量和配置文件等信息，自动完成Bean注册、依赖注入和组件初始化，显著简化了开发流程。

本文将深入剖析Spring Boot自动配置的关键方面：组件扫描机制、自动配置实现原理、SPI机制与spring.factories文件以及条件注解的应用。

一、组件扫描（Component Scanning）：Bean发现的基础机制

组件扫描是Spring框架从2.5版本开始引入的核心功能，它允许Spring自动发现并注册标注了特定注解的类作为Spring容器中的Bean。这一机制替代了传统Spring中通过XML文件显式声明Bean的方式，极大地简化了配置。

1.1 核心注解：@Component及其衍生注解

Spring的组件扫描机制主要基于@Component注解，以及其三个常用的衍生注解：@Controller、@Service和@Repository。这些注解的核心作用是标识一个类需要被Spring容器扫描并注册为Bean。

  • @Component：通用注解，可用于任何类，表明该类是一个Spring组件。
  • @Controller：专门用于标注控制器类（MVC层），除了标识组件外，还会被Spring MVC框架特殊处理。
  • @Service：用于标注业务逻辑类（服务层），语义上表示该类包含业务处理逻辑。
  • @Repository：用于标注数据访问类（持久层），Spring会为其自动处理数据库操作的异常转换。

这些注解在功能上没有本质区别，主要差异在于语义化表达，帮助开发者更好地理解类的职责。以下是一个简单示例：

// 控制器组件
@Controller
public class UserController {
    // 控制器逻辑
}

// 服务组件
@Service
public class UserService {
    // 业务逻辑
}

// 数据访问组件
@Repository
public class UserRepository {
    // 数据库操作
}

// 通用组件
@Component
public class UserValidator {
    // 数据验证逻辑
}

1.2 启动组件扫描：@ComponentScan注解

仅有标注了组件注解的类并不足以被Spring容器发现，还需要通过@ComponentScan注解启动组件扫描机制。@ComponentScan可以指定需要扫描的包路径，Spring会递归扫描该路径下所有标注了组件注解的类，并将其注册为Bean。

在Spring Boot应用中，@SpringBootApplication注解是启动类的标志性注解，而它实际上已经包含了@ComponentScan注解的功能。@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 {
    // 注解属性...
}

可以看到，@SpringBootApplication组合了@ComponentScan，因此Spring Boot应用的启动类本身就具备了组件扫描的能力。默认情况下，组件扫描会从启动类所在的包开始，递归扫描所有子包。

例如，若启动类位于com.example.demo包下：

package com.example.demo;

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

则Spring会自动扫描com.example.demo包及其所有子包（如com.example.demo.controller、com.example.demo.service等）下的组件类。

1.3 @ComponentScan的高级配置

@ComponentScan提供了丰富的属性配置，允许开发者精确控制组件扫描的范围和行为：

  • basePackages：指定需要扫描的包路径数组，如@ComponentScan(basePackages = {"com.example.service", "com.example.controller"})
  • basePackageClasses：指定作为扫描基准的类，Spring会扫描这些类所在的包及其子包，如@ComponentScan(basePackageClasses = {UserService.class, UserController.class})
  • includeFilters：指定需要包含的过滤规则，即使类没有标注组件注解，只要符合过滤规则也会被扫描
  • excludeFilters：指定需要排除的过滤规则，即使类标注了组件注解，符合规则也会被排除
  • useDefaultFilters：是否启用默认过滤器（默认值为true），默认过滤器会扫描所有标注了@Component及其衍生注解的类
1.3.1 自定义包含/排除规则

通过includeFilters和excludeFilters，可以实现更灵活的组件扫描策略。过滤规则支持多种类型（FilterType）：

  • ANNOTATION：根据注解过滤，如排除所有标注了@Controller的类
  • ASSIGNABLE_TYPE：根据类类型过滤
  • ASPECTJ：根据AspectJ表达式过滤
  • REGEX：根据正则表达式过滤
  • CUSTOM：自定义过滤器，需实现TypeFilter接口

示例：排除所有@Service注解的类，并包含指定包下的所有类：

@ComponentScan(
    basePackages = "com.example",
    excludeFilters = @ComponentScan.Filter(type = FilterType.ANNOTATION, classes = Service.class),
    includeFilters = @ComponentScan.Filter(type = FilterType.REGEX, pattern = "com\\.example\\.util\\..*")
)
public class AppConfig {
    // 配置类内容
}
1.3.2 自定义TypeFilter实现

当内置的过滤类型无法满足需求时，可以通过实现TypeFilter接口创建自定义过滤器。例如，创建一个只包含名称以"Service"结尾的类的过滤器：

public class ServiceNameFilter implements TypeFilter {
    @Override
    public boolean match(MetadataReader metadataReader, MetadataReaderFactory metadataReaderFactory) 
            throws IOException {
        // 获取类名
        String className = metadataReader.getClassMetadata().getClassName();
        // 匹配以"Service"结尾的类
        return className.endsWith("Service");
    }
}

// 在@ComponentScan中使用自定义过滤器
@ComponentScan(
    basePackages = "com.example",
    includeFilters = @ComponentScan.Filter(type = FilterType.CUSTOM, classes = ServiceNameFilter.class)
)
public class AppConfig {
    // 配置类内容
}

1.4 组件扫描的原理与流程

Spring的组件扫描过程主要由ComponentScanAnnotationParser解析@ComponentScan注解，并由ClassPathBeanDefinitionScanner执行实际的扫描工作。其核心流程如下：

  1. 确定扫描包路径：根据@ComponentScan的basePackages或basePackageClasses属性确定扫描范围，默认使用配置类所在的包。
  2. 获取候选组件：ClassPathScanningCandidateComponentProvider在指定包路径下递归扫描所有类文件，通过ResourcePatternResolver加载类资源。
  3. 过滤候选组件：应用includeFilters和excludeFilters过滤规则，筛选出符合条件的类。
  4. 注册Bean定义：将筛选出的类转换为BeanDefinition对象，并注册到Spring容器的BeanDefinitionRegistry中。

源码片段展示了ClassPathBeanDefinitionScanner的扫描过程：

public int scan(String... basePackages) {
    int beanCountAtScanStart = this.registry.getBeanDefinitionCount();
    
    // 实际执行扫描的方法
    doScan(basePackages);
    
    // 注册注解配置处理器（如@Autowired、@Required等）
    if (this.includeAnnotationConfig) {
        AnnotationConfigUtils.registerAnnotationConfigProcessors(this.registry);
    }
    
    return (this.registry.getBeanDefinitionCount() - beanCountAtScanStart);
}

protected Set<BeanDefinitionHolder> doScan(String... basePackages) {
    Assert.notEmpty(basePackages, "At least one base package must be specified");
    Set<BeanDefinitionHolder> beanDefinitions = new LinkedHashSet<>();
    
    for (String basePackage : basePackages) {
        // 找到候选的Bean定义
        Set<BeanDefinition> candidates = findCandidateComponents(basePackage);
        
        for (BeanDefinition candidate : candidates) {
            // 处理Scope注解
            ScopeMetadata scopeMetadata = this.scopeMetadataResolver.resolveScopeMetadata(candidate);
            candidate.setScope(scopeMetadata.getScopeName());
            
            // 生成Bean名称
            String beanName = this.beanNameGenerator.generateBeanName(candidate, this.registry);
            
            // 处理通用注解（如@Lazy、@Primary等）
            if (candidate instanceof AbstractBeanDefinition) {
                postProcessBeanDefinition((AbstractBeanDefinition) candidate, beanName);
            }
            
            // 处理@Component注解的属性
            if (candidate instanceof AnnotatedBeanDefinition) {
                AnnotationConfigUtils.processCommonDefinitionAnnotations((AnnotatedBeanDefinition) candidate);
            }
            
            // 检查Bean是否已存在，处理冲突
            if (checkCandidate(beanName, candidate)) {
                BeanDefinitionHolder definitionHolder = new BeanDefinitionHolder(candidate, beanName);
                definitionHolder = AnnotationConfigUtils.applyScopedProxyMode(
                    scopeMetadata, definitionHolder, this.registry);
                beanDefinitions.add(definitionHolder);
                // 注册Bean定义
                registerBeanDefinition(definitionHolder, this.registry);
            }
        }
    }
    return beanDefinitions;
}

1.5 组件扫描的常见问题与解决方案

1.5.1 组件未被扫描到的原因

开发中经常遇到组件类标注了@Component等注解，但Spring容器中却找不到对应的Bean的问题，常见原因包括：

  1. 包路径不在扫描范围内：组件类所在的包未被@ComponentScan指定的扫描路径包含。

    解决方案：调整@ComponentScan的basePackages属性，确保包含组件所在的包，或移动组件类到正确的包路径下。

  2. 过滤规则导致组件被排除：自定义的excludeFilters可能意外排除了需要的组件。

    解决方案：检查过滤规则，使用@ComponentScan(excludeFilters = {})暂时禁用排除规则进行测试。

  3. 组件类未标注正确的注解：例如，将@Service误写为@Services（拼写错误），或使用了未被默认过滤器识别的自定义注解。

    解决方案：检查注解拼写，对于自定义注解，需要通过@Component元注解标注，或在includeFilters中指定。

  4. 多个配置类的扫描范围冲突：多个@ComponentScan注解可能导致扫描范围重叠或冲突。

    解决方案：统一管理扫描配置，尽量在一个配置类中集中定义@ComponentScan。

1.5.2 扫描范围过大导致的性能问题

当项目规模较大时，@ComponentScan的扫描范围过大会导致Spring启动时间变长，因为需要扫描和处理大量的类文件。

解决方案：

  1. 精确指定扫描路径：只扫描包含组件类的必要包，避免使用过于宽泛的包路径（如com.example）。

    @ComponentScan(basePackages = {
    "com.example.demo.controller",
    "com.example.demo.service",
    "com.example.demo.repository"
})

  2. 排除不需要的路径：使用excludeFilters排除明确不需要扫描的包或类。

    @ComponentScan(
    basePackages = "com.example",
    excludeFilters = @Filter(type = FilterType.REGEX, pattern = "com\\.example\\.legacy\\..*")
)

  3. 使用懒加载：对于非关键组件，可通过@Lazy注解实现懒加载，延迟到首次使用时才初始化。

二、自动配置（Auto-configuration）

Spring Boot能够根据项目的依赖、配置和环境自动配置Spring应用，极大地简化了开发流程。自动配置基于"约定优于配置"的原则，在合理默认值的基础上，允许通过配置文件或自定义Bean灵活调整配置。

2.1 自动配置的触发：@EnableAutoConfiguration注解

自动配置的核心触发点是@EnableAutoConfiguration注解，该注解通常通过@SpringBootApplication间接引入（如前文所示）。@EnableAutoConfiguration的作用是启用Spring Boot的自动配置机制，它会根据类路径下的依赖jar包、配置文件等信息，自动配置Spring容器中的Bean。

@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 {};
}

该注解包含两个关键部分：

  1. @AutoConfigurationPackage：指定自动配置的基础包，默认是标注该注解的类所在的包，通常用于注册EntityManagerFactory等需要扫描实体类的组件。
  2. @Import(AutoConfigurationImportSelector.class)：导入AutoConfigurationImportSelector类，该类是自动配置的核心实现，负责加载和筛选自动配置类。

2.2 自动配置的核心流程

自动配置的核心流程由AutoConfigurationImportSelector类主导，其主要职责是识别并导入符合条件的自动配置类。整个流程可以概括为以下步骤：

  1. 加载候选自动配置类：从META-INF/spring.factories文件中读取EnableAutoConfiguration对应的配置类列表（详细机制见SPI部分）。
  2. 筛选自动配置类：根据类路径下的依赖、@Conditional条件注解、排除规则等筛选出有效的自动配置类。
  3. 排序自动配置类：根据@AutoConfigureBefore、@AutoConfigureAfter、@AutoConfigureOrder等注解确定自动配置类的加载顺序。
  4. 导入自动配置类：将筛选和排序后的自动配置类导入到Spring容器中，这些类会定义相应的Bean。

AutoConfigurationImportSelector的核心方法selectImports实现了这一流程：

@Override
public String[] selectImports(AnnotationMetadata annotationMetadata) {
    if (!isEnabled(annotationMetadata)) {
        return NO_IMPORTS;
    }
    // 加载自动配置元数据
    AutoConfigurationMetadata autoConfigurationMetadata = AutoConfigurationMetadataLoader
        .loadMetadata(this.beanClassLoader);
    // 获取自动配置入口（注解属性）
    AutoConfigurationEntry autoConfigurationEntry = getAutoConfigurationEntry(
        autoConfigurationMetadata, annotationMetadata);
    return StringUtils.toStringArray(autoConfigurationEntry.getConfigurations());
}

protected AutoConfigurationEntry getAutoConfigurationEntry(
    AutoConfigurationMetadata autoConfigurationMetadata, AnnotationMetadata annotationMetadata) {
    
    if (!isEnabled(annotationMetadata)) {
        return EMPTY_ENTRY;
    }
    // 获取@EnableAutoConfiguration注解的属性（如exclude等）
    AnnotationAttributes attributes = getAttributes(annotationMetadata);
    // 从spring.factories加载候选自动配置类
    List<String> configurations = getCandidateConfigurations(annotationMetadata, attributes);
    // 去重
    configurations = removeDuplicates(configurations);
    // 获取需要排除的类
    Set<String> exclusions = getExclusions(annotationMetadata, attributes);
    // 检查排除类的有效性
    checkExcludedClasses(configurations, exclusions);
    // 移除需要排除的类
    configurations.removeAll(exclusions);
    // 根据类路径下的依赖筛选配置类
    configurations = filter(configurations, autoConfigurationMetadata);
    // 触发自动配置导入事件
    fireAutoConfigurationImportEvents(configurations, exclusions);
    return new AutoConfigurationEntry(configurations, exclusions);
}

2.3 自动配置类的结构与示例

自动配置类是实现自动配置的具体载体，它们通常是标注

了@Configuration注解的配置类，并结合条件注解（如@ConditionalOnClass、@ConditionalOnMissingBean等）来决定是否创建特定的Bean，以及如何配置这些Bean。

一个典型的自动配置类结构如下：

@Configuration
@ConditionalOnClass({DataSource.class, EmbeddedDatabaseType.class})
@EnableConfigurationProperties(DataSourceProperties.class)
@Import({DataSourcePoolMetadataProvidersConfiguration.class, DataSourceInitializationConfiguration.class})
public class DataSourceAutoConfiguration {

    @Configuration
    @Conditional(EmbeddedDatabaseCondition.class)
    @ConditionalOnMissingBean({DataSource.class, XADataSource.class})
    @Import(EmbeddedDataSourceConfiguration.class)
    protected static class EmbeddedDatabaseConfiguration {
    }

    @Configuration
    @Conditional(PooledDataSourceCondition.class)
    @ConditionalOnMissingBean({DataSource.class, XADataSource.class})
    @Import({Hikari.class, Tomcat.class, Dbcp2.class, Generic.class, DataSourceJmxConfiguration.class})
    protected static class PooledDataSourceConfiguration {
    }

    // 其他内部配置类和Bean定义...
}

上述示例是Spring Boot内置的DataSourceAutoConfiguration类的简化版，它展示了自动配置类的几个关键特征：

  1. @Configuration注解：标识该类是一个配置类，其中可以定义Bean。
  2. 条件注解：如@ConditionalOnClass确保只有当类路径下存在DataSource和EmbeddedDatabaseType类时，该自动配置类才会生效；@ConditionalOnMissingBean确保只有当容器中不存在DataSource类型的Bean时，才会创建相应的Bean。
  3. @EnableConfigurationProperties：启用对DataSourceProperties类的支持，该类用于绑定配置文件中的数据源配置（如spring.datasource.url、spring.datasource.username等）。
  4. 内部配置类：通过静态内部类进一步细分配置场景（如嵌入式数据库、连接池等），每个内部类都可以有自己的条件注解和Bean定义。
  5. @Import注解：导入其他相关的配置类，实现配置的模块化组合。

2.4 自动配置的工作原理：Bean的条件注册

自动配置的核心是根据条件动态注册Bean。当Spring容器启动时，自动配置类会被解析，其内部定义的Bean会根据条件注解的判断结果决定是否注册到容器中。

以DataSourceAutoConfiguration为例，其工作流程如下：

  1. 条件判断：@ConditionalOnClass({DataSource.class, EmbeddedDatabaseType.class})检查类路径下是否存在这两个类。如果项目中引入了数据库相关依赖（如spring-boot-starter-jdbc），则这两个类会存在，条件满足。
  2. 属性绑定：@EnableConfigurationProperties(DataSourceProperties.class)将配置文件中的属性（如spring.datasource.*）绑定到DataSourceProperties对象中。
  3. 场景细分：根据不同的条件（如是否存在嵌入式数据库、是否配置了连接池等），选择对应的内部配置类（如EmbeddedDatabaseConfiguration或PooledDataSourceConfiguration）。
  4. Bean注册：在选中的内部配置类中，定义具体的DataSourceBean。例如，PooledDataSourceConfiguration会根据类路径下的连接池依赖（如HikariCP、Tomcat JDBC等）选择相应的连接池实现，并根据DataSourceProperties中的配置创建DataSourceBean。

自动配置过程中，Bean的注册是条件性的，这意味着：

  • 如果用户没有自定义相关的Bean，自动配置会根据默认条件创建一个合理的Bean。
  • 如果用户自定义了相关的Bean（如通过@Bean注解定义了自己的DataSource），则@ConditionalOnMissingBean条件会生效，自动配置的Bean注册会被跳过，从而实现用户自定义配置对自动配置的覆盖。

这种"用户优先"的策略确保了自动配置的灵活性：既提供了开箱即用的默认配置，又允许开发者根据需求进行定制。

2.5 自动配置的定制与覆盖

Spring Boot提供了多种方式让开发者定制或覆盖自动配置：

2.5.1 通过配置文件定制

大多数自动配置类都通过@EnableConfigurationProperties绑定了相应的属性类，开发者可以在application.properties或application.yml中配置相关属性，从而定制自动配置的行为。

例如，对于数据源配置，可以在application.properties中设置：

spring.datasource.url=jdbc:mysql://localhost:3306/mydb
spring.datasource.username=root
spring.datasource.password=123456
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver
spring.datasource.hikari.maximum-pool-size=10

这些配置会被绑定到DataSourceProperties对象中，并用于配置DataSourceBean。

2.5.2 通过自定义Bean覆盖

如果需要更深度的定制，可以通过自定义Bean覆盖自动配置的默认Bean。由于自动配置类中通常使用@ConditionalOnMissingBean注解，当容器中存在用户定义的同类型Bean时，自动配置的Bean会被忽略。

例如，自定义一个DataSourceBean：

@Configuration
public class MyDataSourceConfig {

    @Bean
    public DataSource dataSource() {
        HikariConfig config = new HikariConfig();
        config.setJdbcUrl("jdbc:mysql://localhost:3306/mydb");
        config.setUsername("root");
        config.setPassword("123456");
        config.setMaximumPoolSize(20);
        // 其他自定义配置
        return new HikariDataSource(config);
    }
}

当Spring容器中存在这个DataSourceBean时，DataSourceAutoConfiguration中的@ConditionalOnMissingBean条件会不满足，从而不会注册默认的DataSourceBean。

2.5.3 排除特定的自动配置类

如果某些自动配置类不需要生效，可以通过@EnableAutoConfiguration的exclude属性或配置文件排除它们。

使用注解排除：

@SpringBootApplication(exclude = DataSourceAutoConfiguration.class)
public class DemoApplication {
    // ...
}

使用配置文件排除：

spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration

这种方式适用于完全不需要某个自动配置功能的场景。

三、SPI机制与spring.factories文件：自动配置的发现机制

SPI（Service Provider Interface）是一种服务发现机制，它允许第三方为特定的接口提供实现，而无需在代码中显式引用。Spring Boot使用SPI机制来发现和加载自动配置类，其核心是META-INF/spring.factories文件。

3.1 SPI机制的基本原理

SPI机制的工作流程通常包括以下步骤：

  1. 定义服务接口：服务的使用方定义一个接口，作为服务的抽象。
  2. 提供服务实现：服务的实现方提供接口的具体实现类。
  3. 注册服务实现：在META-INF/services目录下创建一个以服务接口全类名命名的文件，文件内容为服务实现类的全类名。
  4. 发现并使用服务：服务的使用方通过SPI机制扫描META-INF/services目录下的配置文件，加载并实例化服务实现类。

Java标准库中的java.util.ServiceLoader类是SPI机制的实现，它可以根据服务接口加载所有注册的实现类。

3.2 Spring Boot对SPI的扩展：spring.factories文件

Spring Boot并没有直接使用Java标准的SPI机制，而是对其进行了扩展，使用META-INF/spring.factories文件来注册各种服务，包括自动配置类、监听器、初始化器等。

spring.factories文件采用键值对的格式，其中键是接口或注解的全类名，值是该接口的实现类或注解的候选类的全类名，多个类之间用逗号分隔。

例如，Spring Boot的spring-boot-autoconfigure模块中的META-INF/spring.factories文件包含了大量自动配置类的注册：

# Auto Configure
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
org.springframework.boot.autoconfigure.admin.SpringApplicationAdminJmxAutoConfiguration,\
org.springframework.boot.autoconfigure.aop.AopAutoConfiguration,\
org.springframework.boot.autoconfigure.amqp.RabbitAutoConfiguration,\
org.springframework.boot.autoconfigure.batch.BatchAutoConfiguration,\
org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration,\
org.springframework.boot.autoconfigure.cassandra.CassandraAutoConfiguration,\
org.springframework.boot.autoconfigure.context.ConfigurationPropertiesAutoConfiguration,\
org.springframework.boot.autoconfigure.context.LifecycleAutoConfiguration,\
org.springframework.boot.autoconfigure.context.MessageSourceAutoConfiguration,\
org.springframework.boot.autoconfigure.context.PropertyPlaceholderAutoConfiguration,\
# 更多自动配置类...

在这个例子中，键是org.springframework.boot.autoconfigure.EnableAutoConfiguration，值是一系列自动配置类的全类名。当@EnableAutoConfiguration注解生效时，这些自动配置类会被作为候选类加载。

3.3 spring.factories的加载与解析

Spring Boot通过SpringFactoriesLoader类加载和解析spring.factories文件。SpringFactoriesLoader会扫描类路径下所有JAR包中的META-INF/spring.factories文件，将其内容合并到一个Map中，键为接口或注解全类名，值为对应的实现类列表。

SpringFactoriesLoader的核心方法loadFactories和loadFactoryNames：

public abstract class SpringFactoriesLoader {
    public static final String FACTORIES_RESOURCE_LOCATION = "META-INF/spring.factories";
    
    // 加载指定类型的所有实现类实例
    public static <T> List<T> loadFactories(Class<T> factoryType, @Nullable ClassLoader classLoader) {
        Assert.notNull(factoryType, "'factoryType' must not be null");
        ClassLoader classLoaderToUse = classLoader;
        if (classLoaderToUse == null) {
            classLoaderToUse = SpringFactoriesLoader.class.getClassLoader();
        }
        // 获取所有实现类的全类名
        List<String> factoryImplementationNames = loadFactoryNames(factoryType, classLoaderToUse);
        if (logger.isTraceEnabled()) {
            logger.trace("Loaded [" + factoryType.getName() + "] names: " + factoryImplementationNames);
        }
        List<T> result = new ArrayList<>(factoryImplementationNames.size());
        // 实例化每个实现类
        for (String factoryImplementationName : factoryImplementationNames) {
            result.add(instantiateFactory(factoryImplementationName, factoryType, classLoaderToUse));
        }
        // 排序
        AnnotationAwareOrderComparator.sort(result);
        return result;
    }
    
    // 获取指定类型的所有实现类的全类名
    public static List<String> loadFactoryNames(Class<?> factoryType, @Nullable ClassLoader classLoader) {
        String factoryTypeName = factoryType.getName();
        // 加载并获取对应的值
        return loadSpringFactories(classLoader).getOrDefault(factoryTypeName, Collections.emptyList());
    }
    
    // 加载所有spring.factories文件并合并内容
    private static Map<String, List<String>> loadSpringFactories(@Nullable ClassLoader classLoader) {
        MultiValueMap<String, String> result = cache.get(classLoader);
        if (result != null) {
            return result;
        }
        
        try {
            // 查找所有META-INF/spring.factories资源
            Enumeration<URL> urls = (classLoader != null ?
                classLoader.getResources(FACTORIES_RESOURCE_LOCATION) :
                ClassLoader.getSystemResources(FACTORIES_RESOURCE_LOCATION));
            result = new LinkedMultiValueMap<>();
            // 解析每个资源并合并到result中
            while (urls.hasMoreElements()) {
                URL url = urls.nextElement();
                UrlResource resource = new UrlResource(url);
                Properties properties = PropertiesLoaderUtils.loadProperties(resource);
                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);
        }
    }
}

在自动配置流程中，AutoConfigurationImportSelector会调用SpringFactoriesLoader.loadFactoryNames(EnableAutoConfiguration.class, classLoader)方法，获取spring.factories文件中注册的所有自动配置类的全类名，作为候选自动配置类。

3.4 自定义spring.factories实现自动配置

在开发自定义Starter时，通常需要通过spring.factories文件注册自己的自动配置类，以便Spring Boot能够发现并加载它。

步骤如下：

  1. 创建自动配置类：编写一个标注了@Configuration和相关条件注解的自动配置类。
@Configuration
@ConditionalOnClass(MyService.class)
@EnableConfigurationProperties(MyServiceProperties.class)
public class MyServiceAutoConfiguration {

    private final MyServiceProperties properties;

    public MyServiceAutoConfiguration(MyServiceProperties properties) {
        this.properties = properties;
    }

    @Bean
    @ConditionalOnMissingBean
    public MyService myService() {
        return new MyService(properties.getPrefix(), properties.getSuffix());
    }
}
  1. 创建属性类：用于绑定配置文件中的属性。
@ConfigurationProperties(prefix = "my.service")
public class MyServiceProperties {
    private String prefix = "defaultPrefix";
    private String suffix = "defaultSuffix";

    // getter和setter方法
}
  1. 注册自动配置类：在项目的src/main/resources/META-INF/目录下创建spring.factories文件，并注册自动配置类。
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
com.example.mystarter.MyServiceAutoConfiguration
  1. 打包与使用：将项目打包为Jar包，其他项目引入该Jar包后，Spring Boot会自动发现并加载MyServiceAutoConfiguration，根据条件创建MyServiceBean。

通过这种方式，自定义Starter可以像Spring Boot官方Starter一样，实现"开箱即用"的自动配置。

四、条件注解（Conditional Annotations）：自动配置的开关

条件注解是Spring Boot自动配置的核心控制机制，它允许根据特定的条件来决定是否注册Bean或启用配置类。Spring Boot提供了一系列内置的条件注解，覆盖了类路径检查、Bean存在性检查、配置属性检查等常见场景。

4.1 条件注解的基础：@Conditional注解

所有条件注解的基础是@Conditional注解，它接收一个Class<? extends Condition>数组作为参数，这些类实现了具体的条件判断逻辑。

Condition接口的定义如下：

@FunctionalInterface
public interface Condition {
    // 判断条件是否满足
    boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata);
}

matches方法返回true表示条件满足，false表示条件不满足。ConditionContext提供了访问Spring容器的上下文信息（如Bean定义、环境变量、资源加载器等），AnnotatedTypeMetadata提供了被注解元素的元数据（如注解属性等）。

例如，自定义一个判断系统类型的条件：

public class OnWindowsCondition implements Condition {
    @Override
    public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
        // 获取操作系统名称
        String osName = context.getEnvironment().getProperty("os.name");
        // 判断是否为Windows系统
        return osName != null && osName.toLowerCase().contains("windows");
    }
}

public class OnLinuxCondition implements Condition {
    @Override
    public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
        String osName = context.getEnvironment().getProperty("os.name");
        return osName != null && osName.toLowerCase().contains("linux");
    }
}

使用自定义条件注解：

@Configuration
public class OsSpecificConfig {

    @Bean
    @Conditional(OnWindowsCondition.class)
    public FileSystem windowsFileSystem() {
        return new WindowsFileSystem();
    }

    @Bean
    @Conditional(OnLinuxCondition.class)
    public FileSystem linuxFileSystem() {
        return new LinuxFileSystem();
    }
}

在上述示例中，windowsFileSystemBean只会在Windows系统中注册，linuxFileSystemBean只会在Linux系统中注册。

4.2 Spring Boot内置的条件注解

Spring Boot在org.springframework.boot.autoconfigure.condition包下提供了一系列常用的条件注解，这些注解基于@Conditional实现，并封装了特定的条件判断逻辑。

4.2.1 类路径相关条件
  • @ConditionalOnClass：当类路径下存在指定的类时，条件满足。

@Configuration
@ConditionalOnClass({MyService.class, MyDependency.class})
public class MyServiceAutoConfiguration {
// 配置内容…
}

该注解会检查类路径下是否同时存在`MyService`和`MyDependency`两个类，只有都存在时，`MyServiceAutoConfiguration`才会生效。

- **@ConditionalOnMissingClass**：当类路径下不存在指定的类时，条件满足。
```java
@Configuration
@ConditionalOnMissingClass("com.example.UnwantedClass")
public class MyServiceAutoConfiguration {
    // 配置内容...
}

当类路径下没有com.example.UnwantedClass时，该配置类生效。

这两个注解在判断类是否存在时，使用的是类加载器尝试加载类的方式，不会实际初始化类，因此即使类存在但依赖缺失，也不会导致类初始化异常。

4.2.2 Bean存在性相关条件

  • @ConditionalOnBean：当Spring容器中存在指定类型或名称的Bean时，条件满足。

    @Bean
@ConditionalOnBean(DataSource.class)
public DataSourceInitializer dataSourceInitializer() {
    return new DataSourceInitializer();
}

    只有当容器中存在DataSource类型的Bean时，才会创建dataSourceInitializerBean。

    该注解支持通过type、value、name等属性指定Bean的类型或名称，还可以通过annotation属性指定Bean是否标注了特定注解。

  • @ConditionalOnMissingBean：当Spring容器中不存在指定类型或名称的Bean时，条件满足。这是自动配置中最常用的注解之一，用于实现"用户自定义Bean优先"的策略。

    @Bean
@ConditionalOnMissingBean
public MyService myService() {
    return new DefaultMyService();
}

    当容器中不存在MyService类型的Bean时，会创建DefaultMyService实例；如果用户已经定义了MyService类型的Bean，则该方法不会执行。

    同样，该注解也支持通过多种属性指定Bean的特征，还可以通过parameterizedContainer属性指定参数化容器类型（如List<MyService>）。

4.2.3 配置属性相关条件

  • @ConditionalOnProperty：根据配置文件中指定属性的值判断条件是否满足。

    @Bean
@ConditionalOnProperty(name = "feature.enabled", havingValue = "true", matchIfMissing = true)
public FeatureService featureService() {
    return new FeatureService();
}

    该示例中，name指定了属性名称为feature.enabled，havingValue指定属性值为true时条件满足，matchIfMissing指定如果属性不存在时默认条件满足。因此，当feature.enabled=true或属性未配置时，会创建featureServiceBean。

    该注解还支持prefix属性指定属性前缀，value属性指定多个属性（逻辑与关系），matchIfMissing默认为false。

4.2.4 环境相关条件

  • @ConditionalOnEnvironment：根据当前Spring环境（Environment）中的激活配置文件（profile）判断条件是否满足。

    @Configuration
@ConditionalOnEnvironment(profiles = "dev")
public class DevConfig {
    // 开发环境配置...
}

    只有当dev profile被激活时，DevConfig配置类才会生效。

    该注解的profiles属性可以指定多个profile，还可以通过value属性的NOT、AND、OR等组合逻辑进行更复杂的判断。

  • @ConditionalOnCloudPlatform：当应用运行在指定的云平台（如CloudFoundry、Heroku等）时，条件满足。

    @Bean
@ConditionalOnCloudPlatform(CloudPlatform.CLOUD_FOUNDRY)
public CloudFoundryService cloudFoundryService() {
    return new CloudFoundryService();
}

    当应用部署在CloudFoundry云平台时，会创建cloudFoundryServiceBean。

4.2.5 资源相关条件
  • @ConditionalOnResource：当指定的资源存在时，条件满足。
    @Bean
@ConditionalOnResource(resources = "classpath:data/init.sql")
public SqlInitializer sqlInitializer() {
    return new SqlInitializer();
}
    当类路径下存在data/init.sql资源文件时，会创建sqlInitializerBean。
4.2.6 Web环境相关条件

  • @ConditionalOnWebApplication：当应用是Web应用时，条件满足。Web应用包括Servlet Web应用和Reactive Web应用，可以通过type属性指定。

    @Configuration
@ConditionalOnWebApplication(type = ConditionalOnWebApplication.Type.SERVLET)
public class ServletWebConfig {
    // Servlet Web应用配置...
}

    只有当应用是Servlet Web应用时，该配置类才会生效。

  • @ConditionalOnNotWebApplication：当应用不是Web应用时，条件满足。

4.2.7 其他常用条件

  • @ConditionalOnExpression：根据SpEL表达式的计算结果判断条件是否满足，支持更复杂的逻辑判断。

    @Bean
@ConditionalOnExpression("${feature.enabled:true} and ${feature.version:1} >= 2")
public AdvancedFeatureService advancedFeatureService() {
    return new AdvancedFeatureService();
}

    当feature.enabled=true且feature.version>=2时，条件满足。

  • @ConditionalOnJava：根据当前JVM的Java版本判断条件是否满足。

    @Bean
@ConditionalOnJava(range = ConditionalOnJava.Range.EQUAL_OR_NEWER, value = JavaVersion.EIGHTEEN)
public Java18FeatureService java18FeatureService() {
    return new Java18FeatureService();
}

    当JVM版本为Java 18或更高时，会创建java18FeatureServiceBean。

4.3 条件注解的组合使用

在实际开发中，条件注解可以组合使用，实现更精确的条件判断。多个条件注解之间是逻辑与（AND）的关系，只有所有条件都满足时，才会执行Bean注册或配置类生效。

例如，在自动配置类中组合使用多种条件注解：

@Configuration
@ConditionalOnClass(MyService.class)
@ConditionalOnWebApplication
@ConditionalOnProperty(prefix = "my.service", name = "enabled", havingValue = "true")
public class MyServiceAutoConfiguration {

    @Bean
    @ConditionalOnMissingBean
    @ConditionalOnExpression("${my.service.cache.enabled:false}")
    public MyService cachedMyService() {
        return new CachedMyService();
    }

    @Bean
    @ConditionalOnMissingBean
    @ConditionalOnExpression("!${my.service.cache.enabled:false}")
    public MyService defaultMyService() {
        return new DefaultMyService();
    }
}

上述示例中：

  • 配置类MyServiceAutoConfiguration生效的条件是：类路径存在MyService、应用是Web应用、my.service.enabled=true。
  • cachedMyServiceBean生效的条件是：容器中没有MyServiceBean、my.service.cache.enabled=true。
  • defaultMyServiceBean生效的条件是：容器中没有MyServiceBean、my.service.cache.enabled=false（或属性不存在）。

通过组合使用条件注解，可以根据不同的环境和配置，灵活地注册不同的Bean。

4.4 条件注解的执行顺序

当多个条件注解应用于同一个配置类或Bean方法时，它们的执行顺序可能会影响最终结果。Spring Boot对条件注解的执行顺序有一定的默认规则：

  1. 类级别的条件注解先于方法级别的条件注解执行：配置类上的条件注解会先判断，如果不满足，配置类中的所有Bean方法都不会执行。
  2. 特定类型的条件注解优先执行：例如，@ConditionalOnClass和@ConditionalOnMissingClass会在@ConditionalOnBean和@ConditionalOnMissingBean之前执行，因为Bean的存在依赖于类的存在。
  3. 相同类型的条件注解按定义顺序执行：但由于条件之间是逻辑与的关系，顺序通常不影响结果。

如果需要自定义条件的执行顺序，可以让Condition实现类实现Ordered接口或标注@Order注解，数值越小优先级越高。

@Order(Ordered.HIGHEST_PRECEDENCE)
public class EarlyCondition implements Condition {
    // 条件判断逻辑...
}

public class LateCondition implements Condition, Ordered {
    @Override
    public int getOrder() {
        return Ordered.LOWEST_PRECEDENCE;
    }

    // 条件判断逻辑...
}

在上述示例中，EarlyCondition会比LateCondition先执行。

4.5 自定义条件注解

除了使用Spring Boot内置的条件注解，还可以通过@Conditional注解结合自定义Condition实现类，创建自己的条件注解，以满足特定的业务需求。

创建自定义条件注解的步骤如下：

  1. 实现Condition接口：编写条件判断逻辑。

    public class OnProductionEnvironmentCondition implements Condition {
    @Override
    public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
        // 获取激活的profiles
        String[] activeProfiles = context.getEnvironment().getActiveProfiles();
        // 判断是否包含"prod" profile
        return Arrays.asList(activeProfiles).contains("prod");
    }
}

  2. 创建注解并标注@Conditional：将自定义的Condition类作为参数传入。

    @Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Conditional(OnProductionEnvironmentCondition.class)
public @interface ConditionalOnProduction {
}

  3. 使用自定义条件注解：

    @Configuration
public class EnvironmentSpecificConfig {

    @Bean
    @ConditionalOnProduction
    public ProductionService productionService() {
        return new ProductionService();
    }
}

    当应用激活了prod profile时，productionServiceBean会被注册。

通过这种方式，可以创建具有业务语义的条件注解，使代码更具可读性和可维护性。

五、自动配置的调试与诊断

尽管Spring Boot的自动配置极大地简化了开发，但当自动配置不符合预期时（如Bean未被创建、配置未生效等），需要有效的调试手段来诊断问题。

5.1 启用自动配置调试日志

Spring Boot提供了详细的自动配置日志，通过设置日志级别为DEBUG可以查看自动配置的决策过程。

在application.properties中配置：

logging.level.org.springframework.boot.autoconfigure=DEBUG

启用后，日志中会包含自动配置类的加载、条件判断结果等信息，例如：

DEBUG 12345 --- [           main] o.s.b.a.AutoConfigurationReportLoggingInitializer : 

============================
CONDITIONS EVALUATION REPORT
============================


Positive matches:
-----------------

   AopAutoConfiguration matched:
      - @ConditionalOnClass found required classes 'org.springframework.aop.Pointcut', 'org.springframework.aop.framework.AopInfrastructureBean' (OnClassCondition)
      - @ConditionalOnProperty (spring.aop.auto=true) matched (OnPropertyCondition)

   DataSourceAutoConfiguration matched:
      - @ConditionalOnClass found required classes 'javax.sql.DataSource', 'org.springframework.jdbc.datasource.embedded.EmbeddedDatabaseType' (OnClassCondition)


Negative matches:
-----------------

   ActiveMQAutoConfiguration:
      Did not match:
         - @ConditionalOnClass did not find required class 'javax.jms.ConnectionFactory' (OnClassCondition)

   AopAutoConfiguration.ClassProxyingConfiguration:
      Did not match:
         - @ConditionalOnMissingClass found unwanted class 'org.aspectj.weaver.Advice' (OnClassCondition)

日志中分为"Positive matches"（条件满足的自动配置类）和"Negative matches"（条件不满足的自动配置类），并详细说明了每个条件的判断结果，有助于定位问题。

5.2 使用spring-boot-starter-actuator查看自动配置报告

spring-boot-starter-actuator提供了conditions端点（原autoconfig端点），可以以JSON或HTML格式查看自动配置的详细报告。

步骤如下：

  1. 添加依赖：

    <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

  2. 启用conditions端点：

    management.endpoints.web.exposure.include=conditions

  3. 访问端点：启动应用后，访问http://localhost:8080/actuator/conditions，可以查看所有自动配置类的条件判断结果，包括匹配的条件和不匹配的条件，以及具体原因。

5.3 常见自动配置问题的诊断思路

  1. Bean未被创建：

    • 检查对应的自动配置类是否在"Positive matches"中，若不在，查看该类的条件为何不满足（如类路径是否缺少依赖、是否存在冲突的Bean等）。
    • 检查是否存在@ConditionalOnMissingBean条件，是否用户自定义了同类型的Bean。
    • 检查配置属性是否正确设置，是否满足@ConditionalOnProperty等条件。

  2. 自动配置类未生效：

    • 检查类路径下是否存在该自动配置类所在的Jar包，依赖是否正确引入。
    • 检查是否通过@SpringBootApplication(exclude=...)或配置文件排除了该自动配置类。
    • 查看日志中该自动配置类的条件判断结果，分析不满足的条件。

  3. 属性绑定失败：

    • 检查属性类是否标注了@ConfigurationProperties注解，是否通过@EnableConfigurationProperties启用。
    • 检查配置文件中的属性名称是否与属性类的字段名匹配（注意前缀和驼峰命名规则）。
    • 启用DEBUG日志，查看属性绑定的详细信息，是否有类型转换错误等。

六、总结

Spring Boot的自动配置机制是其"约定优于配置"理念的集中体现，通过组件扫描、自动配置类、SPI机制和条件注解的有机结合，实现了应用的快速开发和部署。

  • 组件扫描负责发现应用内部的组件类并注册为Bean，是基础的Bean发现机制。
  • 自动配置通过@EnableAutoConfiguration触发，基于spring.factories文件中的自动配置类，根据条件动态注册Bean，实现了基础设施的自动装配。
  • SPI机制与spring.factories文件提供了自动配置类的发现机制，使第三方Starter能够无缝集成到Spring Boot应用中。
  • 条件注解作为自动配置的开关，根据类路径、Bean存在性、配置属性等条件动态控制配置的生效，实现了灵活的配置策略。

理解这些机制不仅有助于更好地使用Spring Boot，还能在开发自定义Starter时，遵循Spring Boot的设计理念，提供良好的自动配置体验。

随着Spring Boot的不断发展，自动配置机制也在持续优化，例如引入了@AutoConfiguration注解（Spring Boot 2.7+）用于更精确地标识自动配置类，以及META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件（Spring Boot 3.0+）替代spring.factories用于注册自动配置类，使自动配置的实现更加规范和高效。

这一次带你搞懂SpringBoot核心原理（自动配置、事件驱动、Condition）
ITjianshuzhai的博客
06-26 3156
目录 前言 正文启动原理事件驱动自动配置原理Condition注解原理 总结 前言 SpringBoot是Spring的包装，通过自动配置使得SpringBoot可以做到开箱即用，上手成本非常低，但是学习其实现原理的成本大大增加，需要先了解熟悉Spring原理。如果还不清楚Spring原理的，可以先查看博主之前的文章，本篇主要分析SpringBoot的启动、自动配置、Condition、事件驱动原理。 正文 启动原理 SpringBoot启动非常简单，因其内置了Tomcat，所以只需要通...
Spring Boot 自动配置原理及过程
yuanchun的知识整理
08-06 3393
Spring Boot 自动配置原理及过程
SpringBoot 扫描配置 Application
qq_25635139的博客
12-16 2077
/*方法一*/ 解决SpringBoot访问不到Controller @SpringBootApplication(scanBasePackages = "com") @EnableAutoConfiguration public class LiuliangApplication { public static void main(String[] args) { Sp...
Spring 条件注解与 SPI 机制（深度解析）
最新发布
dom_jun的博客
08-15 798
本文深入探讨了Spring框架中条件注解与SPI机制的核心原理与应用。条件注解通过@Conditional及其派生注解（如@ConditionalOnClass、@ConditionalOnMissingBean等）实现了灵活的Bean加载控制，而SPI机制则通过spring.factories文件实现组件的自动发现与配置加载。文章详细解析了它们的底层实现、执行顺序及协同作用，并提供了自定义组件的实战案例。同时总结了面试中的高频问题应答框架，帮助开发者深入理解SpringBoot自动配置的核心机制，提升开发
SpringBoot-MVC配置类与 Controller 的扫描
qq_45090949的博客
03-18 1293
本章主要研究 SpringBoot 对于 MVC 的自动配置提示：这里对文章进行总结：例如：以上就是今天要讲的内容，本文仅仅简单介绍了pandas的使用，而pandas提供了大量能使我们快速便捷地处理数据的函数和方法。
SpringBoot注解自动扫描-底层实现
Kevinnsm的博客
12-13 1976
分析上文Spring Boot快速入门 @SpringBootApplication public class HelloWorldApplication { public static void main(String[] args) { //Spring应用启动起来 SpringApplication.run(HelloWorldApplication.class,args); } } @SpringBootConfiguration:Spring
Springboot指定扫描路径
weixin_74261199的博客
02-24 3686
前提：配置类要在启动类所在包或子包下 ( 保证配置类要被扫描到 )
基于Java的mica-auto注解自动生成Java SPI和Spring Boot配置设计源码
05-22
mica-auto是一个使用注解自动生成Java SPI和Spring Boot配置的工具，旨在简化开发过程中的配置工作，提高开发效率。该项目还提供了文档和示例代码，帮助开发者快速上手。记得在右上角点个star关注更新！
Spring Boot ComponentScan-组件扫描
xycxycooo的博客
07-22 1538
在 Spring Boot 中，是一个非常重要的注解，用于配置组件扫描。组件扫描是 Spring 框架中的一个核心功能，它允许 Spring 自动发现应用中的组件并将其注册为 Spring Bean。通过组件扫描，开发者可以避免手动配置每个 Bean，从而简化配置并提高开发效率。如果需要扫描其他包中的类，可以通过注解进行配置。在这个例子中，Spring Boot 会扫描和包及其子包中的所有类。注解是 Spring Boot 中配置组件扫描的重要手段。
mica-auto：云母自动使用注解自动生成java spi和Spring boot的配置。:TOP_arrow:记得右上角点个星星关注更新！
02-05
mica-auto是Spring cloud微服务框架Mica中的一个基础组件，用于生成Spring boot starter的一些基础配置。 原理 mica auto采用注释处理器，她不是什么新技术，在jdk 1.6就存在了。注释处理器是javac的一个工具，它...
深入探索Spring Starter自动装配与Java SPI机制
道长的博客
07-20 1382
Spring Starter 是 Spring Boot 的一部分，它提供了一种快速启动 Spring 应用程序的方式。通过自动装配，Spring Starter 能够根据项目中添加的依赖自动配置应用程序，极大地简化了 Spring 应用的配置过程。
读懂Springboot自动配置原理必会的java SPI思想
05-20 1815
读懂Springboot必会的java SPI思想什么是java的SPISPI 应用场景Java SPI 规范案例代码创建案例工程 什么是java的SPI SPI全称Service Provider Interface，是Java提供的一套用来被第三方实现或者扩展的API，它可以用来启用框架扩展和替换组件。 Java SPI 实际上是“基于接口的编程＋策略模式＋配置文件”组合实现的动态加载机制。 系统设计的各个抽象，往往有很多不同的实现方案，在面向的对象的设计里，一般推荐模块之间基于接口编程，模块之间不对
springboot1入门&springboot设计目的、概念、约定由于配置&springboot启动类扫描路径&构建简单springboot项目
m0_45899013的博客
06-09 854
springboot设计目的： 用来简化新 Spring 应用的初始搭建以及开发过程。 （简单来说，Spring Boot 的设计是为了让你尽可能快的跑起来 Spring 应用程序并且尽可能减少你的配置文件。） springboot是什么？ 参考：https://blog.csdn.net/qq_40147863/article/details/84194493 从最根本上来讲，Spring Boot 就是一些库的集合，它能够被任意项目的构建系统所使用。它使用 “约定优于配置” 的理念让你的项目快速运行起来
基础springboot扫描讲解
m0_54849806的博客
08-28 1490
看到什么，@configuration，说明什么，说明@SpringBootApplication本身就是一个ioc容器配置类，可以进行自动装配，在写代码时配置的@Controller，@Service，@Component，@Repository自动扫描配置到ioc容器中，供springboot调用。springboot自动装配的原理，创建一个main入口，在类上注解@SpringBootApplication，这就完成了springboot的基本配置，前提是pom.xml配置好依赖。...
spring boot 自动扫描Controller、Service、Component原理
u014200244的专栏
01-09 2293
spring boot 启动类加上@SpringBootApplication会自动扫描当前目录，及子目录下的Controller，Service，Component注解的bean。##看到ConfigurationClassParser解析ComponentScans.class, ComponentScan.class注解。查看@SpringBootApplication注解源码，里面有@ComponentScan注解。启动类没有@ComponentScan注解。##包名为空，添加启动类所在的包。
SpringBoot常用注解
baozi121的博客
09-30 1325
SpringBoot常用注解
Spring Boot 中的 @ComponentScan 注解是什么，原理，如何使用
徐师兄的博客
06-27 2973
在本文中，我们介绍了 Spring Boot 中的 @ComponentScan 注解。这个注解可以让 Spring 自动扫描指定的包及其子包中的组件，并将它们自动装配到 Spring 容器中。我们还介绍了 @ComponentScan 注解的原理以及如何在 Spring Boot 中使用它。如果你正在开发一个大型的 Spring Boot 应用，那么使用 @ComponentScan 注解可以帮助你更加方便地管理和装配组件，减少手动配置的工作量。
【Spring Boot 对Bean扫描的几种方式】
qq_33545255的博客
12-06 1379
Spring Boot通过简化配置，使得Bean的扫描变得更加容易。通过注解，Spring Boot自动扫描启动类所在包及其子包中的Bean。如果需要自定义扫描路径，可以使用注解来指定。这些机制使得Spring Boot在微服务架构中非常受欢迎，因为它大大减少了配置的复杂性。
spring中所涉及到的SPI机制
gwokgwok137的博客
02-21 4759
一、什么是SPI SPI ，全称为 Service Provider Interface，是一种服务发现机制，这一机制被广大厂商和插件所使用。 SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。在我们的系统中有各个抽象的模块，而往往该模块会有很多不同的实现方案，比如： 日志模块：加载不同的日志实现框架 jdbc模块：加载不同类型的数据库驱动 spring：spring-web加载不同的web容器（servlet3.0所规范的） TypeConversion SPI
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值