前言
现在Spring Boot使用越来越广泛，基于注解的配置越来越受欢迎，注解及其相关的技术很早就出现了，本文主要是依照源码跟踪基于注解的bean的初始化流程，希望读者已经了解原来流行的xml的配置的bean的初始化流程基础知识。本文会概述xml相关的初始化基本原理，这一块若在阅读过程中有疑问读者可以自己搜索相关详细内容，而关于注解到Bean Definition（这个不知道可以先往下看，看不懂可以去详细了解基于XML的IoC容器加载过程）的流程会尽量详细。
概述：基于XML的IoC容器初始化流程
IoC容器本身也是一个类，这个类通过定义相关的属性来记录容器的状态，存放容器的组件等等，定义相关的方法来进行对容器的各种操作和容器本身运转自己需要的操作。当然现在spring ioc的容器功能很强大，如果要定义成一个非常大的类那就很不好扩展和维护，所以IoC容器类的定义是分了很多层级的，体现了很多设计模式思想，也遵循SOLID设计原则。
IoC容器在spring中的相关类按名字分主要是BeanFactory和ApplicationContext。一般ApplicationContext依赖于BeanFactory，更靠近使用者，所以平常能用到如ClassPathXmlApplicationContext,FileSystemXmlApplicationContext，AnnotationConfigApplicationContext等类来new一个容器对象。
先来看平常开发很少用的但却是IoC容器基石的BeanFactory家族：
其中有<<interface>>标识的是接口，没有的是类，名字前缀为Abstract的为抽象类，spring的命名很规范。
BeanFactory就分了很多层，接口按功能分开遵从接口隔离原则，约束了spring内部对象处理时的行为。这种分层看起来复杂，但是对遵循开闭原则进行扩展是非常有利的，而且抽象类或接口相互关联是靠抽象和抽象之间关联（面向接口编程，依赖倒转），具体的实现就比较容易加在层次之间，有相当的灵活性。比如从顶端分出来的ListableBeanFactory、HierarchicalBeanFactory、AutowireCapableBeanFactory就分别规定了容器的列出组件的行为、容器之间的父子关系（比如Spring MVC的servlet context容器的父容器是root context）、容器的装配行为（依赖注入）。因为java是单继承，但是可以实现多个接口，所以这些接口的行为最后又可以在一个汇总的类上体现。上图并没有将这些类相关的所有的接口或父类给列出来，范围限制在了名为BeanFactory的类。
再来看ApplicationContext，ApplicationContext与BeanFactory多了很多与企业应用相关的功能，本文关注的是资源加载这块的功能。
展示了XML相关的ApplicationContext，最上面继承了相应的BeanFactory接口，没有继承下来的实现类或抽象类不是用不到了，而是没在继承或实现里展现出来，比如在一些ApplicationContext类的方法中会new DefaultListableBeanFactory并使用它。到ApplicationContext就不仅是接口隔离了，不同的实现类或者再往下衍生的的子类就会越来越“具体”的进行相应实现并且成为一个强大IoC容器。同样，图中只是展现了名为ApplicationContext的类，其他一些实现的接口或父类没有展现出来。比如重要的接口ResourceLoader，让ApplicationContext不仅是有IoC容器的特性，ApplicationContext本身也是相应的资源加载器。ApplicationContext中处处体现了模板方法模式的思想，抽象类调用抽象方法，然后由子类来实现具体的方法。不同的描述bean的定义的信息源就会有不同的ApplicationContext子类去实现加载资源的逻辑。比如ClassPathXmlApplicationContext就会有去classpath下找相应的定义bean的xml配置文件并加载到容器中的行为。Bean从我们手写的配置文件（不管是xml还是注解等等，对，注解也可以算做描述“资源”），到最后可用的对象的大致过程如下：
基于注解的AnnotationConfigApplicationContext
相对于ClassPathXmlApplicationContext等常用容器类，AnnotationConfigApplicationContext是专门加载注解描述信息的容器。这也体现了spring架构的易扩展性，注解也可以看做是一种描述Bean的资源。
AnnotationConfigApplicationContext主要实现的接口及继承的类
看一下这几个相关的类：
AbstractApplicationContext——ApplicationContext接口的抽象实现，没有强制规定配置的存储类型，仅仅实现了通用的上下文功能。这个实现用到了模板方法设计模式，需要具体的子类来实现其抽象方法。几乎现在能用到的ApplicationContext都继承了这个抽象类（可回头看上面的XML相关的类也是）。
GenericApplicationContext——会new并持有一个DefaultListableBeanFactory实例（这个类虽然不会被继承，但是上一节所描述的体系底层类中会持有这个类的实例来当容器，剩下的就是再实现其它接口）。GenericApplicationContext有了一个真正可以操作的DefaultListableBeanFactory，通过复写一部分继承来的方法操作这个内含容器，比如调用refresh()方法来初始化那些带有应用上下文语义（org.springframework.context.ApplicationContextAware）的bean，自动探测org.springframework.beans.factory.config.BeanFactoryPostProcessor等。Generic系列的ApplicationContext的特点就体现在暴露BeanDefinitionRegistry的相应实现方法和refresh不重新创建容器。ClassPathXmlApplicationContext这些容器没有暴露动态的注册BeanDefinition的接口，只能靠在容器refresh()的时候载入，refresh时会创建容器并走一遍相关的流程，比如bean的描述到BeanDefinition的载入，bean的依赖注入，生命周期的逻辑扩展执行（spring提供的可以在bean加载后或整个容器初始化后做的事情这些扩展点），GenericApplicationContext可以通过registerBeanDefinition等方法注册删除相应的BeanDefinition，并且refresh的时候不创建新的容器，只是为了实例化新注册的BeanDefinition等。
BeanDefinitionRegistry——用于持有像RootBeanDefinition和 ChildBeanDefinition实例的bean definitions的注册表接口。DefaultListableBeanFactory实现了这个接口，GenericApplicationContext也实现了这个接口，GenericApplicationContext只是包了一下相应方法。
AnnotationConfigRegistry——注解配置注册表。用于注解配置应用上下文的通用接口，拥有一个注册配置类和扫描配置类的方法。
GenericApplicationContext平常业务用的不多，也是因为它的特点，我们一般不会手动的去添加或删除BeanDefinition，并希望refresh的时候能够彻底地刷新容器（重建一个）。下面对比看下其中的刷新过程逻辑，ClassPathXmlApplicationContext继承的AbstractRefreshableApplicationContext的刷新容器方法（这个方法是refresh调用的其中一个，refresh还会做其他事，比如注册监听器等等容器初始化会干的事）：
可以看到重新创建了一个容器，下面再看下GenericApplicationContext的刷新容器方法：
几乎没做什么事，只是设置了一个序列化要用的id。
讲了这么多GenericApplicationContext是因为AnnotationConfigApplicationContext继承自它，也有它的特性，下面我们来剖析AnnotationConfigApplicationContext。
AnnotationConfigApplicationContext的构造方法
成员变量及构造方法：
private final AnnotatedBeanDefinitionReader reader;
private final ClassPathBeanDefinitionScanner scanner;
/**
* Create a new AnnotationConfigApplicationContext that needs to be populated
* through {@link #register} calls and then manually {@linkplain #refresh refreshed}.
*/
public AnnotationConfigApplicationContext() {
this.reader = new AnnotatedBeanDefinitionReader(this);
this.scanner = new ClassPathBeanDefinitionScanner(this);
}
/**
* Create a new AnnotationConfigApplicationContext, deriving bean definitions
* from the given annotated classes and automatically refreshing the context.
* @param annotatedClasses one or more annotated classes,
* e.g. {@link Configuration @Configuration} classes
*/
public AnnotationConfigApplicationContext(Class<?>... annotatedClasses) {
this();
register(annotatedClasses);
refresh();
}
/**
* Create a new AnnotationConfigApplicationContext, scanning for bean definitions
* in the given packages and automatically refreshing the context.
* @param basePackages the packages to check for annotated classes
*/
public AnnotationConfigApplicationContext(String... basePackages) {
this();
scan(basePackages);
refresh();
}
AnnotationConfigApplicationContext有两个成员变量，从名字来看一个用来读取注解定义的BeanDefinition,一个用来扫描对应路径下的BeanDefinition。
无参的构造函数通过注释可以看到是让手动调用注册相应BeanDefinition并手动refresh来实例化Bean。当然是可以利用两个成员变量来做这个事的，两个成员变量私有，用相应的方法可以达到目的。
传入annotatedClasses参数则是调用register方法来从类上获取相应的注解，转化成BeanDefinition到容器中。然后调用refresh方法（这个就是AbstractApplicationContext的refresh方法，模板方法模式再调用子类的一些实现方法），前面讲了主要是把新注册的BeanDefinition实例化（lazy-init的不会实例化，但是会有绑一些事件这些refresh要进行的操作）,refresh涉及的整个流程其实是非常繁琐的，会调很多层数深的函数。
传入basePackages参数调用scan方法来扫描某一包下的所有类（包括接口）的注解。
AnnotationConfigApplicationContext的register和scan方法
AnnotationConfigApplicationContext的register方法：
public void register(Class<?>... annotatedClasses) {
Assert.notEmpty(annotatedClasses, "At least one annotated class must be specified");
this.reader.register(annotatedClasses);
}
其中reader是构造函数初始化的AnnotatedBeanDefinitionReader，它的register及相关方法：
public void register(Class<?>... annotatedClasses) {
for (Class<?> annotatedClass : annotatedClasses) {
registerBean(annotatedClass);
}
}
public void registerBean(Class<?> annotatedClass) {
registerBean(annotatedClass, null, (Class<? extends Annotation>[]) null);
}
public void registerBean(Class<?> annotatedClass, Class<? extends Annotation>... qualifiers) {
registerBean(annotatedClass, null, qualifiers);
}
public void registerBean(Class<?> annotatedClass, String name, Class<? extends Annotation>... qualifiers) {
//解析能转化成BeanDefinition的注解的所在类，创建Spring容器中对BeanDefinition的封装的数据结构
AnnotatedGenericBeanDefinition abd = new AnnotatedGenericBeanDefinition(annotatedClass);
AnnotationMetadata metadata = abd.getMetadata();
//Spring的Profile机制，和maven的profile机制差不多，只有当Profile被激活时才继续解析加载相应的Bean
if (metadata.isAnnotated(Profile.class.getName())) {
AnnotationAttributes profile = MetadataUtils.attributesFor(metadata, Profile.class);
if (!this.environment.acceptsProfiles(profile.getStringArray("value"))) {
return;
}
}
//解析@Scope注解定义的域并设置到BeanDefinition，如Singleton，Prototype
ScopeMetadata scopeMetadata = this.scopeMetadataResolver.resolveScopeMetadata(abd);
abd.setScope(scopeMetadata.getScopeName());
//由beanNameGenerator生成Bean的名称，这个generator可以通过AnnotationConfigApplicationContext的方法设置的
String beanName = (name != null ? name : this.beanNameGenerator.generateBeanName(abd, this.registry));
//处理BeanDefinition的通用注解：@Primary，@DependsOn，@Lazy，@Role
AnnotationConfigUtils.processCommonDefinitionAnnotations(abd);
//处理限定符注解@Qualifier，这个注解为了区分有歧义的Bean，比如在Autowire装配的时候可以注入的Bean有两个，就可以通过加这个注解区分
if (qualifiers != null) {
for (Class<? extends Annotation> qualifier : qualifiers) {
if (Primary.class.equals(qualifier)) {
abd.setPrimary(true);
}
else if (Lazy.class.equals(qualifier)) {
abd.setLazyInit(true);
}
else {
abd.addQualifier(new AutowireCandidateQualifier(qualifier));
}
}
}
//封装Bean名字和BeanDefinition
BeanDefinitionHolder definitionHolder = new BeanDefinitionHolder(abd, beanName);
//根据注解Bean定义类中配置的作用域，创建相应的代理对象
definitionHolder = AnnotationConfigUtils.applyScopedProxyMode(scopeMetadata, definitionHolder, this.registry);
//向容器中注册BeanDefinition
BeanDefinitionReaderUtils.registerBeanDefinition(definitionHolder, this.registry);
}
AnnotationConfigApplicationContext的scan方法：
public void scan(String... basePackages) {
Assert.notEmpty(basePackages, "At least one base package must be specified");
this.scanner.scan(basePackages);
}
其中reader是构造函数初始化的ClassPathBeanDefinitionScanner，它在构造的时候指定（通过boolean参数）是否使用默认的扫描过滤规则。即Spring默认扫描配置：@Component、@Repository、@Service、@Controller注解的Bean，同时也支持JavaEE6的@ManagedBean和JSR-330的@Named注解。ClassPathBeanDefinitionScanner的scan及相关方法：
public int scan(String... basePackages) {
int beanCountAtScanStart = this.registry.getBeanDefinitionCount();
doScan(basePackages);
// Register annotation config processors, if necessary.
if (this.includeAnnotationConfig) {
AnnotationConfigUtils.registerAnnotationConfigProcessors(this.registry);
}
return (this.registry.getBeanDefinitionCount() - beanCountAtScanStart);
}
protected Set<BeanDefinitionHolder> doScan(String... basePackages) {
Assert.notEmpty(basePackages, "At least one base package must be specified");
//创建一个集合，存放扫描到Bean定义的封装类
Set<BeanDefinitionHolder> beanDefinitions = new LinkedHashSet<BeanDefinitionHolder>();
//遍历扫描所有给定的包
for (String basePackage : basePackages) {
//调用父类ClassPathScanningCandidateComponentProvider的方法
//扫描给定类路径，按照过滤规则（默认规则是扫描@Component等）获取符合条件的Bean定义
Set<BeanDefinition> candidates = findCandidateComponents(basePackage);
//遍历扫描到的Bean
for (BeanDefinition candidate : candidates) {
//接下来同样是处理Scope，Bean名字，通用注解
ScopeMetadata scopeMetadata = this.scopeMetadataResolver.resolveScopeMetadata(candidate);
candidate.setScope(scopeMetadata.getScopeName());
String beanName = this.beanNameGenerator.generateBeanName(candidate, this.registry);
if (candidate instanceof AbstractBeanDefinition) {
postProcessBeanDefinition((AbstractBeanDefinition) candidate, beanName);
}
if (candidate instanceof AnnotatedBeanDefinition) {
AnnotationConfigUtils.processCommonDefinitionAnnotations((AnnotatedBeanDefinition) candidate);
}
if (checkCandidate(beanName, candidate)) {
BeanDefinitionHolder definitionHolder = new BeanDefinitionHolder(candidate, beanName);
definitionHolder = AnnotationConfigUtils.applyScopedProxyMode(scopeMetadata, definitionHolder, this.registry);
beanDefinitions.add(definitionHolder);
registerBeanDefinition(definitionHolder, this.registry);
}
}
}
//返回扫到的BeanDefinition
return beanDefinitions;
}
经常用到的注解@ComponentScan，这个注解定义在@Configuration类上，但是register方法注册的时候只是将其载进了BeanDefinition，并没有进行处理，其实对@ComponentScan是进行了调用类似scan方法的过程，但什么时候调的呢？不在register流程中，这个注解到BeanDefinition里并注册到容器后，在refresh的过程中会调用到BeanDefinitionRegistryPostProcessor的postProcessBeanDefinitionRegistry方法，在这个方法执行过程中会处理@ComponentScan注解并载入BeanDefinition进行处理。
还有一个要注意的点，ClassPathXmlApplicationContext在构造时先是setLocations设置路径值（字符串），然后在refresh完成了将路径转化为Resource，并读取Resource成BeanDefinition，还有后面一系列逻辑。而AnnotationConfigApplicationContext在register方法里就将注解转化为了BeanDefinition并注册，refresh里做的事要少一些（符合Generic系的ApplicationContext特征）。
SpringBoot对AnnotationConfigApplicationContext的利用
一般是在Main函数中这么启动SpringBoot的应用的：
SpringApplication.run(Application.class, args);
参数args就是把main函数的参数传递一下，第一个参数是一个类，这个类就是AnnotationConfigApplicationContext需要的annotatedClasses，run函数有重载的，可以传一个annotatedClass数组也可以只传一个：
public static ConfigurableApplicationContext run(Object source, String... args) {
return run(new Object[] { source }, args);
}
public static ConfigurableApplicationContext run(Object[] sources, String[] args) {
return new SpringApplication(sources).run(args);
}
这时候还没用到AnnotationConfigApplicationContext呢，所以参数名先叫sources，后面会传给它的。可以看到调用的SpringApplication的构造函数（new了一个SpringApplication），构造函数主要调用了initialize方法：
private void initialize(Object[] sources) {
if (sources != null && sources.length > 0) {
this.sources.addAll(Arrays.asList(sources));
}
//推断是否是web环境，如果是会专门针对web上下文进行设置
this.webEnvironment = deduceWebEnvironment();
//设置初始化器
setInitializers((Collection) getSpringFactoriesInstances(
ApplicationContextInitializer.class));
//设置监听器
setListeners((Collection) getSpringFactoriesInstances(ApplicationListener.class));
//设置Main函数，这个就是我们写的程序的Main函数
this.mainApplicationClass = deduceMainApplicationClass();
}
新建完SpringApplication马上又调用了它的run方法，这个run方法就不再是一开始从我们main函数调的那些静态方法了，这个是个普通方法，参数只有一个args。
public ConfigurableApplicationContext run(String... args) {
//spring的StopWatch类，可以做类似任务执行时间控制
StopWatch stopWatch = new StopWatch();
stopWatch.start();
//这个引用真正会用到的ApplicationContext，在后面的逻辑中决定用什么
ConfigurableApplicationContext context = null;
FailureAnalyzers analyzers = null;
configureHeadlessProperty();
// spring boot启动监听器
SpringApplicationRunListeners listeners = getRunListeners(args);
listeners.starting();
try {
//将参数包装一下
ApplicationArguments applicationArguments = new DefaultApplicationArguments(
args);
// 准备应用环境
ConfigurableEnvironment environment = prepareEnvironment(listeners,
applicationArguments);
Banner printedBanner = printBanner(environment);
// 创建ApplicationContext
context = createApplicationContext();
analyzers = new FailureAnalyzers(context);
// 准备context
prepareContext(context, environment, listeners, applicationArguments,
printedBanner);
// refresh!
refreshContext(context);
// 后期工作
afterRefresh(context, applicationArguments);
listeners.finished(context, null);
stopWatch.stop();
if (this.logStartupInfo) {
new StartupInfoLogger(this.mainApplicationClass)
.logStarted(getApplicationLog(), stopWatch);
}
return context;
}
catch (Throwable ex) {
handleRunFailure(context, listeners, analyzers, ex);
throw new IllegalStateException(ex);
}
}
终于用到AnnotationConfigApplicationContext了，就在createApplicationContext()方法里：
protected ConfigurableApplicationContext createApplicationContext() {
Class<?> contextClass = this.applicationContextClass;
if (contextClass == null) {
try {
//若非Web环境，那么就用AnnotationConfigApplicationContext
contextClass = Class.forName(this.webEnvironment
? DEFAULT_WEB_CONTEXT_CLASS : DEFAULT_CONTEXT_CLASS);
}
catch (ClassNotFoundException ex) {
throw new IllegalStateException(
"Unable create a default ApplicationContext, "
+ "please specify an ApplicationContextClass",
ex);
}
}
return (ConfigurableApplicationContext) BeanUtils.instantiate(contextClass);
}
没错，DEFAULT_CONTEXT_CLASS的值就是"org.springframework.context.annotation.AnnotationConfigApplicationContext"。
至于Web环境在spring boot里就是用的AnnotationConfigEmbeddedWebApplicationContext，这个类还有AnnotationConfigWebApplicationContext都是相应的衍生。
剩下的就是spring boot去初始化和维护这个容器了。
