【小家Spring】Spring解析@ComponentScan注解源码分析（ComponentScanAnnotationParser、ClassPathBeanDefinitionScanner）
【小家Spring】Spring解析@ComponentScan注解源码分析（ComponentScanAnnotationParser、ClassPathBeanDefinitionScanner）
YourBatman
发布于 2019-09-03 16:29:56
发布于 2019-09-03 16:29:56
前言
前面我在这篇博文：【小家Spring】Spring解析@Configuration注解的处理器：ConfigurationClassPostProcessor（ConfigurationClassParser） 解释Spring解析@Configuration的时候，提到过了解析：@PropertySource、@ComponentScan、@Import…等等的解析过程。
它在这个类里大概如下：ConfigurationClassParser#doProcessConfigurationClass：
protected final SourceClass doProcessConfigurationClass(ConfigurationClass configClass, SourceClass sourceClass){
//1、Process any @PropertySource annotations
//2、Process any @ComponentScan annotations ===
==== 这一步解析，现在就是我们今天的主题，下面会对源码进行分析 ====
//3、Process any @Import annotations
//4、Process any @ImportResource annotations
//5、Process individual @Bean methods
//6、Process default methods on interfaces
//7、Process superclass, if any
}因为扫描模式在应用（我们自己在涉及自己的框架的时候，扫描模式也会被大量的、广泛的应用）使用非常的广泛，因此本文有必要来说说@ComponentScan的原理，旨在掌握它的运行过程，然后学以致用。
Spring Boot默认扫描Bean的处理，就是基于
@ComponentScan这个注解的
源码分析
入口处源码
前言部分已经提到了入口处，因此这里直接贴出此部分的源码吧：
// Process any @ComponentScan annotations
// 拿到该类上面所有的@ComponentScan注解，包含重复注解
Set<AnnotationAttributes> componentScans = AnnotationConfigUtils.attributesForRepeatable(
sourceClass.getMetadata(), ComponentScans.class, ComponentScan.class);
// 不为空，且此类不会被跳过,就开始解析吧
if (!componentScans.isEmpty() && !this.conditionEvaluator.shouldSkip(sourceClass.getMetadata(), ConfigurationPhase.REGISTER_BEAN)) {
for (AnnotationAttributes componentScan : componentScans) {
// The config class is annotated with @ComponentScan -> perform the scan immediately
// 最终委托给了componentScanParser去完成这件事：至于componentScanParser是什么呢？下面有解释
// 备注：这个方法虽然有返回值，但是其实内部都已经把Bean定义信息加入到工厂里面去了
Set<BeanDefinitionHolder> scannedBeanDefinitions = this.componentScanParser.parse(componentScan, sourceClass.getMetadata().getClassName());
// Check the set of scanned definitions for any further config classes and parse recursively if needed
//这里面有一个重要的一步，还需要把每个Bean检测一遍。因为Scan出来的Bean，还有可能是@Configuration的，或者标注有@Import等等一些列注解的，因此需要再次交给parse一遍，防止疏漏
for (BeanDefinitionHolder holder : scannedBeanDefinitions) {
BeanDefinition bdCand = holder.getBeanDefinition().getOriginatingBeanDefinition();
if (bdCand == null) {
bdCand = holder.getBeanDefinition();
}
if (ConfigurationClassUtils.checkConfigurationClassCandidate(bdCand, this.metadataReaderFactory)) {
parse(bdCand.getBeanClassName(), holder.getBeanName());
}
}
}
}
`componentScanParser`是什么呢？
private final ComponentScanAnnotationParser componentScanParser;
// 然后在ConfigurationClassParser的构造函数里，对他进行了初始化
public ConfigurationClassParser(MetadataReaderFactory metadataReaderFactory,
ProblemReporter problemReporter, Environment environment, ResourceLoader resourceLoader,
BeanNameGenerator componentScanBeanNameGenerator, BeanDefinitionRegistry registry) {
this.metadataReaderFactory = metadataReaderFactory;
this.problemReporter = problemReporter;
this.environment = environment;
this.resourceLoader = resourceLoader;
this.registry = registry;
// 这里对componentScanParser 进行初始化。持有环境、ResourceLoader、名字生成器、注册器的引用
this.componentScanParser = new ComponentScanAnnotationParser(environment, resourceLoader, componentScanBeanNameGenerator, registry);
// 初始化condition的计算器，持有注册器、环境、ResourceLoader的引用
this.conditionEvaluator = new ConditionEvaluator(registry, environment, resourceLoader);
}ComponentScanAnnotationParser：准们解析@ComponentScan的类
从访问权限（Default）来看，它被定义为Spring的一个自己内部使用的工具类。它的惟一一个public方法为：parse()：
public Set<BeanDefinitionHolder> parse(AnnotationAttributes componentScan, final String declaringClass) {
// 第一句代码就看出了端倪：原来扫描的工作最终还是委托给了ClassPathBeanDefinitionScanner去做
// 注意：useDefaultFilters这个值特别的重要，能够解释伙伴们为何要配置的原因~~~下面讲解它的时候会有详解
ClassPathBeanDefinitionScanner scanner = new ClassPathBeanDefinitionScanner(this.registry, componentScan.getBoolean("useDefaultFilters"), this.environment, this.resourceLoader);
// BeanName的生成器，我们可以单独制定。若不指定（大部分情况下都不指定），那就是默认的AnnotationBeanNameGenerator
// 它的处理方式是：类名首字母小写
Class<? extends BeanNameGenerator> generatorClass = componentScan.getClass("nameGenerator");
boolean useInheritedGenerator = (BeanNameGenerator.class == generatorClass);
scanner.setBeanNameGenerator(useInheritedGenerator ? this.beanNameGenerator :
BeanUtils.instantiateClass(generatorClass));
// 这两个属性和scope代理相关的，这里略过，使用较少
ScopedProxyMode scopedProxyMode = componentScan.getEnum("scopedProxy");
if (scopedProxyMode != ScopedProxyMode.DEFAULT) {
scanner.setScopedProxyMode(scopedProxyMode);
} else {
Class<? extends ScopeMetadataResolver> resolverClass = componentScan.getClass("scopeResolver");
scanner.setScopeMetadataResolver(BeanUtils.instantiateClass(resolverClass));
}
// 控制去扫描哪些.clsss文件的模版。一般不设置 默认值为：**/*.class 全扫嘛
scanner.setResourcePattern(componentScan.getString("resourcePattern"));
// includeFilters和excludeFilters算是内部处理最复杂的逻辑了，但还好，对使用者是十分友好的
for (AnnotationAttributes filter : componentScan.getAnnotationArray("includeFilters")) {
for (TypeFilter typeFilter : typeFiltersFor(filter)) {
scanner.addIncludeFilter(typeFilter);
}
}
for (AnnotationAttributes filter : componentScan.getAnnotationArray("excludeFilters")) {
for (TypeFilter typeFilter : typeFiltersFor(filter)) {
scanner.addExcludeFilter(typeFilter);
}
}
// Spring4.1后出现的。哪怕我是扫描的Bean，也支持懒加载啦
boolean lazyInit = componentScan.getBoolean("lazyInit");
if (lazyInit) {
scanner.getBeanDefinitionDefaults().setLazyInit(true);
}
// 这里属于核心逻辑，核心逻辑，核心逻辑
Set<String> basePackages = new LinkedHashSet<>();
String[] basePackagesArray = componentScan.getStringArray("basePackages");
// Spring在此处有强大的容错处理。瑞然他是支持数组的，但是它这里也容错处理：支持,;换行等的符号分隔处理
// 并且，并且更强大的地方在于：它支持${...}这种占位符的形式，非常的强大。我们可以动态的进行扫包了~~~~~厉害了我的哥
for (String pkg : basePackagesArray) {
String[] tokenized = StringUtils.tokenizeToStringArray(this.environment.resolvePlaceholders(pkg),
ConfigurableApplicationContext.CONFIG_LOCATION_DELIMITERS);
Collections.addAll(basePackages, tokenized);
}
//basePackageClasses有时候也挺好使的。它可以指定class，然后这个class所在的包（含子包）都会被扫描
for (Class<?> clazz : componentScan.getClassArray("basePackageClasses")) {
basePackages.add(ClassUtils.getPackageName(clazz));
}
// 如果我们没有指定此值，它会取当前配置类所在的包 比如SpringBoot就是这么来干的
if (basePackages.isEmpty()) {
basePackages.add(ClassUtils.getPackageName(declaringClass));
}
scanner.addExcludeFilter(new AbstractTypeHierarchyTraversingFilter(false, false) {
@Override
protected boolean matchClassName(String className) {
return declaringClass.equals(className);
}
});
// 最后，最后，把@ComponentScan的属性都解析好了，就交给scanner去扫描吧
// 因为都准备好了，所以这里直接调用的doScan()哦~
return scanner.doScan(StringUtils.toStringArray(basePackages));
}这里再次提示一下：
@ComponentScan(basePackages = "${xxx}")是支持这么写的 可谓非常暖心。
ClassPathBeanDefinitionScanner 类路径下的Bean定义扫描器
参考博文：【小家Spring】Spring容器加载Bean定义信息的两员大将：AnnotatedBeanDefinitionReader和ClassPathBeanDefinitionScanner
其实这个类我们早就接触过了，前面讲到AnnotationConfigApplicationContext容器初始化的时候，就讲到了它，它可以去扫描特定类型的组件。它有它自己的默认扫描策略。它继承自ClassPathScanningCandidateComponentProvider：
下面我们先从它的构造函数说起：
public ClassPathBeanDefinitionScanner(BeanDefinitionRegistry registry, boolean useDefaultFilters,
Environment environment, @Nullable ResourceLoader resourceLoader) {
Assert.notNull(registry, "BeanDefinitionRegistry must not be null");
this.registry = registry;
// 我们发现这个useDefaultFilters特别重要，默认情况下他是true，只会扫描默认的注解们
// 至于是哪些注解，看下面
if (useDefaultFilters) {
registerDefaultFilters();
}
setEnvironment(environment);
setResourceLoader(resourceLoader);
}
//registerDefaultFilters();
protected void registerDefaultFilters() {
// @Component显然默认是必须要扫描的嘛
this.includeFilters.add(new AnnotationTypeFilter(Component.class));
ClassLoader cl = ClassPathScanningCandidateComponentProvider.class.getClassLoader();
// 下面两个是，默认也支持JSR-250规范的`@ManagedBean`和JSR-330规范的@Named注解(但是我并不建议大家使用，还是使用Spring源生的吧)
try {
this.includeFilters.add(new AnnotationTypeFilter(
((Class<? extends Annotation>) ClassUtils.forName("javax.annotation.ManagedBean", cl)), false));
logger.debug("JSR-250 'javax.annotation.ManagedBean' found and supported for component scanning");
}
catch (ClassNotFoundException ex) {
// JSR-250 1.1 API (as included in Java EE 6) not available - simply skip.
}
try {
this.includeFilters.add(new AnnotationTypeFilter(
((Class<? extends Annotation>) ClassUtils.forName("javax.inject.Named", cl)), false));
logger.debug("JSR-330 'javax.inject.Named' annotation found and supported for component scanning");
}
catch (ClassNotFoundException ex) {
// JSR-330 API not available - simply skip.
}
}需要说明的是：@Controller、@ControllerAdvice、@Service、@Repository都属于@Component范畴。当然还有@Configuration它也是
doScan()如下：
protected Set<BeanDefinitionHolder> doScan(String... basePackages) {
Assert.notEmpty(basePackages, "At least one base package must be specified");
Set<BeanDefinitionHolder> beanDefinitions = new LinkedHashSet<>();
for (String basePackage : basePackages) {
// 这里面findCandidateComponents是核心。这边就不再详解了，因为上面贴出的那篇博文已经有详解了
// 总之就是找到候选的Bean定义们
//findCandidateComponents这个方法需要注意，Spring5以后走的可能会从索引上走 addCandidateComponentsFromIndex()
// 如果不是Spring5 会走原来的逻辑scanCandidateComponents()
Set<BeanDefinition> candidates = findCandidateComponents(basePackage);
for (BeanDefinition candidate : candidates) {
ScopeMetadata scopeMetadata = this.scopeMetadataResolver.resolveScopeMetadata(candidate);
candidate.setScope(scopeMetadata.getScopeName());
String beanName = this.beanNameGenerator.generateBeanName(candidate, this.registry);
// 给刚扫描出来的Bean定义设置一些默认值
if (candidate instanceof AbstractBeanDefinition) {
postProcessBeanDefinition((AbstractBeanDefinition) candidate, beanName);
}
//解析@Primary、@Lazy...等等基础注解
if (candidate instanceof AnnotatedBeanDefinition) {
AnnotationConfigUtils.processCommonDefinitionAnnotations((AnnotatedBeanDefinition) candidate);
}
// 检查一些Bean定义，若之前已经存在了，看看采用什么策略吧（覆盖or不管？）
// 原则：在同意文件内，覆盖吧 在不同文件内 不管吧~~~~
if (checkCandidate(beanName, candidate)) {
BeanDefinitionHolder definitionHolder = new BeanDefinitionHolder(candidate, beanName);
definitionHolder = AnnotationConfigUtils.applyScopedProxyMode(scopeMetadata, definitionHolder, this.registry);
beanDefinitions.add(definitionHolder);
// 内部就已经把该Bean定义注册进去了，所以外部可以不用再重复注册了
registerBeanDefinition(definitionHolder, this.registry);
}
}
}
return beanDefinitions;
}
public Set<BeanDefinition> findCandidateComponents(String basePackage) {
// 如果是Spring5 会走这里（当然需要你手动开启~~~）
if (this.componentsIndex != null && indexSupportsIncludeFilters()) {
return addCandidateComponentsFromIndex(this.componentsIndex, basePackage);
} else {
// 老方式，简单的说，就是从从磁盘里找。利用了`ResourceLoader`的子接口ResourcePatternResolver
return scanCandidateComponents(basePackage);
}
}
// 私有方法，根据基础包名，去扫描所有的符合条件的类~~~
private Set<BeanDefinition> scanCandidateComponents(String basePackage) {
...
// 这个构建出来的 是基础包路径，形如：classpath*:com/fsx/demo1/**/*.class
// 从这里可以看出：首先它会去扫描Jar包（因为他是classpath*）,所以如果我们路径是这样的：
// "classpath*:org/springframework/**/*.class"：它会把所有的Spring里面的类都拿出来~~~~ 所以这个是需要注意的
// 小技巧：classpath*:**/*.class相当于拿到你所有的所有的类。可以借助这个看看你工程里面一共多少个类。Spring项目大约1万个往上走~~~~
String packageSearchPath = ResourcePatternResolver.CLASSPATH_ALL_URL_PREFIX + resolveBasePackage(basePackage) + '/' + this.resourcePattern;
// 调用ResourcePatternResolver来处理
// 注意：此处使用的实例默认为：PathMatchingResourcePatternResolver 当然你可以自己set来指定 但是一般都没有必要~~~~
Resource[] resources = getResourcePatternResolver().getResources(packageSearchPath);
... // 然后一个个遍历，看看哪个是@Component组件，然后就注册进去
}至此，整个@ComponentScan扫描完成，并且符合条件的组件也都注册进去了
从上源码分析我们发现：若我们想要扫描到Jar包里面的
@Component进容器，(@Import当然是阔仪)，也可以这么来做，也是能够实现我们的扫描需求的（如果jar包内非常多，可以考虑这种方式~~~）只是一般都不建议这么来使用
另外，若你想使用Spring5提供的新特性去加速项目的启动，你是需要额外导入这个Jar的（SpringBoot中不用指定版本号）：
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context-indexer</artifactId>
<scope>provided</scope>
</dependency>所以下面例子是可行的：
Jar包内（注意是jar包内 ）有一个类：
@Component
public class DemoComponent {
}显然我们另外一个服务项目导入这个jar：
<dependency>
<groupId>com.fsx.clients</groupId>
<artifactId>solog-service-api</artifactId>
<version>demo-SNAPSHOT</version>
</dependency>然后我们这个项目想把这个Jar里面的DemoComponent怎么办呢？？？可以按照如下做法（此处不介绍@Import的方式~）：
//@ComponentScan(basePackageClasses = DemoComponent.class) //若类不多，使用这种方式也是可行的
@ComponentScan(basePackages = "com.fsx.solog.demo") // 若包内类很多，推荐使用此种方式
@Configuration
public class Scan {
}这样测试一下，我们发现这个bean是被扫描进容器了的。
System.out.println(applicationContext.getBean(DemoComponent.class)); //com.fsx.solog.demo.DemoComponent@238b521eTips
既然知道了@ComponentScan如此的强大，所以使用的时候也务必务必要注意，不要无缘无故多扫描进Bean来的情况。
典型案例：比如我们现在大都使用SpringBoot构建微服务，依赖内置的@SpringBootApplication进行默认的包扫描：默认扫描Application主类所在的包以及所有的子包。
所以使用的时候，请务必务必确保如果你的jar需要提供给别人引入，不要被别人默认给扫描进去了，那就别人项目造成了非常强的依赖性。
一般情况下，我们自定的所有文件夹都放在一个以
服务名命名的子包内，而主类Application在外层~ 形如：jar包里类所在包为：com.fsx.solog（然后你所有的类都是solog下面或者子包内） 别人的项目包为：com.fsx.room，然后它所有的类都在这下面或者其子包内 这样就完成了隔离，最大可能的避免了侵入性。各位使用起来的时候请务必注意可能被重复扫描的可能，特别特别是你的jar可能会被提供给别人使用的情况
最后，若真的出现了此种情况，原理源码已经分析了，请务必知道怎么去排查和解决问题~这才是最重要的
总结
Scan扫描的思想，是一种批量处理的思想。它在设计模式中是具有非常好的通用性的。
本文以Spring内部的处理做源码分析为例，我们可以在自己设计框架的时候，也借鉴此些思想，达到更灵活配置，更通用，更能扩展的效果。
本文参与 腾讯云自媒体分享计划，分享自作者个人站点/博客。
原始发表：2019年03月18日，如有侵权请联系 cloudcommunity@tencent.com 删除
评论
登录后参与评论
推荐阅读