SpringBoot自动装配底层全流程

以自定义线程池Starter为例，完整讲透SpringBoot自动装配底层全流程

我们先把整套东西的分工先说清楚，再顺着程序启动的顺序，一步一步拆解底层发生了什么，全程结合我们手写的线程池starter来讲。

一、先理清我们手写starter三个模块各自的作用，这是自动装配的载体

我们一共写了三层工程，各司其职，缺一不可：

1. my-starter父工程：只用来统一锁定SpringBoot版本、统一管理所有子模块版本，本身不提供任何业务代码，是Maven多模块的管理壳子；
2. threadpool-autoconfigure（自动配置核心包）：这是自动装配真正干活的核心，里面有三块关键代码：
   • ThreadPoolProperties：绑定yml配置的属性类；
   • ThreadPoolAutoConfiguration：线程池的自动配置类，带条件注解，负责创建线程池Bean；
   • META-INF/spring/xxx.imports 文件：SPI注册文件，告诉SpringBoot“我这里有一个自动配置类需要加载”；
3. threadpool-starter（启动器空包）：里面一行Java代码都没有，只在pom里依赖上面的autoconfigure包。它的作用就是给使用者提供一个统一依赖坐标，别人只需要引入这个starter，就能间接引入自动配置核心代码，不用自己管理多个依赖。

使用者会新建一个demo-test测试项目，引入我们写好的starter，写Controller注入线程池使用，这是自动装配的使用者端。

二、SpringBoot项目启动的第一阶段：开启自动装配总开关

我们demo-test的启动类上标注了@SpringBootApplication，这个注解是一个复合注解，里面包含三个关键能力，和自动装配强相关的是@EnableAutoConfiguration：

1. @ComponentScan：只会扫描当前demo-test项目自己包下的Controller、自定义配置类，不会扫描第三方jar包里的代码，这也是为什么我们不能把接口写在starter里；
2. @Configuration：标记当前启动类也是一个配置类；
3. @EnableAutoConfiguration：自动装配的总开关，没有这个注解，后面所有自动配置都不会执行。

点开@EnableAutoConfiguration源码，它内部通过@Import(AutoConfigurationImportSelector.class)导入了一个选择器类，这个选择器就是自动装配底层的核心执行器，整个自动装配的逻辑全部由这个类驱动。

三、第二阶段：选择器扫描所有jar，找到我们线程池的自动配置类

当程序走到AutoConfigurationImportSelector的核心方法getAutoConfigurationEntry()时，会执行一套固定流程，专门读取第三方jar里的自动配置：

1. 程序遍历当前项目所有引入的依赖jar包，包括我们导入的threadpool-starter，starter又传递依赖了autoconfigure包；
2. 针对每一个jar包，去固定路径读取文件：SpringBoot3规范路径是META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports；
3. 读到我们autoconfigure包里的这个文件，文件里写了我们配置类的全类名com.starter.threadpool.autoconfigure.ThreadPoolAutoConfiguration，程序会把这个类名存进一个待加载列表；
4. 同理，如果项目引入redis、web等官方starter，也会读取对应imports文件，收集所有官方自动配置类。

简单说：我们手写的imports文件，就是给SpringBoot留的“路标”，告诉启动程序：我的jar包里有一个自动配置类，记得加载它。如果不写这个文件，SpringBoot完全不知道我们存在ThreadPoolAutoConfiguration，自动装配直接失效。

四、第三阶段：根据条件注解，判断我们的线程池配置类是否生效

收集完所有自动配置类名后，Spring不会直接全部加载，会通过条件注解做过滤，我们ThreadPoolAutoConfiguration上的注解就在这里生效：

1. 首先判断类上@ConditionalOnClass(ThreadPoolExecutor.class)：校验当前JVM中是否存在ThreadPoolExecutor这个类，这个类是JDK原生线程池类，必然存在，所以我们这个配置类不会被过滤，保留下来；
   举个对比：如果是Redis自动配置，会判断项目里有没有RedisTemplate类，没引入redis starter就过滤掉配置，实现按需装配；
2. 确认配置类生效后，处理@EnableConfigurationProperties(ThreadPoolProperties.class)：
   Spring会读取项目resources下的application.yml文件，匹配前缀starter.threadpool的配置，把yml里写的核心线程、最大线程、队列容量等数值，自动注入到ThreadPoolProperties实体类中，并且把这个属性类存入Spring容器，后续创建线程池时直接读取配置参数；
3. 此时ThreadPoolAutoConfiguration已经被Spring识别为标准@Configuration配置类，等待执行里面的@Bean方法。

五、第四阶段：创建线程池Bean，实现“自动装配”核心效果

Spring处理配置类内部的@Bean方法，也就是我们创建ThreadPoolExecutor的方法，这里@ConditionalOnMissingBean注解发挥作用：

1. Spring先去当前容器中检索：有没有已经存在ThreadPoolExecutor类型的Bean；
2. 分两种情况：
   • 情况1：用户demo-test项目里没有手动写线程池@Bean：容器找不到对应Bean，满足@ConditionalOnMissingBean的条件，执行我们的方法；
     方法会拿着之前注入完成的ThreadPoolProperties（yml配置参数），new一个ThreadPoolExecutor线程池对象，放入Spring单例容器；
   • 情况2：用户自己写了配置类，手动创建了ThreadPoolExecutor Bean：容器中已经存在对应实例，注解生效，跳过我们自动创建Bean的逻辑，优先使用用户自定义的线程池，满足扩展、覆盖的需求；
3. 执行完成后，Spring容器里已经存在一个可用的线程池实例，不需要用户手动new、手动写配置类，这就是“自动装配”带来的便捷。

六、第五阶段：使用者注入使用，走完完整链路

当Spring容器初始化完成后，我们在demo-test的PoolTestController中写@Resource private ThreadPoolExecutor threadPoolExecutor：
Spring会从容器中取出我们自动装配好的线程池Bean，直接注入给Controller，接口访问时就能调用线程池执行任务，全程不需要用户关心线程池是怎么创建、怎么读取yml配置的。

七、整条底层流程串联总结（简化完整版）

1. 开发者在测试项目引入自定义线程池starter；
2. 启动类@SpringBootApplication携带@EnableAutoConfiguration，开启自动装配；
3. 底层AutoConfigurationImportSelector扫描所有jar包，读取autoconfigure中的imports文件，拿到线程池自动配置类的完整类名；
4. 校验配置类上@ConditionalOnClass，确认配置类可以生效；
5. 通过@EnableConfigurationProperties读取application.yml的自定义线程池配置，封装到属性类；
6. 执行配置类里的@Bean方法，通过@ConditionalOnMissingBean判断，无自定义Bean则自动创建线程池放入Spring容器；
7. 业务Controller直接注入容器中自动生成的线程池，完成使用。

补充设计思想：为什么要这么设计？

这套自动装配解决了原生Spring的痛点：原生Spring想要使用线程池，必须自己写配置类、手动读取配置文件、手动注册Bean；而通过starter+自动装配，把通用组件的创建逻辑、配置绑定逻辑全部封装到第三方jar，使用者只需要引入依赖、简单写yml参数，底层全部由SpringBoot自动完成，同时依靠条件注解实现按需加载、支持用户自定义覆盖，符合开闭原则。

口述版

SpringBoot项目启动类标注@SpringBootApplication，它是组合注解，其中@EnableAutoConfiguration注解内部带有@Import，导入自动配置选择器AutoConfigurationImportSelector；
这个选择器的selectImports方法会扫描项目所有导入的jar包，读取每个jar包下META-INF/spring目录的AutoConfiguration.imports文件，文件内记录所有候选自动配置类的全类名，读取后存入候选列表。

随后根据每个自动配置类上的@Conditional系列注解做过滤，仅满足条件的配置类会保留，不满足条件直接丢弃。
过滤后保留的自动配置类一般标注@EnableConfigurationProperties(XXX.class)；属性类XXX.class带有@ConfigurationProperties(prefix = "xxx")注解，Spring会读取application.yml中对应前缀的配置，封装到该属性类，并将属性类存入容器，供自动配置类读取配置参数。

Spring启动执行refresh()容器刷新流程时，会提前解析配置类中的@Bean方法，根据方法上@ConditionalOnMissingBean注解判断：若容器已存在同类型Bean，则跳过当前Bean创建逻辑；否则执行@Bean方法完成实例化，将Bean存入Spring容器。

最终在Controller、Service等业务代码中，可直接通过依赖注入拿到容器内提前创建好的Bean直接使用。

自动装配的核心好处：无需手动编写配置类、无需手动解析yml并封装配置实体，底层逻辑全部自动化，引入第三方starter后可直接使用其封装好的Bean。