背景
Spring 经过近20年的发展，目前版本已经迭代到了5.x，每个版本 Spring 都有不同的改进，版本 5.x 中，Spring 把重心放到了性能优化上。我们知道，Spring 注解驱动编程中，Spring 启动时需要对类路径下的包进行扫描，以便发现所需管理的 bean。如果在应用启动前能够确定 Spring bean，不再进行扫描，那么性能就会大大提高，Spring 5 对此进行了实现。
@Indexed 与 spring-context-indexer
spring-framework 在版本 5.x 中新增了一个模块 spring-context-indexer，作用就是在编译时扫描 @Indexed 注解，确定 bean，生成索引文件。先看如下 Spring 官网 候选组件索引生成 一节的介绍。
尽管类路径扫描已经非常快了，仍可以在编译时创建静态的候选列表来提高大型应用的启动性能。在这种模式下，组件扫描的所有目标的模块都必须使用这种机制。
现有的 @ComponentScan 或 <context:component-scan 指令必须保留，以便让上下文扫描包中的候选对象。当 ApplicationContext 扫描到这样的索引，将自动使用它，而不是扫描类路径。
要生成索引，需要向包含组件的每个模块中添加附件的依赖，这些组件是组件扫描的目标。以下示例展示了如何在 maven 中使用。
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context-indexer</artifactId>
<version>5.2.6.RELEASE</version>
<optional>true</optional>
</dependency>
</dependencies>
对于 Gradle 4.5 或更早的版本，依赖关系应该在 compileOnly 配置中声明。如下例所示。
dependencies {
compileOnly "org.springframework:spring-context-indexer:5.2.6.RELEASE"
}
对于 Gradle 4.6 或以后的版本，依赖应该被定义在 annotationProcessor 配置中。如下例所示。
dependencies {
annotationProcessor "org.springframework:spring-context-indexer:{spring-version}"
}
编译处理过程将生成 META-INF/spring.components 文件到 jar 包中。
在 IDE 中使用这种模式时，必须将 spring-context-indexer 注册为注解处理器以确保当候选组件被更新的时候索引是最新的。
当 META-INF/spring.components 在类路径下时索引自动启用。如果索引在一些库(或用例)有效，但不能为整个应用构建索引，可以通过设置 spring.index.ignore 为 true 来回退到常规的类路径处理，参数可以是系统属性或在根路径的 spring.properties 文件中。
@Indexed 如何提高 Spring 启动性能
根据上面官网的介绍我们知道 spring-context-indexer 可以生成 META-INF/spring.components 文件到类路径，那么文件中到底保存了哪些信息？文件中的的所有内容都会被用到吗？Spring 又是如何读取文件的？
Indexed 注解的定义
Indexed 源码如下。
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Indexed {
}
可以看到，@Indexed 注解只能标注在类型上。@Indexed 标注的注解如果标注或元标注在类上，则这个类将成为候选的对象。
META-INF/spring.components 如何生成？
spring-context-indexer 定义了一个注解处理器(参见前面的文章 Java 注解处理器及其应用 )，因此只需要跟踪注解处理的逻辑即可了解其内部的实现，确定写入的文件内容。事实上 spring-context-indexer 模块中的类也确实没有几个，其项目结构如下图所示。
CandidateComponentsIndexer 就是注解处理器，其核心源码如下所示。
public class CandidateComponentsIndexer implements Processor {
...省略部分代码
@Override
public synchronized void init(ProcessingEnvironment env) {
this.stereotypesProviders = getStereotypesProviders(env);
this.typeHelper = new TypeHelper(env);
this.metadataStore = new MetadataStore(env);
this.metadataCollector = new MetadataCollector(env, this.metadataStore.readMetadata());
}
// 处理注解
@Override
public boolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv) {
// 标记元素已被处理
this.metadataCollector.processing(roundEnv);
// 处理元素
roundEnv.getRootElements().forEach(this::processElement);
if (roundEnv.processingOver()) {
// 最后一轮处理写文件
writeMetaData();
}
return false;
}
...省略部分代码
private void processElement(Element element) {
addMetadataFor(element);
staticTypesIn(element.getEnclosedElements()).forEach(this::processElement);
}
private void addMetadataFor(Element element) {
Set<String> stereotypes = new LinkedHashSet<>();
// 分别收集不同的元数据
this.stereotypesProviders.forEach(p -> stereotypes.addAll(p.getStereotypes(element)));
if (!stereotypes.isEmpty()) {
// 元数据汇总，ItemMetadata 包含元素的类型和模式信息
this.metadataCollector.add(new ItemMetadata(this.typeHelper.getType(element), stereotypes));
}
}
...省略部分代码
}
CandidateComponentsIndexer 一轮一轮的处理元素，到最后一轮时将获取到的元数据写入到文件中。StereotypesProvider 是元数据的收集器，用来收集元素中的模式信息，模式信息可能是注解等类型，也可能是其他的信息。收集到的每一项元数据保存到 ItemMetadata，包含类型和类型对应的模式列表。最终类型作为 key，模式列表以英文逗号分隔作为 value，以 properties 的形式保存到文件。StereotypesProvider 定义如下。
interface StereotypesProvider {
/**
* 返回给定元素的模式信息
*/
Set<String> getStereotypes(Element element);
}
StereotypesProvider 有三个实现，具体如下。
- IndexedStereotypesProvider: 用来处理 @Indexed 注解，事实上也只有这个类才处理 @Indexed 注解。其获取到的模式信息如下。
- @Indexed 注解直接标注的类型完全限定名，包括父类和接口。
- 标注或元标注在类上的并且被 @Indexed 元标注的注解类型的完全限定名。
- StandardStereotypesProvider：收集的模式信息为类上直接标注或通过 @Inherited 可以获取到的 Java 中包名以 javax 开头的注解的完全限定名。
- PackageInfoStereotypesProvider：注解如果标注在 package-info.java 文件中的包名上，则收集的模式信息为 package-info 。
示例如下：
@Indexed
@Service
public interface Inter1 {
}
@Named
public interface Inter2 {
}
@Indexed
public class Parent {
}
@Component
@Indexed
public class Child extends Parent implements Inter1,Inter2 {
}
// package-info.java
@PackageAnnotation
package com.zzhkp;
编译后获取到的文件内容如下。
com.zzhkp=package-info
com.zzhkp.Child=org.springframework.stereotype.Component,com.zzhkp.Child,com.zzhkp.Parent,com.zzhkp.Inter1
com.zzhkp.Inter1=org.springframework.stereotype.Component,com.zzhkp.Inter1
com.zzhkp.Inter2=javax.inject.Named
com.zzhkp.Parent=com.zzhkp.Parent
可见 StereotypesProvider 已经正确收集了所需的信息，这些信息保存在文件，将作为索引，在 Spring 应用上下文启动时进行读取。
META-INF/spring.components 如何读取？
以 AnnotationConfigApplicationContext 应用上下文为例，其扫描 bean 的过程需要保证在刷新之前，其扫描的核心源码如下。
public class AnnotationConfigApplicationContext extends GenericApplicationContext implements AnnotationConfigRegistry {
private final AnnotatedBeanDefinitionReader reader;
//类路径下的 BeanDefinition 扫描器
private final ClassPathBeanDefinitionScanner scanner;
public AnnotationConfigApplicationContext() {
this.reader = new AnnotatedBeanDefinitionReader(this);
this.scanner = new ClassPathBeanDefinitionScanner(this);
}
@Override
public void scan(String... basePackages) {
Assert.notEmpty(basePackages, "At least one base package must be specified");
this.scanner.scan(basePackages);
}
}
可以看到 AnnotationConfigApplicationContext 将扫描的功能委托给 ClassPathBeanDefinitionScanner 进行实现，ClassPathBeanDefinitionScanner 对象在应用上下文实例化时创建，其核心构造方法如下。
public ClassPathBeanDefinitionScanner(BeanDefinitionRegistry registry, boolean useDefaultFilters,
Environment environment, @Nullable ResourceLoader resourceLoader) {
Assert.notNull(registry, "BeanDefinitionRegistry must not be null");
this.registry = registry;
if (useDefaultFilters) {
// 注册默认的过滤器
registerDefaultFilters();
}
setEnvironment(environment);
// 加载 META-INF/spring.components 文件
setResourceLoader(resourceLoader);
}
registerDefaultFilters() 方法用来注册默认的过滤器，满足过滤器要求的类型才会被作为 bean，其源码如下。
protected void registerDefaultFilters() {
this.includeFilters.add(new AnnotationTypeFilter(Component.class));
ClassLoader cl = ClassPathScanningCandidateComponentProvider.class.getClassLoader();
try {
this.includeFilters.add(new AnnotationTypeFilter(
((Class<? extends Annotation>) ClassUtils.forName("javax.annotation.ManagedBean", cl)), false));
logger.trace("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.trace("JSR-330 'javax.inject.Named' annotation found and supported for component scanning");
} catch (ClassNotFoundException ex) {
// JSR-330 API not available - simply skip.
}
}
默认的过滤器是 AnnotationTypeFilter，用来匹配类上存在的注解或元注解。这里支持的注解是被 @Indexed 标注的 @Component 注解以及 javax 包下的 @ManagedBean、@Named 注解。由此可见，并不是所有 spring.components 文件内的类型都会被作为 bean 处理。
spring.components 文件的读取在 ClassPathBeanDefinitionScanner 的父类ClassPathScanningCandidateComponentProvider 的 setResourceLoader 方法中，源码如下。
@Nullable
private CandidateComponentsIndex componentsIndex;
@Override
public void setResourceLoader(@Nullable ResourceLoader resourceLoader) {
this.resourcePatternResolver = ResourcePatternUtils.getResourcePatternResolver(resourceLoader);
this.metadataReaderFactory = new CachingMetadataReaderFactory(resourceLoader);
this.componentsIndex = CandidateComponentsIndexLoader.loadIndex(this.resourcePatternResolver.getClassLoader());
}
可以看到读取文件最终是由CandidateComponentsIndexLoader.loadIndex完成，并将读取结果保存到 CandidateComponentsIndex 中。读取的逻辑也较为简单，判断类路径 spring.properties 文件内或系统参数 spring.index.ignore 是否设置为true，如果是则跳过读取，否则使用 ClassLoader 获取类路径下所有的 META-INF/spring.components 文件(参见前面的文章 Java 中如何获取 classpath 下资源文件? )，并加载为 Properties，然后保存到 CandidateComponentsIndex 。
那么读取到的文件内容都会被使用吗？事实并非如此。ClassPathBeanDefinitionScanner 获取候选组件的工作交给父类来完成，源码如下。
public Set<BeanDefinition> findCandidateComponents(String basePackage) {
if (this.componentsIndex != null && indexSupportsIncludeFilters()) {
// 从索引中添加候选组件
return addCandidateComponentsFromIndex(this.componentsIndex, basePackage);
} else {
// 从类路径下扫描候选组件
return scanCandidateComponents(basePackage);
}
}
这个方法是查找候选组件的核心方法，这里加了判断，如果存在 CandidateComponentsIndex 并且 存在支持 @Indexed 的过滤器，则会从 spring.components 读取 bean，否则还是需要从类路径下进行组件扫描。从索引中添加候选组件的源码如下。
private Set<BeanDefinition> addCandidateComponentsFromIndex(CandidateComponentsIndex index, String basePackage) {
Set<BeanDefinition> candidates = new LinkedHashSet<>();
try {
Set<String> types = new HashSet<>();
for (TypeFilter filter : this.includeFilters) {
// 获取过滤器支持的模式
String stereotype = extractStereotype(filter);
if (stereotype == null) {
throw new IllegalArgumentException("Failed to extract stereotype from " + filter);
}
// 根据包名和模式查找对应的类型
types.addAll(index.getCandidateTypes(basePackage, stereotype));
}
boolean traceEnabled = logger.isTraceEnabled();
boolean debugEnabled = logger.isDebugEnabled();
for (String type : types) {
// 读取类型信息
MetadataReader metadataReader = getMetadataReaderFactory().getMetadataReader(type);
// 判断类型是否为候选组件
if (isCandidateComponent(metadataReader)) {
ScannedGenericBeanDefinition sbd = new ScannedGenericBeanDefinition(metadataReader);
sbd.setSource(metadataReader.getResource());
if (isCandidateComponent(sbd)) {
if (debugEnabled) {
logger.debug("Using candidate component class from index: " + type);
}
candidates.add(sbd);
} else {
if (debugEnabled) {
logger.debug("Ignored because not a concrete top-level class: " + type);
}
}
} else {
if (traceEnabled) {
logger.trace("Ignored because matching an exclude filter: " + type);
}
}
}
} catch (IOException ex) {
throw new BeanDefinitionStoreException("I/O failure during classpath scanning", ex);
}
return candidates;
}
includeFilters 是指满足条件的过滤器，满足条件才会被添加。上述 registerDefaultFilters() 方法注册了支持注解 @Component、@ManagedBean、@Named 的注解类型过滤器。 这里先获取过滤器支持的模式，然后根据所需的包名和模式从前面保存模式信息的 CandidateComponentsIndex 对象中获取模式对应的类型。然后判断类型是否为候选的组件，如果是则创建对应的 BeanDefinition 并添加到返回的列表中。至此 META-INF/spring.components 文件内满足条件的 bean 被转换为 BeanDefinition 。
@Indexed 使用注意事项
通过上面的描述可以知道，我们自定义的注解如果标注了 @Component 也会被作为 bean ，因为 @Component 上面标注了 @Indexed 注解。
@Indexed 并非可以任意使用。在没有其他模块依赖或者所依赖的模块都生成了 spring.components 文件时不会存在问题，然而如果依赖的模块只有部分模块存在 spring.components 文件，则其他模块的 bean 也不会被扫描，为避免这种问题，需要在类路径下 spring.properties 文件中或系统属性中的 spring.index.ignore 参数设置为 true，这样就会跳过 spring.components 文件的扫描，而转为重新扫描类路径下的 bean 。
总结
本篇首先通过介绍 @Indexed 实现启动性能优化的原理，然后从源码层面对索引文件的生成和读取进行了剖析，最后还介绍了 @Indexed 的注意事项。其中使用到的技术包括类路径下资源获取、注解处理器等，事实上 Spring 内部的实现都是依赖 Java 最基础的技术，只有提高最核心的能力，阅读 Spring 源码才能够得心应手。最后欢迎大家指导，共同进步。