ConfigurationClassPostProcessor 简单概述

Spring 中类的解析是非常重要的，因为工程中有很多类，并且被一些注解修饰，比如：@Component、@Bean、@Import、@PropertySource、@ImportSource、@Scope 等。

你在类或者方法上标注这些注解，Spring 想要认识它，就需要通过 ConfigurationClassPostProcessor 类去解析扫描，以一定的形式加载到 Spring 中 (BeanDefinition)，这样 Spring 才能够去使用它，并且去管理它。

ConfigurationClassPostProcessor 类是 BeanFactoryPostProcessor 接口的应用，在同类行中它的执行优先级是最低的，它的作用就是将工程中的类 xxx.class 文件解析封装成 BeanDefinition，然后 Spring 就可以根据 BeanDefinition 模版生产 bean。

可以说没有 ConfigurationClassPostProcessor 这个类就没有 Spring 大家族，一切都是靠这个类白手起家的！

ConfigurationClassPostProcessor 类注册和调用

那么 ConfigurationClassPostProcessor 类是设么时候存在的呢？追踪源码如下：

从上面源码中可以看出 Spring 直接内置了这几个核心类，直接手动创建 RootBeanDefinition 封装 ConfigurationClassPostProcessor 的模版。因为 Spring 肯定要有带头大哥，这几个内置的系统类都是带头大哥，这样就可以通过一个类然后生产一大家族出来。

那么 BeanDefinition 已经创建好啦，在哪个地方将 ConfigurationClassPostProcessor 实例化的呢？源码如下：

最终追踪到下面这段源码中，Spring 通过 getBeanNamesForType() 方法获取到所有实现 BeanDefinitionRegistryPostProcessor 接口的子类实现，其实目前只有一个那就是 ConfigurationClassPostProcessor，因为现在才刚开始阶段，类的解析都还没开始，所以 Spring 容器中基本上没啥东西。这里直接调用 getBean() 实例化 ConfigurationClassPostProcessor 类。

然后下面就要开始调用 ConfigurationClassPostProcessor 这个类中的 postProcessBeanDefinitionRegistry() 方法去解析扫描其他类，就此类的解析流程就开始了！后面都是围绕着这个类进行解析。

@ComponentScan 扫描解析类

进入到 ConfigurationClassPostProcessor 类的 postProcessBeanDefinitionRegistry() 方法中，我们先看比较简单的 @ComponentScan 注解扫描解析。

@ComponentScan 注解大家都知道会去扫描 @Component 修饰的类，最终交给 Spring 管理。这里就用一个案例开始分析。

先定义个 Student 类，并且用 @Component 修饰，如下：

package com.gwm.componentscan;

@Component
public class Student {

}

然后定义一个测试类，并且通过 @ComponentScan 注解去扫描 @Component 修饰的类，这里直接指定 basePackages 包的路径，如果不指定包路径，也会默认使用 ComponentScanTest 类所在的包路径(后面源码可以看到这个逻辑)作为扫描路径， 如下：

@ComponentScan(basePackages = "com.gwm.componentscan")
public class ComponentScanTest {
	public static void main(String[] args) {
		ApplicationContext context = new AnnotationConfigApplicationContext(ComponentScanTest.class);
		Student bean = context.getBean(Student.class);
		System.out.println("bean = " + bean);
	}
}

这里 ComponentScanTest 类作为 AnnotationConfigApplicationContext 类的参数，即为入口类，这是第一个自定义类被注册到 BeanDefinitionMap 中，源码如下：

Spring 手动创建一个 AnnotatedGenericBeanDefinition 模版，封装 ComponentScanTest.class 类，然后最终注册到 Spring 容器的 BeanDefinitionMap 中。

这个 ComponentScanTest 类将会成为导火索，由这个类触发可以解析更多的类，注册完入口类之后，回到
ConfigurationClassPostProcessor 类的 postProcessBeanDefinitionRegistry() 方法中，核心源码如下：

从上述源码中可以看出，ComponentScanTest 类被 @ComponentScan 修饰，所以会加入到 configCandidates 容器中，等待被处理，接着往下看，准备好一个专门用来解析类内容的对象 ConfigurationClassParser，源码如下：

判断 ComponentScanTest 类是否有 @ComponentScan 注解，很显然是有的，并且获取到 @ComponentScan 所有的属性信息，其中一个就是 basePackages 包路径，源码如下：

然后进入 parse() 方法开始解析，进来就直接生成一个包扫描器 ClassPathBeanDefinitionScanner ，这个类负责把 Spring 中指定包下面的所有被 @Component 修改的类扫描到 Spring 中

进入 ClassPathBeanDefinitionScanner 包扫描器构造方法中，默认会给包扫描器一个过滤条件，其实就是指定这个包扫描器只能对 @Component 生效，源码如下：

指定只扫描有 @Component 注解修饰的类，所以为什么 @ComponentScan 默认只扫描 @Component 注解，其他注解都不管，原因就是这个过滤条件限定死了。

下面这段逻辑就解释了为什么你在 @ComponentScan 中不用显示的配置包路径也能扫描到类，Spring 默认就会用入口类所在的包路径作为扫描路径，源码如下：

然后进入 doScan() 方法，开始真正的扫描，源码如下：

将 doScan() 方法拆分成三部分讲解：

第一部分： findCandidateComponents() 内部逻辑就是通过 Resource 流的方式去这个包路径下面读取所有的 class 文件，然后判断哪些 class 上面有 @Component 注解修饰，有的话，就会封装成 ScannedGenericBeanDefinition 模版，注意这里只是封装，而且 BeanDefinition 的属性还比较少，并没有注册到 Spring 容器中。

进入 findCandidateComponents() 方法，源码如下：

过滤是否有 @Component 修饰的类，includeFilters 在前面已经提过，Spring 默认就给这个容器中放了一个 @Component 注解，表示只处理又这个注解修饰的类。源码如下：

第二部分： 第一步封装的 BeanDefinition 属性还比较少，现在继续解析 class 上是否有 @Scope 注解修饰，然后生成 beanName 名称，也是唯一的 bean 的 ID，然后就是其他 BeanDefinition 属性的填充(@Lazy、@Primary 等)，这第二部完成，BeanDefinition 属性就立马多起来了。

第三部分： 将第二步完善好的 BeanDefinition 注册到 Spring 容器中 (BeanDefinitionMap、BeanDefinitionNames)

经过这三部操作，@ComponentScan 注解算基本上完成对 @Component 扫描解析，但是还不够全，因为你不知道解析出来的类里面是否还包含 @Component 注解或者其他注解 @Import 等，所以需要继续进行判断，看解析完的的类里面是否还包含 @Component、@Import 等注解，追踪源码如下：

注意这个判断条件 checkConfigurationClassCandidate()，这个判断条件有点意思，有什么作用呢？就是在这个方法里面如果判断类是被 @Configuration 注解修饰，就会认为是全扫描，并标记上为 full 全扫描，被 @Component 注解修饰的，认为是部分扫描，并标记为 little 部分扫描。 其实打上这个标记就是在后续操作中 full 标记的类会用代理的方式生成对象，侧面说明 @Configuration 注解修饰的类最终 Spring 容器中是一个代理对象，而且是 cglib 代理对象，这个在这里只是扩展，具体可以看我另一篇文章有解析过，现在继续回到这里。

发现代码会继续调用 parse() 方法去扫描解析 @Component、和其他注解修饰的类，其实这是一种递归调用。

最终解析完后 @Component 修饰的类都被 @ComponentScan 全部解析完成，并注册到 Spring 容器中。

总结

读取所有资源文件判断哪些有 @Component 修饰，封装成 BeanDefinition，然后注册到 Spring 容器中完事

扩展

MetadataReader 元数据封装着一个类所有的内容，另一篇文章中有详细介绍
ClasspathBeanDefinitionScanner 包扫描器，对指定路径下进行扫描，过滤条件可以自己重写 Filter