1.

springboot启动过程中,首先会收集需要加载的bean的定义,作为BeanDefinition对象,添加到BeanFactory中去。

由于BeanFactory中只有getBean之类获取bean对象的方法,所以将将BeanDefinition添加到BeanFactory中,是通过BeanDefinitionRegistry接口的void registerBeanDefinition(String beanName, BeanDefinition beanDefinition) throws BeanDefinitionStoreException;方法来完成的。

所以我们的BeanFactory的实现类如果需要具备通过beanName来返回bean对象和添加删除BeanDefinition的能力,至少实现BeanFactoryBeanDefinitionRegistry的这两个接口。

这里我们就来看看springboot是如何查找bean的定义,添加到BeanFactory中的。

由于我们这里只是关注查找bean对象的定义,所以这里我们这里提到的BeanFactory主要会关注BeanDefinitionRegistry这个接口。


我们本地主要分析springboot扫描加载bean的配置,和我们的代码关系不大,所以我们的代码就用最简单的吧。具体代码如下:

package com.example.bootargs;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication; @SpringBootApplication
public class BootargsApplication { public static void main(String[] args) {
SpringApplication.run(BootargsApplication.class, args);
} }

后面提到的主类统一是com.example.bootargs.BootargsApplication

2.

Springboot 查找bean的定义主要是通过ConfigurationClassPostProcessor这个类来完成的。

ConfigurationClassPostProcessor实现了BeanDefinitionRegistryPostProcessor接口。BeanDefinitionRegistryPostProcessor接口就是通过postProcessBeanDefinitionRegistry方法来给BeanDefinitionRegistry的实现类来添加bean的定义。

BeanDefinitionRegistryPostProcessor继承了BeanFactoryPostProcessor接口,而BeanFactoryPostProcessor接口主要是用来对BeanFactory进行增强。在springboot启动过程中首先会创建BeanFactory,再调用BeanFactoryPostProcessorBeanFactory

进行增强,最后才会去创建bean对象。

通过BeanFactoryPostProcessor对BeanFactory进行增强,主要是通过PostProcessorRegistrationDelegate的静态方法来完成的。在这过程中就会调用到ConfigurationClassPostProcessor这个类。

由于ConfigurationClassPostProcessor实现了BeanDefinitionRegistryPostProcessor接口,PostProcessorRegistrationDelegate就会调用ConfigurationClassPostProcessorpostProcessBeanDefinitionRegistry方法中,就会调用到processConfigBeanDefinitions方法来查找bean的定义。我们就从这里作为入口来看吧。


3.

下面我们就去看看ConfigurationClassPostProcessorprocessConfigBeanDefinitions方法

	/**
* Build and validate a configuration model based on the registry of
* {@link Configuration} classes.
*/
public void processConfigBeanDefinitions(BeanDefinitionRegistry registry) {
List<BeanDefinitionHolder> configCandidates = new ArrayList<>();
String[] candidateNames = registry.getBeanDefinitionNames();
//在下面的这个for循环中,会从beanFactory中已经有的bean的定义中寻找有Configuration注解的配置类。
//默认这里获取到的只有一个包含SpringBootApplication注解的主类
for (String beanName : candidateNames) {
......
configCandidates.add(new BeanDefinitionHolder(beanDef, beanName));
}
} //如果没有找到配置类,就直接返回
// Return immediately if no @Configuration classes were found
if (configCandidates.isEmpty()) {
return;
} ......
//在这里就通过ConfigurationClassParser去解析配置类
// Parse each @Configuration class
ConfigurationClassParser parser = new ConfigurationClassParser(
this.metadataReaderFactory, this.problemReporter, this.environment,
this.resourceLoader, this.componentScanBeanNameGenerator, registry); Set<BeanDefinitionHolder> candidates = new LinkedHashSet<>(configCandidates);
Set<ConfigurationClass> alreadyParsed = new HashSet<>(configCandidates.size());
do {
StartupStep processConfig = this.applicationStartup.start("spring.context.config-classes.parse");
//所有bean的定义的查找都是在这里完成的。下面我们去看看这里的parse方法
parser.parse(candidates);
......
}

ConfigurationClassParser中的parse方法中,由于我们的配置类是通过注解来定义的,所以会走AnnotatedBeanDefinition这个分支。继续会调用到processConfigurationClass(new ConfigurationClass(metadata, beanName), DEFAULT_EXCLUSION_FILTER);这句,我们就直接进到这个processConfigurationClass方法去看吧。

protected void processConfigurationClass(ConfigurationClass configClass, Predicate<String> filter) throws IOException {
//在这里首先看配置类上是否有Conditional注解,如果有的话,就去解析处理,看看是否要跳过这个注解类
if (this.conditionEvaluator.shouldSkip(configClass.getMetadata(), ConfigurationPhase.PARSE_CONFIGURATION)) {
return;
} //所有解析出来的配置类都要放置到configurationClasses中,key是当前解析出来的配置类,value就是表示这个配置类是通过谁来导入的。
//如果这个配置类不是通过别的类来导入的,这时key和value就是一样的。
ConfigurationClass existingClass = this.configurationClasses.get(configClass);
//如果通过多个配置类导入了同一个配置类,那么把这个和配置类的导入关系就要进行一下合并
if (existingClass != null) {
if (configClass.isImported()) {
if (existingClass.isImported()) {
existingClass.mergeImportedBy(configClass);
}
// Otherwise ignore new imported config class; existing non-imported class overrides it.
return;
}
else {
// Explicit bean definition found, probably replacing an import.
// Let's remove the old one and go with the new one.
this.configurationClasses.remove(configClass);
this.knownSuperclasses.values().removeIf(configClass::equals);
}
} // Recursively process the configuration class and its superclass hierarchy.
//这里是将配置类转化为SourceClass对象
SourceClass sourceClass = asSourceClass(configClass, filter);
do {
//在这里就会进行真正的配置类的解析出来。 //注意这里是个do-while循环,处理完当前的配置类,会继续去处理当前配置类的父类。
//如果当前类的父类类名不是java开头,且没有被处理过的话,就会在这个do-while循环中继续去处理 sourceClass = doProcessConfigurationClass(configClass, sourceClass, filter);
}
while (sourceClass != null); this.configurationClasses.put(configClass, configClass);
}

this.conditionEvaluator.shouldSkip(configClass.getMetadata(), ConfigurationPhase.PARSE_CONFIGURATION)这个的过滤主要是通过org.springframework.context.annotation.Condition接口的子类去实现matches方法完成的。

举个例子简单说下:

@Configuration(proxyBeanMethods = false)
@ConditionalOnMissingBean(name = AbstractApplicationContext.MESSAGE_SOURCE_BEAN_NAME, search = SearchStrategy.CURRENT)
@AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE)
@Conditional(ResourceBundleCondition.class)
@EnableConfigurationProperties
public class MessageSourceAutoConfiguration

上面是MessageSourceAutoConfiguration类的定义,首先会查找它上面的Conditional注解,会找到两个注解:

  • @ConditionalOnMissingBean(name = AbstractApplicationContext.MESSAGE_SOURCE_BEAN_NAME, search = SearchStrategy.CURRENT)

    由于这个这个注解上面有@Conditional(OnBeanCondition.class),所以会交给OnBeanCondition这个类去处理。

  • @Conditional(ResourceBundleCondition.class),则会交给ResourceBundleCondition这个类去处理。


processConfigurationClass这个方法会有多个地方,主要会出现在三个地方:

  1. 就是调用parse方法的时候会调用到这个processConfigurationClass方法。
  2. doProcessConfigurationClass中解析当前配置类的属性时也可能会多次调用到processConfigurationClass方法。
  3. this.deferredImportSelectorHandler.process()调用时也可能会调用到processConfigurationClass方法

我们这里解析的所有配置类都添加到都会调用到configurationClasses.put(configClass, configClass)方法,所以我们最终有多个类添加到configurationClasses集合中,就至少有多少次调用到processConfigurationClass方法(有Conditional注解的判断,所以调用次数可能多于最终添加到configurationClasses集合中元素个数)


	@Nullable
protected final SourceClass doProcessConfigurationClass(
ConfigurationClass configClass, SourceClass sourceClass, Predicate<String> filter)
throws IOException {
//在这里,查看类是否有Component注解,有的话,查找当前类的内部类,进行处理
if (configClass.getMetadata().isAnnotated(Component.class.getName())) {
// Recursively process any member (nested) classes first
//这里就可能会递归调用到上面的processConfigurationClass方法
processMemberClasses(configClass, sourceClass, filter);
} // Process any @PropertySource annotations
//在这里,查看类是否有PropertySources注解,有的话去解析属性配置,添加到环境上下文中去
for (AnnotationAttributes propertySource : AnnotationConfigUtils.attributesForRepeatable(
sourceClass.getMetadata(), PropertySources.class,
org.springframework.context.annotation.PropertySource.class)) {
if (this.environment instanceof ConfigurableEnvironment) {
processPropertySource(propertySource);
}
else {
logger.info("Ignoring @PropertySource annotation on [" + sourceClass.getMetadata().getClassName() +
"]. Reason: Environment must implement ConfigurableEnvironment");
}
} // Process any @ComponentScan annotations
//在这里,查看类是否有ComponentScans注解,有的话,就根据这里的条件去进行目录扫描,查找bean的定义
//由于我们当前的类上有SpringBootApplication注解,所以这里是能够找到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
//在这里,就会去处理ComponentScans注解相关的内容。
//ComponentScans注解上有个basePackages属性,用来指定扫描的包的名字。
//如果没有指定basePackages属性,就在当前类的包下及其所有子包下去查找相关的bean的定义。
//我们一般不会指定basePackages属性,那么会在当前sourceClass类的包及其所有子包下去查找bean的定义。
//我们自己代码中定义的controller,service,dao等等都是在这一步获取到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
for (BeanDefinitionHolder holder : scannedBeanDefinitions) {
BeanDefinition bdCand = holder.getBeanDefinition().getOriginatingBeanDefinition();
if (bdCand == null) {
bdCand = holder.getBeanDefinition();
}
if (ConfigurationClassUtils.checkConfigurationClassCandidate(bdCand, this.metadataReaderFactory)) {
//这里也会间接调用到processConfigurationClass方法
parse(bdCand.getBeanClassName(), holder.getBeanName());
}
}
}
} // Process any @Import annotations
//在这里,就会去处理类上的import注解。 //getImports(sourceClass)首先会获取到import的类。
//这里会有两个,一个是AutoConfigurationPackage上注解的AutoConfigurationPackages.Registrar.class
//另一个是EnableAutoConfiguration上的注解AutoConfigurationImportSelector.class) //下面我们去看看processImports这个方法
//这里面也可能会调用到processConfigurationClass方法
processImports(configClass, sourceClass, getImports(sourceClass), filter, true);
......
}

doProcessConfigurationClass是真正用来处理配置类的。

在这个方法中会依次处理内部类、PropertySources注解、ComponentScans注解、Import注解、ImportResource注解、Bean注解、接口上的默认方法、继续递归到它的父类。

其中:

  • 内部类会继续调用processConfigurationClass方法递归去处理

  • PropertySources注解解析后添加到环境上下文中

  • ComponentScans注解扫描到的到的类会直接被添加到beanFactory中,也会继续调用processConfigurationClass方法递归去处理

  • Import注解会分3种情况处理:

    • Import的类如果实现了ImportSelector。且实现了它的子接口DeferredImportSelector,则会添加到deferredImportSelectors中,后续进行处理。如果没有实现子接口,就递归调用processImports进行处理。
    • Import的类如果实现了ImportBeanDefinitionRegistrar。则添加到当前配置类的属性中,进行后续处理。
    • 不属于上面两种情况的话,就继续递归调用processConfigurationClass进行处理。
  • ImportResource注解、Bean注解、接口上的默认方法这些都会解析后添加到当前配置类的属性上,后续进行处理


对下面方法的几个入参简单描述下:

  • configClasscurrentSourceClass这两个参数直接都是指代我们包含SpringBootApplication注解的主类。

    其中configClass表示当前处理的类是被谁导入的,currentSourceClass表示当前正在处理的类。这两者一般底层是同一个资源类,但是有可能会有递归调用,这时两者就可能会不同。

  • importCandidates是通过import注解导入的类,这里是AutoConfigurationPackages.Registrar.classAutoConfigurationImportSelector.class

    importCandidates就是当前被导入的类,也就是在这里被处理的类

  • exclusionFilter是在ConfigurationClassParser中定义的,用来过滤java.lang.annotation.org.springframework.stereotype.开头的注解

  • checkForCircularImports表示是否检查递归导入

private void processImports(ConfigurationClass configClass, SourceClass currentSourceClass,
Collection<SourceClass> importCandidates, Predicate<String> exclusionFilter,
boolean checkForCircularImports) { if (importCandidates.isEmpty()) {
return;
}
//这里是错误检查,检查是否出现了递归
if (checkForCircularImports && isChainedImportOnStack(configClass)) {
this.problemReporter.error(new CircularImportProblem(configClass, this.importStack));
}
else {
//先将当前的配置类压入栈
this.importStack.push(configClass);
try {
//这里,就会对import标签导入的类进行处理
for (SourceClass candidate : importCandidates) { //AutoConfigurationImportSelector.class类就会走下面的分支
if (candidate.isAssignable(ImportSelector.class)) {
// Candidate class is an ImportSelector -> delegate to it to determine imports
Class<?> candidateClass = candidate.loadClass();
//首先在这里创建一个AutoConfigurationImportSelector类的对象,
ImportSelector selector = ParserStrategyUtils.instantiateClass(candidateClass, ImportSelector.class,
this.environment, this.resourceLoader, this.registry);
Predicate<String> selectorFilter = selector.getExclusionFilter();
if (selectorFilter != null) {
exclusionFilter = exclusionFilter.or(selectorFilter);
}
if (selector instanceof DeferredImportSelector) {
//在这里,将当前的配置类和AutoConfigurationImportSelector的对象封装成DeferredImportSelectorHolder对象
//添加到延迟导入的集合deferredImportSelectors中
this.deferredImportSelectorHandler.handle(configClass, (DeferredImportSelector) selector);
}
else {
String[] importClassNames = selector.selectImports(currentSourceClass.getMetadata());
Collection<SourceClass> importSourceClasses = asSourceClasses(importClassNames, exclusionFilter);
processImports(configClass, currentSourceClass, importSourceClasses, exclusionFilter, false);
}
}
//AutoConfigurationPackages.Registrar.class这个类就会走到这个分支中
//在这个分支中,首先创建AutoConfigurationPackages.Registrar的对象
//添加到当前配置类的importBeanDefinitionRegistrars属性中去
else if (candidate.isAssignable(ImportBeanDefinitionRegistrar.class)) {
// Candidate class is an ImportBeanDefinitionRegistrar ->
// delegate to it to register additional bean definitions
Class<?> candidateClass = candidate.loadClass();
ImportBeanDefinitionRegistrar registrar =
ParserStrategyUtils.instantiateClass(candidateClass, ImportBeanDefinitionRegistrar.class,
this.environment, this.resourceLoader, this.registry);
configClass.addImportBeanDefinitionRegistrar(registrar, currentSourceClass.getMetadata());
}
else {
// Candidate class not an ImportSelector or ImportBeanDefinitionRegistrar ->
// process it as an @Configuration class
this.importStack.registerImport(
currentSourceClass.getMetadata(), candidate.getMetadata().getClassName());
processConfigurationClass(candidate.asConfigClass(configClass), exclusionFilter);
}
}
}
catch (BeanDefinitionStoreException ex) {
throw ex;
}
catch (Throwable ex) {
throw new BeanDefinitionStoreException(
"Failed to process import candidates for configuration class [" +
configClass.getMetadata().getClassName() + "]", ex);
}
finally {
this.importStack.pop();
}
}
}

上面的import导入类处理完了,下面我们继续回到doProcessConfigurationClass中去看剩余的部分

	@Nullable
protected final SourceClass doProcessConfigurationClass(
ConfigurationClass configClass, SourceClass sourceClass, Predicate<String> filter)
throws IOException { ......//这部分前面已经分析过了,我们就继续看后面的吧 // Process any @ImportResource annotations
// 这里是处理ImportResource注解
AnnotationAttributes importResource =
AnnotationConfigUtils.attributesFor(sourceClass.getMetadata(), ImportResource.class);
if (importResource != null) {
String[] resources = importResource.getStringArray("locations");
Class<? extends BeanDefinitionReader> readerClass = importResource.getClass("reader");
for (String resource : resources) {
String resolvedResource = this.environment.resolveRequiredPlaceholders(resource);
configClass.addImportedResource(resolvedResource, readerClass);
}
} // Process individual @Bean methods
//这里是处理配置类内部的有Bean注解的方法,添加到配置类的beanMethods属性中
Set<MethodMetadata> beanMethods = retrieveBeanMethodMetadata(sourceClass);
for (MethodMetadata methodMetadata : beanMethods) {
configClass.addBeanMethod(new BeanMethod(methodMetadata, configClass));
} // Process default methods on interfaces
//这里处理配置类实现的接口上默认方法上有Bean注解的话,也添加到beanMethods属性中
processInterfaces(configClass, sourceClass); // Process superclass, if any //这里去获取配置类的父类,如果存在父类且父类类名不是java开头且还没有被处理过,就会返回父类,继续进行父类的处理。
if (sourceClass.getMetadata().hasSuperClass()) {
String superclass = sourceClass.getMetadata().getSuperClassName();
if (superclass != null && !superclass.startsWith("java") &&
!this.knownSuperclasses.containsKey(superclass)) {
this.knownSuperclasses.put(superclass, configClass);
// Superclass found, return its annotation metadata and recurse
return sourceClass.getSuperClass();
}
} // No superclass -> processing is complete
return null;
}

到这里processConfigurationClass方法就整个分析完了。

下面就会走到parse方法的最后一句了。我们进去看看

public void parse(Set<BeanDefinitionHolder> configCandidates) {
......
//就会走到下面这行代码
this.deferredImportSelectorHandler.process();
}

这里主要是对延迟导入的类进行处理

		public void process() {

			//在上面代码中我们分析到this.deferredImportSelectors中只有一个
//由前面的配置类和AutoConfigurationImportSelector类的对象封装的DeferredImportSelectorHolder对象
List<DeferredImportSelectorHolder> deferredImports = this.deferredImportSelectors;
this.deferredImportSelectors = null;
try {
if (deferredImports != null) {
DeferredImportSelectorGroupingHandler handler = new DeferredImportSelectorGroupingHandler();
deferredImports.sort(DEFERRED_IMPORT_COMPARATOR);
//这里会对延迟导入的类进行分组,添加到handler中,由于我们这里只有一个对象,所以这块的分组,我们可以不用太关注
//同时会将前面的配置类添加到handler对象的configurationClasses属性中
deferredImports.forEach(handler::register);
//下面就会交给handler去进行处理
handler.processGroupImports();
}
}
finally {
this.deferredImportSelectors = new ArrayList<>();
}
}
}

下面我们看看processGroupImports是如何处理的

public void processGroupImports() {
//这里就按分组去处理了
for (DeferredImportSelectorGrouping grouping : this.groupings.values()) {
Predicate<String> exclusionFilter = grouping.getCandidateFilter();
//这里的grouping.getImports()就回去获取系统的配置类,我们下面去看这个getImports
grouping.getImports().forEach(entry -> {
......
}
}

这里的grouping.getCandidateFilter()来自两部分:

  • 另一部分是来自ConfigurationClassParser定义的lambda表达式


这个是在ConfigurationClassParser类的一个静态内部类DeferredImportSelectorGrouping中的方法

		public Iterable<Group.Entry> getImports() {
//这里的deferredImports中只有一个对象,还是之前的DeferredImportSelectorHolder
for (DeferredImportSelectorHolder deferredImport : this.deferredImports) {
//这里的this.group就是之前分组的deferredImport.getImportSelector().getImportGroup();方法的返回值创建的对象
//具体就是AutoConfigurationImportSelector.AutoConfigurationGroup的对象
//下面我们先看看这个process方法
this.group.process(deferredImport.getConfigurationClass().getMetadata(),
deferredImport.getImportSelector());
}
return this.group.selectImports();
}

process是在AutoConfigurationImportSelector.AutoConfigurationGroup这个类中

		public void process(AnnotationMetadata annotationMetadata, DeferredImportSelector deferredImportSelector) {
Assert.state(deferredImportSelector instanceof AutoConfigurationImportSelector,
() -> String.format("Only %s implementations are supported, got %s",
AutoConfigurationImportSelector.class.getSimpleName(),
deferredImportSelector.getClass().getName()));
//下面这行代码也比较重要,我们进去看看
AutoConfigurationEntry autoConfigurationEntry = ((AutoConfigurationImportSelector) deferredImportSelector)
.getAutoConfigurationEntry(annotationMetadata);
this.autoConfigurationEntries.add(autoConfigurationEntry);
for (String importClassName : autoConfigurationEntry.getConfigurations()) {
this.entries.putIfAbsent(importClassName, annotationMetadata);
}
}
	protected AutoConfigurationEntry getAutoConfigurationEntry(AnnotationMetadata annotationMetadata) {
//这里,我们就能看到设置spring.boot.enableautoconfiguration属性去禁止导入系统配置的bean的定义
if (!isEnabled(annotationMetadata)) {
return EMPTY_ENTRY;
} AnnotationAttributes attributes = getAttributes(annotationMetadata);
//在下面这行中,就能看到通过ClassLoader去加载META-INF/spring.factories文件,读取内容。放置到cache中
//在当前这里,会去获取key=org.springframework.boot.autoconfigure.EnableAutoConfiguration的所有属性配置
List<String> configurations = getCandidateConfigurations(annotationMetadata, attributes);
configurations = removeDuplicates(configurations);
Set<String> exclusions = getExclusions(annotationMetadata, attributes);
checkExcludedClasses(configurations, exclusions);
configurations.removeAll(exclusions);
//在这里获取配置过滤类并创建对象,对上面的configuras进行过滤
//这里的配置过滤类也是从cache中获取,key=org.springframework.boot.autoconfigure.AutoConfigurationImportFilter
configurations = getConfigurationClassFilter().filter(configurations);
//这行代码不关键,我们可以不用去关注
fireAutoConfigurationImportEvents(configurations, exclusions);
//这里返回一个AutoConfigurationEntry对象
//其中configurations是过滤器能够匹配到的配置类,exclusions在我们这里是空的
return new AutoConfigurationEntry(configurations, exclusions);
}

上面代码中getConfigurationClassFilter()获取到的是:

是来自spring.factories文件中的org.springframework.boot.autoconfigure.AutoConfigurationImportFilter

  • org.springframework.boot.autoconfigure.condition.OnClassCondition

    这个类主要检查是否存在指定的类

  • org.springframework.boot.autoconfigure.condition.OnWebApplicationCondition

    这个类主要检查是否存在WebApplicationContext.

  • org.springframework.boot.autoconfigure.condition.OnBeanCondition

    这个类主要检查是否存在指定的bean

在这个过程中,在生成filter过程中,首先会通过类加载器去读取META-INF/spring-autoconfigure-metadata.properties这些文件。

在这里,主要是通过类名.ConditionalOnBean类名.ConditionalOnSingleCandidate类名.ConditionalOnClass类名.ConditionalOnWebApplication来过滤掉不符合的配置类。

具体的算法入口都在这3个类的父类FilteringSpringBootConditionmatch方法,具体的实现入口分别在这3个类的getOutcomes方法中。

由于这3个类都是实现了Condition接口,因此前面分析的 processConfigurationClass方法开始的地方通过 Conditional注解过滤配置类也会用到这3个类。

从上面也可以看出springboot的按需加载主要也是通过实现Condition接口来完成的。


再回到process这个方法。

		public void process(AnnotationMetadata annotationMetadata, DeferredImportSelector deferredImportSelector) {
......//上面的代码刚才已经分析过了
//在这里将上面返回的AutoConfigurationEntry对象添加到autoConfigurationEntries中
this.autoConfigurationEntries.add(autoConfigurationEntry); for (String importClassName : autoConfigurationEntry.getConfigurations()) {
//分别将添加的配置类添加到entries这个属性中
//importClassName是新查找到的配置类,annotationMetadata都是同一个就是我们的主类
this.entries.putIfAbsent(importClassName, annotationMetadata);
}
}

在接下来的selectImports方法中,首先会对这些新添加的配置类进行排序,然后组装成new Entry(this.entries.get(importClassName), importClassName))对象的集合。

这里需要注意的是this.entries.get(importClassName)这就是我们的主类,importClassName是我们需要添加的配置类。

这里主要是为了对当前导入的配置类和它是被谁导入的进行一个关联(在这里,所有要导入的配置类都是由我们的主类来导入的)。

就是在后面创建ConfigurationClass对象时会使用public ConfigurationClass(MetadataReader metadataReader, @Nullable ConfigurationClass importedBy)这个构造方法。

最后在添加这些配置类到beanFactory中时通过


下面再回到processGroupImports方法

	public void processGroupImports() {
for (DeferredImportSelectorGrouping grouping : this.groupings.values()) {
Predicate<String> exclusionFilter = grouping.getCandidateFilter();
//上面已经分析到grouping.getImports()返回的是Entry对象的集合
grouping.getImports().forEach(entry -> {
//entry.getMetadata()返回的还是我们之前的主类。
//这里的configurationClass也是我们之前的主类。
//这个主要是为了在processImports方法中创建的配置类为它们设置importedBy属性
ConfigurationClass configurationClass = this.configurationClasses.get(entry.getMetadata());
try {
//这里又会调用到processImports这个方法。这个在前面已经分析过了,但是这里有一点不一样,下面我们看看不一样的地方
processImports(configurationClass, asSourceClass(configurationClass, exclusionFilter),
Collections.singleton(asSourceClass(entry.getImportClassName(), exclusionFilter)),
exclusionFilter, false);
}
catch (BeanDefinitionStoreException ex) {
throw ex;
}
catch (Throwable ex) {
throw new BeanDefinitionStoreException(
"Failed to process import candidates for configuration class [" +
configurationClass.getMetadata().getClassName() + "]", ex);
}
});
}
}

关于这个processImports方法的参数前面有描述,这里就不再说了

下面的这个方法中这时importCandidates和之前的有点不一样,之前的是通过import注解导入的分别会走for循环的前面两个分支,现在大概率会走到后面的else分支


private void processImports(ConfigurationClass configClass, SourceClass currentSourceClass,
Collection<SourceClass> importCandidates, Predicate<String> exclusionFilter,
boolean checkForCircularImports) { this.importStack.push(configClass);
try {
for (SourceClass candidate : importCandidates) {
if (candidate.isAssignable(ImportSelector.class)) {
......
}
else if (candidate.isAssignable(ImportBeanDefinitionRegistrar.class)) {
......
}
else { // Candidate class not an ImportSelector or ImportBeanDefinitionRegistrar ->
// process it as an @Configuration class
//上次进入这个方法,分别走了上面的两个分支,现在大概率会走到这个分支
//这里会将导入的类添加到imports属性中,key是新导入的配置类,value是我们之前的主类
this.importStack.registerImport(
currentSourceClass.getMetadata(), candidate.getMetadata().getClassName());
//这里又会去处理新添加的配置类,在这里是有可能出现递归的,下面我们具体分析下这里的处理逻辑
processConfigurationClass(candidate.asConfigClass(configClass), exclusionFilter);
}
}
}
......
}
}

在上面的processImports方法中,会处理新添加的配置类,会调用到processConfigurationClass这个方法。


到上面为止,ConfigurationClassPostProcessorprocessConfigBeanDefinitions方法从parse处理的部分就全部分析完了 。

这部分主要是处理了通过主类上面的注解,将所有的配置类都添加到ConfigurationClassParser类的成员变量configurationClasses中。对于配置类上的ImportResourceBean等等则添加配置类的对应的属性上。

这里需要注意的是在整个整个过程中只有ComponentScans扫描到的配置类会添加到beanFactory中。

下面我们继续看看后面的代码。

	public void processConfigBeanDefinitions(BeanDefinitionRegistry registry) {
......
do {
StartupStep processConfig = this.applicationStartup.start("spring.context.config-classes.parse");
parser.parse(candidates);//前面已经分析到了这里
parser.validate(); //这里就会得到所有的配置类
Set<ConfigurationClass> configClasses = new LinkedHashSet<>(parser.getConfigurationClasses());
//alreadyParsed第一次是空的,由于这个方法是do-while循环,在后面会对这个变量赋值
configClasses.removeAll(alreadyParsed); // Read the model and create bean definitions based on its content
if (this.reader == null) {
this.reader = new ConfigurationClassBeanDefinitionReader(
registry, this.sourceExtractor, this.resourceLoader, this.environment,
this.importBeanNameGenerator, parser.getImportRegistry());
}
//在这里就会对前面获取的所有的配置类添加到beanFactory中
this.reader.loadBeanDefinitions(configClasses);
alreadyParsed.addAll(configClasses);
processConfig.tag("classCount", () -> String.valueOf(configClasses.size())).end(); candidates.clear();
//这里就是对比前后beanFactory中的beanDefinition数量是否有增加,如果有增加说明我们在本次do-while代码中添加了beanFactory
//下面的逻辑主要是为了判断当前扫描出来的配置类是否全部添加进了beanFactory中,如果有配置类还没有被今天进去,就会循环,重新执行上面的逻辑
if (registry.getBeanDefinitionCount() > candidateNames.length) {
String[] newCandidateNames = registry.getBeanDefinitionNames();
Set<String> oldCandidateNames = new HashSet<>(Arrays.asList(candidateNames));
Set<String> alreadyParsedClasses = new HashSet<>();
for (ConfigurationClass configurationClass : alreadyParsed) {
alreadyParsedClasses.add(configurationClass.getMetadata().getClassName());
}
for (String candidateName : newCandidateNames) {
if (!oldCandidateNames.contains(candidateName)) {
BeanDefinition bd = registry.getBeanDefinition(candidateName);
if (ConfigurationClassUtils.checkConfigurationClassCandidate(bd, this.metadataReaderFactory) &&
!alreadyParsedClasses.contains(bd.getBeanClassName())) {
candidates.add(new BeanDefinitionHolder(bd, candidateName));
}
}
}
candidateNames = newCandidateNames;
}
}
while (!candidates.isEmpty()); // Register the ImportRegistry as a bean in order to support ImportAware @Configuration classes
if (sbr != null && !sbr.containsSingleton(IMPORT_REGISTRY_BEAN_NAME)) {
sbr.registerSingleton(IMPORT_REGISTRY_BEAN_NAME, parser.getImportRegistry());
} if (this.metadataReaderFactory instanceof CachingMetadataReaderFactory) {
// Clear cache in externally provided MetadataReaderFactory; this is a no-op
// for a shared cache since it'll be cleared by the ApplicationContext.
((CachingMetadataReaderFactory) this.metadataReaderFactory).clearCache();
}
}

上面的其他代码都比较简单,我们下面主要对上面的this.reader.loadBeanDefinitions(configClasses);做个简单分析吧。


ConfigurationClassBeanDefinitionReader的方法

	public void loadBeanDefinitions(Set<ConfigurationClass> configurationModel) {

		//这个类还是用来对Conditional注解进行处理,来判断当前配置类是否要被过滤掉
TrackedConditionEvaluator trackedConditionEvaluator = new TrackedConditionEvaluator();
for (ConfigurationClass configClass : configurationModel) {
//在这里会对每个配置类及它的属性进行处理,封装成beanDefinition添加到beanFactory中去
loadBeanDefinitionsForConfigurationClass(configClass, trackedConditionEvaluator);
}
}
	private void loadBeanDefinitionsForConfigurationClass(
ConfigurationClass configClass, TrackedConditionEvaluator trackedConditionEvaluator) { //这里就会对Conditional注解进行判断,如果当前类是被导入的,就会去判断导入它的类
if (trackedConditionEvaluator.shouldSkip(configClass)) {
String beanName = configClass.getBeanName();
if (StringUtils.hasLength(beanName) && this.registry.containsBeanDefinition(beanName)) {
this.registry.removeBeanDefinition(beanName);
}
this.importRegistry.removeImportingClass(configClass.getMetadata().getClassName());
return;
}
//如果类是被导入的,就会去对它进行处理
if (configClass.isImported()) {
registerBeanDefinitionForImportedConfigurationClass(configClass);
}
//下面就是对配置类的各种属性进行处理
//处理方法上的bean注解
for (BeanMethod beanMethod : configClass.getBeanMethods()) {
loadBeanDefinitionsForBeanMethod(beanMethod);
}
//处理导入的资源
loadBeanDefinitionsFromImportedResources(configClass.getImportedResources());
//处理导入的ImportBeanDefinitionRegistrar
loadBeanDefinitionsFromRegistrars(configClass.getImportBeanDefinitionRegistrars());
}

在上面的代码也可以看到,单纯的配置类,如果configClass.isImported()返回false,就不会被添加到beanFactory中。也就是如果配置类不是被导入的,就不会将配置类添加到beanFactory中。

前面说过ComponentScans扫描到的类在处理过程中就被添加到了beanFactory中,其他的配置类都是在上面的方法中被添加进去的。

所有添加的类大致可以分为两部分:

  1. 通过类上的注解,直接被添加到配置类中。这部分配置类它们的被导入类就是当前的主类。
  2. 另一部分是通过主类上的@Import(AutoConfigurationImportSelector.class)注解,读取META-INF/spring.factories文件,经过META-INF/spring-autoconfigure-metadata.properties文件过滤后被处理的类。

上面两部分处理的时候都会进行递归,一层一层处理。而且所有的处理过程中也都会根据 Conditional注解进行过滤。

同时也需要注意虽然添加到beanFactory中的都是beanD,但是具体都是不一样的。比如:

ScannedGenericBeanDefinition是通过ComponentScans注解添加的

ConfigurationClassBeanDefinition是处理方法上的bean注解添加的

AnnotatedGenericBeanDefinition是其他普通的配置类


到上面,整个分析就结束了。

整个过程涉及到的各种递归调用等等都比较多,为了不至于文章显的太分散,上面分析过程中对很多细节也都进行了省略。

由于个人能力问题,上面的分析可能存在错误或者描述不清晰的地方,欢迎大家评论指正。

springboot自动扫描添加的BeanDefinition源码解析的更多相关文章

  1. 深度理解springboot集成cache缓存之源码解析

    一.案例准备 1.创建数据表(employee表) 2.创建Employee实体类封装数据库中的数据 @AllArgsConstructor @NoArgsConstructor @Data @ToS ...

  2. Springboot集成RabbitMQ之MessageConvert源码解析

    问题 最近在使用RabbitMq时遇到了一个问题,明明是转换成json发送到mq中的数据,消费者接收到的却是一串数字也就是byte数组,但是使用mq可视化页面查看数据却是正常的,之前在使用过程中从未遇 ...

  3. SpringBoot(1.5.6.RELEASE)源码解析

    转自 https://www.cnblogs.com/dylan-java/p/7450914.html 启动SpringBoot,需要在入口函数所在的类上添加@SpringBootApplicati ...

  4. Spring组件BeanDefinition 源码解析

    BeanDefinition 继承图 继承的接口 BeanMetadataElement接口 将由承载配置源对象的bean元数据元素的类实现. 包含一个getSource的方法,可以获取到MetaDa ...

  5. springboot ---> spring ioc 注册流程 源码解析 this.prepareContext 部分

    现在都是在springboot 中 集成 spirng,那我们就从springboot 开始. 一:springboot 启动main 函数 public static void main(Strin ...

  6. BeanDefinition源码解析

    我们知道BeanDefintion定义了Bean在IoC容器内的基本数据结构.在学习IoC之前先了解BeanDefition对我们理解IoC容器是有帮助的. 首先BeanDefinition是一个接口 ...

  7. 26. SpringBoot 初识缓存及 SimpleCacheConfiguration源码解析

    1.引入一下starter: web.cache.Mybatis.MySQL @MapperScan("com.everjiankang.cache.dao") @SpringBo ...

  8. springboot源码解析-管中窥豹系列之BeanDefinition(八)

    一.前言 Springboot源码解析是一件大工程,逐行逐句的去研究代码,会很枯燥,也不容易坚持下去. 我们不追求大而全,而是试着每次去研究一个小知识点,最终聚沙成塔,这就是我们的springboot ...

  9. SpringBoot 源码解析 (九)----- Spring Boot的核心能力 - 整合Mybatis

    本篇我们在SpringBoot中整合Mybatis这个orm框架,毕竟分析一下其自动配置的源码,我们先来回顾一下以前Spring中是如何整合Mybatis的,大家可以看看我这篇文章Mybaits 源码 ...

随机推荐

  1. 【IntelliJ IDEA】代码模板

    psvm:main方法 sout:console输出 iter:foreach遍历 fori:for索引遍历

  2. 微信小程序组建通信

    子组件传递父组件需要用到triggerEvent方法,当子组件(自定义组件)点击button的时候调用triggerEvent方法传递一些数据,首先第一个属性为自定义名称(myevent)对应父组件( ...

  3. 编写Hive的UDF(查询平台数据同时向mysql添加数据)

    注:图片如果损坏,点击文章链接:https://www.toutiao.com/i6812629187518530052/ 可能会有一些截图中会有错误提示,是因为本地的包一直包下载有问题,截完图已经下 ...

  4. 智能集成接口:I3 ISA-95 的应用

    介绍 多年来,使用基于制造运营管理 (MOM) 的应用程序的制造 IT 顾问试图说服制造商这些类型的应用的高价值.实时 MOM 解决方案是唯一一组能够精确优化工厂日常运营的 IT 应用程序,可为其可用 ...

  5. Android官方文档翻译 十六 4.Managing the Activity Lifecycle

    Managing the Activity Lifecycle 管理activity的生命周期 Dependencies and prerequisites 依赖关系和先决条件 How to crea ...

  6. 12.25 补充总结-jsp标签

    注:标签引用时,需在jsp 头部添加如下语句 <%@taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c ...

  7. (3)ESP32 Python 制作一个办公室温度计

    因为经常在办公室里面不知道实际室内温度是多少,所以用ESP32做了一个工具来进行温度&湿度的监测.在之前的文章当中,已经完成了ESP32的数据上云工作,如果要进行温度/湿度的检测.从原理上就是 ...

  8. [源码分析] Facebook如何训练超大模型 --- (3)

    [源码分析] Facebook如何训练超大模型 --- (3) 目录 [源码分析] Facebook如何训练超大模型 --- (3) 0x00 摘要 0x01 ZeRO-Offload 1.1 设计原 ...

  9. Postman 支持 gRPC 了!继续领先 ~

    最近国产API管理工具比较热,几款产品在API管理层面做得也都还不错,但主要还是对HTTP相关的API管理,毕竟这类API的应用目前还是最为广泛的.但显然,还有不少其他应用场景目前没有覆盖到,DD在之 ...

  10. elasticsearch算法之推荐系统的相似度算法(一)

    一.推荐系统简介 推荐系统主要基于对用户历史的行为数据分析处理,寻找得到用户可能感兴趣的内容,从而实现主动向用户推荐其可能感兴趣的内容: 从物品的长尾理论来看,推荐系统通过发掘用户的行为,找到用户的个 ...