SpringBoot自动装配机制分析

  上篇分析了SpringBoot应用的启动流程,说到过自动装配发生在加载配置类并解析出对应的BeanDefinition这一阶段,同时我们也简要说明了@EnableAutoConfiguration是通过@Import元注解引入的AutoConfigurationImportSelector来实现的,今天就来分析下吧(基于spring-boot-2.1.6.RELEASE)。

Preface

mvm-arch

  典型的SpringBoot应用大多有着类似上图的包结构,我们知道@SpringBootApplication是一个复合注解,它包括:

  1. @Configuration
  2. @ComponentScan
  3. @EnableAutoConfiguration

这就意味着左侧Application这个类可以作为配置类来定义组件,比如添加@Bean标注的方法;同时它所在的包com.anyoptional作为组件扫描的根包,所有定义在其下及其子包下的组件都会被Spring IoC容器管理;最后是通过自动装配机制导入的外部配置。

  再提一嘴@Import元注解,它支持的导入类型有三种:

  1. @Configuration配置类,直接向容器导入组件
  2. ImportSelector实现类,返回@Configuration配置类,间接向容器导入组件
  3. ImportBeanDefinitionRegistrar实现类,携带BeanDefinitionRegistry,支持直接向容器中注册组件

How

  AutoConfigurationImportSelector实现了DeferredImportSelector接口——ImportSelector的一个变种,它的运行时机在所有@Configuration配置类被处理完毕之后。注意这个时间点,此时所有用户自定义的组件已经得到解析,这不正是条件注解@Conditional生效的好时机吗?大家比较熟悉的@ConditionalOnMissingBean@ConditionalOnProperty均是@Conditional元注解衍生出来的。spring-boot-autoconfigure虽然大量依赖@Conditional来实现条件注入,不过这部分逻辑却是在spring-context中实现的,有兴趣的话大家可以翻翻ConfigurationClassPostProcessor的源码。

selectImports(…)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
@Override
public String[] selectImports(AnnotationMetadata annotationMetadata) {
// 查看配置项 spring.boot.enableautoconfiguration
// 看看是否允许自动装配
if (!isEnabled(annotationMetadata)) {
// 不允许的话返回空数组了事
return NO_IMPORTS;
}
// 解析由 auto-configure annotation processor 生成的元数据
// 默认位于 META-INF/spring-autoconfigure-metadata.properties
// 里面的信息主要有两部分:
// 1. 自动配置类的导入条件,用来做过滤,优点是不用实例化配置类再做判断
// 2. 自动配置类的相对顺序,用来调整加载顺序
AutoConfigurationMetadata autoConfigurationMetadata = AutoConfigurationMetadataLoader
.loadMetadata(this.beanClassLoader);
// AutoConfigurationEntry 包含需要导入的自动配置类和需要排除的自动配置类
// 这一步便是通过 Spring SPI 机制加载所有的自动配置类,当然这里面还包含
// 过滤、排序等一系列操作
AutoConfigurationEntry autoConfigurationEntry = getAutoConfigurationEntry(autoConfigurationMetadata,
annotationMetadata);
// 返回需要由容器加载的自动配置类
return StringUtils.toStringArray(autoConfigurationEntry.getConfigurations());
}
AutoConfigurationMetadataLoader

  AutoConfigurationMetadataLoader的源码并不复杂,默认情况下它读取位于META-INF下的spring-autoconfigure-metadata.properties文件。这个文件由AutoConfigureAnnotationProcessor解析class file生成(位于包spring-boot-autoconfigure-processor),它主要包含以下两个方面的内容:

  1. 自动配置类的导入条件
  2. 自动配置类的相对顺序
1
2
3
# 截取自 spring-boot-autoconfifure 下的 META-INF/spring-autoconfigure-metadata.properties
org.springframework.boot.autoconfigure.jdbc.JdbcTemplateAutoConfiguration.AutoConfigureAfter=org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration
org.springframework.boot.autoconfigure.jdbc.JdbcTemplateAutoConfiguration.ConditionalOnSingleCandidate=javax.sql.DataSource

对于上面这个例子,说明:

  1. JdbcTemplateAutoConfiguration需要在DataSourceAutoConfiguration之后加载
  2. JdbcTemplateAutoConfiguration是否生效取决于容器中是否存在唯一的类型为javax.sql.DataSourceBean

这其实很好理解,因为JdbcTemplate操作数据库的能力来源于标准的javax.sql.DataSource,而javax.sql.DataSource默认情况下由DataSourceAutoConfiguration提供。

1
2
3
4
5
6
7
8
9
10
11
12
// AutoConfigureAnnotationProcessor 的声明
@SupportedAnnotationTypes({ "org.springframework.context.annotation.Configuration",
"org.springframework.boot.autoconfigure.condition.ConditionalOnClass",
"org.springframework.boot.autoconfigure.condition.ConditionalOnBean",
"org.springframework.boot.autoconfigure.condition.ConditionalOnSingleCandidate",
"org.springframework.boot.autoconfigure.condition.ConditionalOnWebApplication",
"org.springframework.boot.autoconfigure.AutoConfigureBefore",
"org.springframework.boot.autoconfigure.AutoConfigureAfter",
"org.springframework.boot.autoconfigure.AutoConfigureOrder" })
public class AutoConfigureAnnotationProcessor extends AbstractProcessor {
// omitted...
}

翻一下AutoConfigureAnnotationProcessor的源码,可以清楚地看到它支持的注解类型。因为AutoConfigureAnnotationProcessor解析的是class file,所以可以实现在不实例化自动配置类(比如上例的JdbcTemplateAutoConfiguration)的情况下判断它是否可以被容器加载,算是对内存的一点节约吧。

AutoConfigurationEntry
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
protected static class AutoConfigurationEntry {
// 需要被加载的自动配置类
private final List<String> configurations;
// 不需要被加载的自动配置类
private final Set<String> exclusions;

// rest are omitted...
}

protected AutoConfigurationEntry getAutoConfigurationEntry(
AutoConfigurationMetadata autoConfigurationMetadata, AnnotationMetadata annotationMetadata) {
if (!isEnabled(annotationMetadata)) {
return EMPTY_ENTRY;
}
// 获取 @EnableAutoConfiguration 注解 属性 -> 属性值 的映射
// 其实就是声明的 exclude/excludeName
AnnotationAttributes attributes = getAttributes(annotationMetadata);
// 通过 Spring SPI 机制,获取 spring.factories 文件中所有以
// @EnableAutoConfiguration 注解的全限定名为 key 的值,这些值对应着自动配置类的名称
List<String> configurations = getCandidateConfigurations(annotationMetadata, attributes);
// 通过 Set 去重
configurations = removeDuplicates(configurations);
// 提取由 @EnableAutoConfiguration#exclude/excludeName 和 spring.autoconfigure.exclude
// 指定的自动配置类的名称,这些配置类不需要被容器加载
Set<String> exclusions = getExclusions(annotationMetadata, attributes);
// 检查这些待排除的自动配置类是否存在,并且它们是否真的属于自动配置类的一员
checkExcludedClasses(configurations, exclusions);
// 从自动配置类集合中排除这些不需要加载的
configurations.removeAll(exclusions);
// 根据 AutoConfigurationMetadata 进行过滤
configurations = filter(configurations, autoConfigurationMetadata);
// 通过 SPI 机制加载 AutoConfigurationImportListener(s) 进行回调
fireAutoConfigurationImportEvents(configurations, exclusions);
// 返回结果
return new AutoConfigurationEntry(configurations, exclusions);
}

  getAutoConfigurationEntry(...)主要做了下面几件事:

  1. 汇总需要排除的自动配置类
  2. 通过Spring SPI机制提取所有待加载的自动配置类
  3. 过滤第2步得到的集合,剔除不符合要求或不需要进行加载的
  4. 回调AutoConfigurationImportListener,监听器同样由Spring SPI机制加载

其中第12和第4步都比较简单,大家自己看看就可以了,我们重点来说说第3步——过滤。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
private List<String> filter(List<String> configurations, 
AutoConfigurationMetadata autoConfigurationMetadata) {
long startTime = System.nanoTime();
String[] candidates = StringUtils.toStringArray(configurations);
// 对应 configurations 中自动配置类的下标,标记其是否需要被排除
boolean[] skip = new boolean[candidates.length];
boolean skipped = false;
// 通过 SPI 机制加载 AutoConfigurationImportFilter 来进行过滤
for (AutoConfigurationImportFilter filter : getAutoConfigurationImportFilters()) {
invokeAwareMethods(filter);
// 判定
boolean[] match = filter.match(candidates, autoConfigurationMetadata);
for (int i = 0; i < match.length; i++) {
// 未通过的话进行记录
if (!match[i]) {
skip[i] = true;
// 清掉数据,如此下一个 Filter 就不用再判定了
candidates[i] = null;
skipped = true;
}
}
}
// 都有效直接返回即可,否则...
if (!skipped) {
return configurations;
}
// 就需要遍历一次,剔除不需要的
List<String> result = new ArrayList<>(candidates.length);
for (int i = 0; i < candidates.length; i++) {
if (!skip[i]) {
result.add(candidates[i]);
}
}
if (logger.isTraceEnabled()) {
int numberFiltered = configurations.size() - result.size();
logger.trace("Filtered " + numberFiltered + " auto configuration class in "
+ TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - startTime) + " ms");
}
return new ArrayList<>(result);
}

可以看到对自动配置类的过滤工作是通过代理给AutoConfigurationImportFilter来完成的,这些过滤器同样是通过Spring SPI机制进行加载的,默认注册的有:

1
2
3
4
5
6
# 截取自 spring-boot-autoconfigure 包下的 META-INF/spring.factories
# Auto Configuration Import Filters
org.springframework.boot.autoconfigure.AutoConfigurationImportFilter=\
org.springframework.boot.autoconfigure.condition.OnBeanCondition,\
org.springframework.boot.autoconfigure.condition.OnClassCondition,\
org.springframework.boot.autoconfigure.condition.OnWebApplicationCondition

都是好东西,挑一挑吧。那就挑OnClassCondition来看看吧。

OnClassCondition

  翻开OnClassCondition的源码,可以看到AutoConfigurationImportFilter#match(...)是其父类实现的,然后代理给了模板方法getOutcomes(...),我们直接看这个方法就行。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// 实际工作又代理给了 OutcomesResolver, 注意这里有个并行的优化
@Override
protected final ConditionOutcome[] getOutcomes(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());
// 合并两个 OutcomesResolver 的处理结果
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;
}

只能说大牛写的代码都比较绕吧,getOutcomes(...)也是个代理商,实际的工作都交给OutcomesResolver去完成了。注意这里分而治之的思想,待处理的自动配置类被一分为二,由两个线程并行完成。那继续看看StandardOutcomesResolver是怎么处理的呗。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
private final class StandardOutcomesResolver implements OutcomesResolver {

// fields、ctor are omitted...

@Override
public ConditionOutcome[] resolveOutcomes() {
return getOutcomes(this.autoConfigurationClasses, this.start, this.end, this.autoConfigurationMetadata);
}

private ConditionOutcome[] getOutcomes(String[] autoConfigurationClasses, int start, int end,
AutoConfigurationMetadata autoConfigurationMetadata) {
ConditionOutcome[] outcomes = new ConditionOutcome[end - start];
for (int i = start; i < end; i++) {
String autoConfigurationClass = autoConfigurationClasses[i];
if (autoConfigurationClass != null) {
// 获取当前 autoConfigurationClass 的 ConditionalOnClass
// 比如 example.MyConfig.ConditionalOnClass=example.YourConfig
// 这里就会返回 example.YourConfig,注意这个值是 CSV 格式的
String candidates = autoConfigurationMetadata.get(autoConfigurationClass, "ConditionalOnClass");
if (candidates != null) {
// 判定 candidates 代表的类是否存在于 classpath 下
outcomes[i - start] = getOutcome(candidates);
}
}
}
return outcomes;
}
// 对 candidates 的格式进行处理
private ConditionOutcome getOutcome(String candidates) {
try {
if (!candidates.contains(",")) {
return getOutcome(candidates, this.beanClassLoader);
}
// CSV 格式分解
for (String candidate : StringUtils.commaDelimitedListToStringArray(candidates)) {
ConditionOutcome outcome = getOutcome(candidate, this.beanClassLoader);
if (outcome != null) {
return outcome;
}
}
}
catch (Exception ex) {
// We'll get another chance later
}
return null;
}
// 最终的判定逻辑
private ConditionOutcome getOutcome(String className, ClassLoader classLoader) {
// ClassNameFilter 无非是通过类加载机制来进行判定
// 比如 classLoader.loadClass(className) 或者 classLoader 为空则是 Class.forName(className)
if (ClassNameFilter.MISSING.matches(className, classLoader)) {
return ConditionOutcome.noMatch(ConditionMessage.forCondition(ConditionalOnClass.class)
.didNotFind("required class").items(Style.QUOTE, className));
}
return null;
}
}

前面分析了AutoConfigurationMetadata的加载,这里就利用上了这部分元数据——由autoConfigurationMetadata.get(autoConfigurationClass, "ConditionalOnClass")体现,剩下的只需要通过类加载机制判定一下这些类是否存在就可以了。注意整个判定过程中自动配置类并没有实例化,仅仅使用了它的全限定名。

getImportGroup()

  前面对selectImports(...)的分析已经可以解释SpringBoot的自动装配机制了,不过这里还有一个问题,那就是没有处理自动配置类的加载顺序。我们知道自动配置类可以使用@AutoConfigureBefore@AutoConfigureAfter来指定相对顺序,使用AutoConfigureOrder来指定绝对顺序,不过这在selectImports(...)中一点儿也没有得到体现。答案就在getImportGroup(),它返回的AutoConfigurationGroup处理了这个遗留问题。

1
2
3
4
@Override
public Class<? extends Group> getImportGroup() {
return AutoConfigurationGroup.class;
}
AutoConfigurationGroup
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
private static class AutoConfigurationGroup
implements DeferredImportSelector.Group, BeanClassLoaderAware, BeanFactoryAware, ResourceLoaderAware {

// fields、*Aware are omitted...

@Override
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(getAutoConfigurationMetadata(), annotationMetadata);
this.autoConfigurationEntries.add(autoConfigurationEntry);
// 自动装配类的类名 -> 标注 @EnableAutoConfiguration 类的注解元信息
for (String importClassName : autoConfigurationEntry.getConfigurations()) {
this.entries.putIfAbsent(importClassName, annotationMetadata);
}
}

@Override
public Iterable<Entry> selectImports() {
if (this.autoConfigurationEntries.isEmpty()) {
return Collections.emptyList();
}
Set<String> allExclusions = this.autoConfigurationEntries.stream()
// 待排除的自动配置类集合
.map(AutoConfigurationEntry::getExclusions)
// 降维
.flatMap(Collection::stream)
// 收集成 Set 去重
.collect(Collectors.toSet());
Set<String> processedConfigurations = this.autoConfigurationEntries.stream()
// 待加载的自动配置类集合
.map(AutoConfigurationEntry::getConfigurations)
// 降维
.flatMap(Collection::stream)
// 收集成 Set 去重并保持顺序
.collect(Collectors.toCollection(LinkedHashSet::new));
// 剔除明确不需要加载的
processedConfigurations.removeAll(allExclusions);
// 对剩下的进行排序并转换成Entry
return sortAutoConfigurations(processedConfigurations, getAutoConfigurationMetadata()).stream()
.map((importClassName) -> new Entry(this.entries.get(importClassName), importClassName))
.collect(Collectors.toList());
}

// getAutoConfigurationMetadata() omitted...

private List<String> sortAutoConfigurations(Set<String> configurations,
AutoConfigurationMetadata autoConfigurationMetadata) {
// 使用 AutoConfigurationSorter 进行排序
return new AutoConfigurationSorter(getMetadataReaderFactory(), autoConfigurationMetadata)
.getInPriorityOrder(configurations);
}

// 如果 spring boot starter 未引入 spring-boot-autoconfigure-processor.jar
// 那就不会生成 spring-autoconfigure-metadata.properties
// 这样的话就需要 MetadataReaderFactory 创建 MetadataReader 来读取
// 和自动配置顺序相关的注解了,比如 @AutoConfigureBefore
private MetadataReaderFactory getMetadataReaderFactory() {
try {
return this.beanFactory.getBean(SharedMetadataReaderFactoryContextInitializer.BEAN_NAME,
MetadataReaderFactory.class);
} catch (NoSuchBeanDefinitionException ex) {
return new CachingMetadataReaderFactory(this.resourceLoader);
}
}
}

AutoConfigurationGroup确实只加入了对自动配置类顺序的处理,其它逻辑是相同的,我们的重心自然也转到AutoConfigurationSorter

AutoConfigurationSorter
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public List<String> getInPriorityOrder(Collection<String> classNames) {
AutoConfigurationClasses classes = new AutoConfigurationClasses(this.metadataReaderFactory,
this.autoConfigurationMetadata, classNames);
List<String> orderedClassNames = new ArrayList<>(classNames);
// 1. 按字母表顺序排序
Collections.sort(orderedClassNames);
// 2. 按 @AutoConfigureOrder 指定的优先级排序
orderedClassNames.sort((o1, o2) -> {
int i1 = classes.get(o1).getOrder();
int i2 = classes.get(o2).getOrder();
return Integer.compare(i1, i2);
});
// 3. 最后根据 @AutoConfigureBefore @AutoConfigureAfter 来进行微调
orderedClassNames = sortByAnnotation(classes, orderedClassNames);
return orderedClassNames;
}

  鉴于本篇的篇幅已经很长了,这里仅仅标注了一下AutoConfigurationSorter进行排序的大体步骤,具体细节各位看官自己去扣一扣吧。

End

  今天和大家分享了SpringBoot自动装配机制的原理,相信大家看完后可以开心地编排自定义的starter了,完。