SpringBoot 源码分析 - 自动配置深度分析四
refresh和自动配置大致流程
AutoConfigurationGroup的getAutoConfigurationMetadata加载自动配置元数据
差点把这个细节忘记了,不好意思啊,这个要说下,不然后面说到怎么进行条件过滤的会不知道数据怎么来匹配的。
private AutoConfigurationMetadata getAutoConfigurationMetadata() {
if (this.autoConfigurationMetadata == null) {
this.autoConfigurationMetadata = AutoConfigurationMetadataLoader.loadMetadata(this.beanClassLoader);
}
return this.autoConfigurationMetadata;
}
原来还有一个加载的文件 META-INF/spring-autoconfigure-metadata.properties
:
这里加载的就是自动配置类上的条件类,也就是说过滤的时候会判断这些类是否存在或者不存在才能加载
比如说JdbcTemplateAutoConfiguration
,上面的ConditionalOnClass
注解表示需要有这两个类才能加载。
这个信息就配置在META-INF/spring-autoconfigure-metadata.properties
里,其实是为了方便后面的加载判断,直接写全限定名方便尝试加载:
org.springframework.boot.autoconfigure.jdbc.JdbcTemplateAutoConfiguration.ConditionalOnClass=javax.sql.DataSource,org.springframework.jdbc.core.JdbcTemplate
还有比如ConditionalOnSingleCandidate
注解:
org.springframework.boot.autoconfigure.jdbc.JdbcTemplateAutoConfiguration.ConditionalOnSingleCandidate=javax.sql.DataSource
所以总共属性有 486
个,超过配置类个数,每个都有过滤条件,可能还有好几个条件。
好了,这里铺垫好了,就可以继续讲过滤了。
FilteringSpringBootCondition的match过滤器匹配
过滤器有三个
每一个都会去匹配那么多配置类,所以他开了线程,看这个红色框的方法。
OnClassCondition的getOutcomes
如果是多核的话,就开启一个线程处理。
@Order(Ordered.HIGHEST_PRECEDENCE)
class OnClassCondition extends FilteringSpringBootCondition {
//根据给定的配置类元数据及配置类集合判定配置类是否符合条件
@Override
protected final ConditionOutcome[] getOutcomes(String[] autoConfigurationClasses,
AutoConfigurationMetadata autoConfigurationMetadata) {
// 如果有多个处理器可用,则将工作拆分并在后台线程中执行一半,使用一个额外的线程似乎可以童工最好的性能。
// 线程越多,并不见得性能会更好,可能会更糟糕
if (autoConfigurationClasses.length > 1 && Runtime.getRuntime().availableProcessors() > 1) {
//如果配置类有多个,并且有多个处理器,则选择拆分处理的方法
return resolveOutcomesThreaded(autoConfigurationClasses, autoConfigurationMetadata);
}
else {
//如果只有一个配置类,则使用StandardOutcomesResolver解析类对配置类进行处理
OutcomesResolver outcomesResolver = new StandardOutcomesResolver(autoConfigurationClasses, 0,
autoConfigurationClasses.length, autoConfigurationMetadata, getBeanClassLoader());
return outcomesResolver.resolveOutcomes();
}
}
//如果配置类有多个,并且有多个处理器,则选择拆分处理的方法
private ConditionOutcome[] resolveOutcomesThreaded(String[] autoConfigurationClasses,
AutoConfigurationMetadata autoConfigurationMetadata) {
//获取配置类一半的数量
int split = autoConfigurationClasses.length / 2;
//创建线程解析器解析第一部分配置类
OutcomesResolver firstHalfResolver = createOutcomesResolver(autoConfigurationClasses, 0, split,
autoConfigurationMetadata);
//创建标准的解析器解析第二部分配置类
OutcomesResolver secondHalfResolver = new StandardOutcomesResolver(autoConfigurationClasses, split,
autoConfigurationClasses.length, autoConfigurationMetadata, getBeanClassLoader());
//使用标准解析器解析第二部分配置类
ConditionOutcome[] secondHalf = secondHalfResolver.resolveOutcomes();
//使用线程解析器解析第一部分配置类
ConditionOutcome[] firstHalf = firstHalfResolver.resolveOutcomes();
//创建解析后的结果数据集
ConditionOutcome[] outcomes = new ConditionOutcome[autoConfigurationClasses.length];
//将第一部分解析的结果放入数组
System.arraycopy(firstHalf, 0, outcomes, 0, firstHalf.length);
//将第二部分解析的结果放入数组
System.arraycopy(secondHalf, 0, outcomes, split, secondHalf.length);
return outcomes;
}
private OutcomesResolver createOutcomesResolver(String[] autoConfigurationClasses, int start, int end,
AutoConfigurationMetadata autoConfigurationMetadata) {
//新建一个标准的解析器
OutcomesResolver outcomesResolver = new StandardOutcomesResolver(autoConfigurationClasses, start, end,
autoConfigurationMetadata, getBeanClassLoader());
try {
//以标准解析器为参数新建线程异步解析器
return new ThreadedOutcomesResolver(outcomesResolver);
}
catch (AccessControlException ex) {
return outcomesResolver;
}
}
}