本文主要是介绍Spring 中 ConfigurationClassPostProcessor 类扫描解析之 @ComponentScan 解析,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
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
这篇关于Spring 中 ConfigurationClassPostProcessor 类扫描解析之 @ComponentScan 解析的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!