【Spring源码分析】解析配置类-ConfigurationClassPostProcessor源码分析

本文主要是介绍【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，后续推断构造的时候就会使用这个方法进行得到对应实体。

在这里插入图片描述