本文主要是介绍【Spring源码分析】解析配置类-ConfigurationClassPostProcessor源码分析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
| 阅读此需阅读下面这些博客先 |
|---|
| 【Spring源码分析】Bean的元数据和一些Spring的工具 |
| 【Spring源码分析】BeanFactory系列接口解读 |
| 【Spring源码分析】执行流程之非懒加载单例Bean的实例化逻辑 |
| 【Spring源码分析】从源码角度去熟悉依赖注入（一） |
| 【Spring源码分析】从源码角度去熟悉依赖注入（二） |
| 【Spring源码分析】@Resource注入的源码解析 |
| 【Spring源码分析】循环依赖的底层源码剖析 |
| 【Spring源码分析】Spring的启动流程源码解析 |
解析配置类-ConfigurationClassPostProcessor源码分析
- 一、processConfigBeanDefinitions 源码分析
- 1. 选出配置类（这是未经过扫描的，也就是开始registry的）
- 检查配置方法逻辑-checkConfigurationClassCandidate
- 2. 解析配置类的具体逻辑
- 二、postProcessBeanFactory 源码分析
- @Configuration 注解的作用
- 三、总结
在上篇阐述Spring的启动流程的时候解释了有个扫描BeanDefinition的逻辑，就是去执行 Spring 存在的
BeanFactoryPostProcessor#postProcessBeanDefinitionRegistry和postProcessBeanFactory，而在执行这段之前，Spring就在 beanFactoryPostProcessor 集合中就放了一个
ConfigurationClassPostProcessor 实例，所以这里我们又可以说是去分析 ConfigurationClassPostProcessor 中的源码；
可能有人会觉得只有加了 @Configuration 的才是配置类，其实不是，在Spring中只要有以下注解修饰了的类就算是配置类：@Configuration、@Component、@ComponentScan、@Import、@ImportResource，其实可以扫描出来的类都是算是配置类的，因为都被@Component修饰了才算SpringBean嘛，这是扫描的时候符合includeFilter嘛，这里只是提一下，下面就是源码看为什么是了。因为我怕后面你们看不下去。
一、processConfigBeanDefinitions 源码分析
我不全部直接把源码写出来哈，我就一段一段解析，你们可以定位到源码然后配置这博客看。
1. 选出配置类（这是未经过扫描的，也就是开始registry的）
对应那段代码：
List<BeanDefinitionHolder> configCandidates = new ArrayList<>();String[] candidateNames = registry.getBeanDefinitionNames();for (String beanName : candidateNames) {BeanDefinition beanDef = registry.getBeanDefinition(beanName);if (beanDef.getAttribute(ConfigurationClassUtils.CONFIGURATION_CLASS_ATTRIBUTE) != null) {if (logger.isDebugEnabled()) {logger.debug("Bean definition has already been processed as a configuration class: " + beanDef);}}// 什么是配置类？else if (ConfigurationClassUtils.checkConfigurationClassCandidate(beanDef, this.metadataReaderFactory)) {configCandidates.add(new BeanDefinitionHolder(beanDef, beanName));}}// Return immediately if no @Configuration classes were foundif (configCandidates.isEmpty()) {return;}
就是选出除次组候选配置类，一般情况下就一个，SpringBoot中就对应着我们写的那个@SpringApplication对应的那个类的BeanDefinition。
检查配置方法逻辑-checkConfigurationClassCandidate
接下来看看 checkConfigurationClassCandidate 方法的逻辑，就是检查是否是配置类的这个方法，后面会有基础都有这个方法，所以这里需要多留意一下：
- 排除@Bean形成的BeanDefinition：
- 如果被
@Configuration注解修饰了的话就是候选配置类：
- 如果被
@Component、@ComponentScan、@Import、@ImportResource注解修饰，或者内部含有@Bean注解，也被当做是配置类（@SpringBootApplication注解内部就是通过@ComponentScan修饰的）：
2. 解析配置类的具体逻辑
这里只提供核心源码解析哈，因为有些与咱看代码无关紧要的代码太多了。
-
首先是去条件匹配@Conditional注解（这里是判断是否需要解析配置类进行的@Conditional，和之前扫描器那里的@Conditional不能混为一谈）：
-
从当前类遍历父类调用 doProcessConfigurationClass 方法去解析对应配置（核心代码）：
-
如果被 @Component 注解修饰，会去解析对应内部类是否是配置类，是的话进行解析：
测试：
-
解析
@PropertySource注解，将配置文件中的k-v放入到环境Environment中：
这个就不测试了，大伙应该都用过。 -
解析
@ComponentScan注解，然后用 scanner 扫描器进行扫描得到候选的BeanDefinition，然后将这些BeanDefinition都遍历一遍当配置类解析去，这就是关键：
-
解析
@Import注解，将注解里写的类当做配置类解析了（还有其他俩种，但是不想阐述， 几乎不用）：
测试：
-
解析
@ImportResource，就是将xml导入，用的不多不想给分析源码。 -
将 @Bean 注解修饰的方法封装成BeanMethod的对象，后续会封装成 BeanDefinition 通过 reader 进行注册，在推断构造的时候就会通过这个进行构造
下面这行逻辑就是把对应解析出来的 BeanMethod 对象集解析成 BeanDefinition 然后注册到 reader 中。
二、postProcessBeanFactory 源码分析
@Configuration 注解的作用
就结合实际场景，就比如我们使用@Bean注解修饰的方法的时候，有时会调用另一个@Bean修饰的方法返回的对象，此时是需要返回的是容器内管理的，是单例的，而不是说的Java里的普通的方法返回地址的。
而使用 @Configuration 注解就才可以实现这种效果，让它修饰的类会生成一个代理对象…
里面就不源码分析了，感觉没必要。
测试：
没加@Configuration注解哈：
可用看见三个不重样，但是按道理应该是单例同一个的。
加上 @Configuration 注解试试：
三、总结
- 通过 ConfigurationClassPostProcessor 把配置类取出来进行解析；
- 配置类只要是被
@Configuration、@Component、@ComponentScan、@Import、@ImportResource修饰的就算是配置类； - 如果配置类上存在 @Component 注解，那就会解析内部类上的配置；
- 如果配置类上存在 @PropertySource 注解，那就会把里面修饰的配置里的k-v放入到Environment中；
- 如果配置类上存在 @ComponentScan 注解，那就会解析该注解，进行扫描，把扫描得到的BeanDefinition再去遍历去尝试解析配置；
- 如果配置类上存在 @Import 注解，则会把@Import注解里的类当作配置类解析；
- 如果配置类上存在 @ImportResource 注解，那么就会把xml资源存进去；
- 让 @Bean 修饰的方法封装为 BeanMethod 对象，并添加到类对象中的 beanMethods 属性中，后面封装成 BeanDefinition，后续推断构造的时候就会使用这个方法进行得到对应实体。
这篇关于【Spring源码分析】解析配置类-ConfigurationClassPostProcessor源码分析的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
