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

在上篇阐述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 found
		if (configCandidates.isEmpty()) {
			return;
		}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

就是选出除次组候选配置类，一般情况下就一个，SpringBoot中就对应着我们写的那个@SpringApplication对应的那个类的BeanDefinition。

检查配置方法逻辑-checkConfigurationClassCandidate

接下来看看 checkConfigurationClassCandidate 方法的逻辑，就是检查是否是配置类的这个方法，后面会有基础都有这个方法，所以这里需要多留意一下：

1. 排除@Bean形成的BeanDefinition：
   
2. 如果被 @Configuration 注解修饰了的话就是候选配置类：
   
3. 如果被 @Component、@ComponentScan、@Import、@ImportResource 注解修饰，或者内部含有@Bean注解，也被当做是配置类（@SpringBootApplication注解内部就是通过@ComponentScan修饰的）：
   

2. 解析配置类的具体逻辑

这里只提供核心源码解析哈，因为有些与咱看代码无关紧要的代码太多了。

1. 首先是去条件匹配@Conditional注解（这里是判断是否需要解析配置类进行的@Conditional，和之前扫描器那里的@Conditional不能混为一谈）：
   

2. 从当前类遍历父类调用 doProcessConfigurationClass 方法去解析对应配置（核心代码）：
   

3. 如果被 @Component 注解修饰，会去解析对应内部类是否是配置类，是的话进行解析：
   测试：
   

4. 解析 @PropertySource 注解，将配置文件中的k-v放入到环境Environment中：
   这个就不测试了，大伙应该都用过。

5. 解析 @ComponentScan 注解，然后用 scanner 扫描器进行扫描得到候选的BeanDefinition，然后将这些BeanDefinition都遍历一遍当配置类解析去，这就是关键：
   

6. 解析 @Import 注解，将注解里写的类当做配置类解析了（还有其他俩种，但是不想阐述， 几乎不用）：
   测试：
   

7. 解析 @ImportResource ，就是将xml导入，用的不多不想给分析源码。

8. 将 @Bean 注解修饰的方法封装成BeanMethod的对象，后续会封装成 BeanDefinition 通过 reader 进行注册，在推断构造的时候就会通过这个进行构造
   
   下面这行逻辑就是把对应解析出来的 BeanMethod 对象集解析成 BeanDefinition 然后注册到 reader 中。

二、postProcessBeanFactory 源码分析

@Configuration 注解的作用

就结合实际场景，就比如我们使用@Bean注解修饰的方法的时候，有时会调用另一个@Bean修饰的方法返回的对象，此时是需要返回的是容器内管理的，是单例的，而不是说的Java里的普通的方法返回地址的。

而使用 @Configuration 注解就才可以实现这种效果，让它修饰的类会生成一个代理对象…

里面就不源码分析了，感觉没必要。

测试：

没加@Configuration注解哈：

可用看见三个不重样，但是按道理应该是单例同一个的。加上 @Configuration 注解试试：

三、总结

1. 通过 ConfigurationClassPostProcessor 把配置类取出来进行解析；
2. 配置类只要是被 @Configuration、@Component、@ComponentScan、@Import、@ImportResource 修饰的就算是配置类；
3. 如果配置类上存在 @Component 注解，那就会解析内部类上的配置；
4. 如果配置类上存在 @PropertySource 注解，那就会把里面修饰的配置里的k-v放入到Environment中；
5. 如果配置类上存在 @ComponentScan 注解，那就会解析该注解，进行扫描，把扫描得到的BeanDefinition再去遍历去尝试解析配置；
6. 如果配置类上存在 @Import 注解，则会把@Import注解里的类当作配置类解析；
7. 如果配置类上存在 @ImportResource 注解，那么就会把xml资源存进去；
8. 让 @Bean 修饰的方法封装为 BeanMethod 对象，并添加到类对象中的 beanMethods 属性中，后面封装成 BeanDefinition，后续推断构造的时候就会使用这个方法进行得到对应实体。