-
前言
上文已经介绍了配置资源和环境初始化的过程。本节只讲解createApplicationContext上下文应用创建。
文章基于springboot2.3.x系列的源码（大部分以jar包中的源码为例讲解），github的源码与实际发版的可能略微不同，不过整体流程差别不大。
本人第一次写文章，如有错误或误导欢迎留言指正。文章整体可能比较啰嗦，尽可能的将流程中的每一个重要的方法都讲到。 -
createApplicationContext 创建上下文应用
源码：
protected ConfigurableApplicationContext createApplicationContext() { Class<?> contextClass = this.applicationContextClass; if (contextClass == null) { try { switch(this.webApplicationType) { case SERVLET: contextClass = Class.forName("org.springframework.boot.web.servlet.context.AnnotationConfigServletWebServerApplicationContext"); break; case REACTIVE: contextClass = Class.forName("org.springframework.boot.web.reactive.context.AnnotationConfigReactiveWebServerApplicationContext"); break; default: contextClass = Class.forName("org.springframework.context.annotation.AnnotationConfigApplicationContext"); } } catch (ClassNotFoundException var3) { throw new IllegalStateException("Unable create a default ApplicationContext, please specify an ApplicationContextClass", var3); } } return (ConfigurableApplicationContext)BeanUtils.instantiateClass(contextClass); }webApplicationType默认值为SERVLET，这里对应会获取AnnotationConfigServletWebServerApplicationContext的class对象。通过BeanUtils.instantiateClass实例化对象，其实直接通过new创建出来效果一样，并且在以后版本的源码中是直接使用new创建的。这个类的作用通过名称也可以知道，是基于注解形式的web上下文应用构建。与之相对应的是xml方式XmlServletWebServerApplicationContext。
先看一下这个关键类的uml图：
这里图片上的字比较小，如果看不清也可以通过自己的idea去查看。关系比较复杂，但是可以在图上看到几个常见的类。BeanFactory、ResourceLoader、lifecycle等。可以看出顶层的都是接口，下面的实现类也相互交叉，其公共的父类之一是ApplicationContext接口。
-
AnnotationConfigServletWebServerApplicationContext 初始化
这里开始我们需要去了解AnnotationConfigServletWebServerApplicationContext的自身和其父类，因为到这里开始，有很多初始化动作已经在构造函数内进行了。
从自身开始：
public class AnnotationConfigServletWebServerApplicationContext extends ServletWebServerApplicationContext implements AnnotationConfigRegistry { private final AnnotatedBeanDefinitionReader reader; private final ClassPathBeanDefinitionScanner scanner; private final Set<Class<?>> annotatedClasses; private String[] basePackages; public AnnotationConfigServletWebServerApplicationContext() { this.annotatedClasses = new LinkedHashSet(); this.reader = new AnnotatedBeanDefinitionReader(this); this.scanner = new ClassPathBeanDefinitionScanner(this); } ...... //还有其他的构造函数，这里我们只选启动流程默认的无参构造函数 }构造函数内初始化3个参数，其中 AnnotatedBeanDefinitionReader和 ClassPathBeanDefinitionScanner 是两个非常关键的类。一个是基于注解的bean定义，一个是基于路径的bean扫描。
我们老样子逐个进行分析。从这里也开始了无限套娃模式。说实话spring系列的源码写的真的很好，但也真的很难读懂。
AnnotatedBeanDefinitionReader：
从构造函数开始：public AnnotatedBeanDefinitionReader(BeanDefinitionRegistry registry) { this(registry, getOrCreateEnvironment(registry)); } public AnnotatedBeanDefinitionReader(BeanDefinitionRegistry registry, Environment environment) { //基于产生bean的注解，若没有指定bean的名称将会自动生成一个首字母小写的名称作为bean的名称 this.beanNameGenerator = AnnotationBeanNameGenerator.INSTANCE; //Scop的代理模式 this.scopeMetadataResolver = new AnnotationScopeMetadataResolver(); Assert.notNull(registry, "BeanDefinitionRegistry must not be null"); Assert.notNull(environment, "Environment must not be null"); //这里指的是当前的环境变量 this.registry = registry; //条件注入bean this.conditionEvaluator = new ConditionEvaluator(registry, environment, (ResourceLoader)null); AnnotationConfigUtils.registerAnnotationConfigProcessors(this.registry); } private static Environment getOrCreateEnvironment(BeanDefinitionRegistry registry) { Assert.notNull(registry, "BeanDefinitionRegistry must not be null"); return (Environment)(registry instanceof EnvironmentCapable ? ((EnvironmentCapable)registry).getEnvironment() : new StandardEnvironment()); }先看一下getOrCreateEnvironment方法：
方法主要是判断了一下当前AnnotationConfigServletWebServerApplicationContext是否是EnvironmentCapable子类，若是则返回当前环境对象，若不是则初始化一个StandardEnvironment。EnvironmentCapable主要是判断当前上限文是否具有提供环境属性的能力。内部只有一个getEnvironment方法，原设计是获取一个不可修改的环境对象。但是在ConfigurableApplicationContext对其进行了重写，使获取的对象具有可再次定制的能力。
吐槽一下很有迷惑的入参BeanDefinitionRegistry，这个接口与EnvironmentCapable没有任何的关系，BeanDefinitionRegistry相当于我们在写代码时用的Object接受参数一样，是ApplicationContext的父类。但是方法内直接进行了类型强转，虽然也没有错。
AnnotationBeanNameGenerator:
基于注解生成bean的名称。若注解指定了则使用注解内的，否则默认将类名的首字母变成小写作为名称。
AnnotationScopeMetadataResolver:
设置bean的代理模式，即我们常用的@Scop注解的实现。在其构造函数内默认设置ScopedProxyMode.NO 不使用代理。也就是单例模式，即bean是全局唯一的这样可以避免反复的创建bean，提升服务性能，但也存在线程安全问题，其实很好理解，单例的bean也意味着若存在全局变量，就不能随意更改否则变更后会有影响。
ScopedProxyMode共有四种类型：
DEFAULT：等同于NO，不使用代理的单例模式。
NO：单例模式
INTERFACES：jdk动态代理
TARGET_CLASS：CGLAB动态代理
ConditionEvaluator:
自定义创建bean条件，注解@Condition的处理类。可以按照条件进行类加载，条件需要单独定义，并实现
Condition接口。
例如：
public class MyCondition implements Condition {
@Override
public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
....
return true;
}
}
@Conditional({ MyCondition.class })
@Configuration
public class MyConfig {
@Bean
@Conditional({ MyCondition.class })
public Date date() {
return new Date();
}
}
在springboot项目中很少使用了，springboot提供了更多的@Condition的扩展注解，例如：@ConditionalOnMissingBean，@ConditionalOnProperty，@ConditionalOnBean等。
AnnotationConfigUtils.registerAnnotationConfigProcessors:
在给定的注册表中注册所有相关的注解后处理器。比如提供@Autowired,@Value,@Order等注解的支持。所谓的后处理器，其实就是相关注解的支持类。
源码：
public static Set<BeanDefinitionHolder> registerAnnotationConfigProcessors(
BeanDefinitionRegistry registry, @Nullable Object source) {
//获取bean工厂 若是springboot我们这里已经知道其为 DefaultListableBeanFactory
DefaultListableBeanFactory beanFactory = unwrapDefaultListableBeanFactory(registry);
if (beanFactory != null) {
//加载顺序机制
if (!(beanFactory.getDependencyComparator() instanceof AnnotationAwareOrderComparator)) {
beanFactory.setDependencyComparator(AnnotationAwareOrderComparator.INSTANCE);
}
//决定一个bean定义是否应该被视为自动装配的候选时，为这个BeanFactory设置一个自定义的自动装配候选解析器
if (!(beanFactory.getAutowireCandidateResolver() instanceof ContextAnnotationAutowireCandidateResolver)) {
beanFactory.setAutowireCandidateResolver(new ContextAnnotationAutowireCandidateResolver());
}
}
Set<BeanDefinitionHolder> beanDefs = new LinkedHashSet<>(8);
//验证是否包含名称org.springframework.context.annotation.internalConfigurationAnnotationProcessor的bean
//若没有则通过registerPostProcessor方法添加到registry中
if (!registry.containsBeanDefinition(CONFIGURATION_ANNOTATION_PROCESSOR_BEAN_NAME)) {
//将需要注册的bean手动封装成RootBeanDefinition里面，用于描述bean的属性和对bean进行操作
//@configuration支持
RootBeanDefinition def = new RootBeanDefinition(ConfigurationClassPostProcessor.class);
def.setSource(source);
beanDefs.add(registerPostProcessor(registry, def, CONFIGURATION_ANNOTATION_PROCESSOR_BEAN_NAME));
}
if (!registry.containsBeanDefinition(AUTOWIRED_ANNOTATION_PROCESSOR_BEAN_NAME)) {
//@Autowired、Value注解支持
RootBeanDefinition def = new RootBeanDefinition(AutowiredAnnotationBeanPostProcessor.class);
def.setSource(source);
beanDefs.add(registerPostProcessor(registry, def, AUTOWIRED_ANNOTATION_PROCESSOR_BEAN_NAME));
}
// Check for JSR-250 support, and if present add the CommonAnnotationBeanPostProcessor.
//JSR-250是一个标准，可以理解为java的约定或者说预留的注解，网上的定义为资源相关的处理
if (jsr250Present && !registry.containsBeanDefinition(COMMON_ANNOTATION_PROCESSOR_BEAN_NAME)) {
RootBeanDefinition def = new RootBeanDefinition(CommonAnnotationBeanPostProcessor.class);
def.setSource(source);
beanDefs.add(registerPostProcessor(registry, def, COMMON_ANNOTATION_PROCESSOR_BEAN_NAME));
}
// Check for JPA support, and if present add the PersistenceAnnotationBeanPostProcessor.
// JPA约定
if (jpaPresent && !registry.containsBeanDefinition(PERSISTENCE_ANNOTATION_PROCESSOR_BEAN_NAME)) {
RootBeanDefinition def = new RootBeanDefinition();
try {
def.setBeanClass(ClassUtils.forName(PERSISTENCE_ANNOTATION_PROCESSOR_CLASS_NAME,
AnnotationConfigUtils.class.getClassLoader()));
}
catch (ClassNotFoundException ex) {
throw new IllegalStateException(
"Cannot load optional framework class: " + PERSISTENCE_ANNOTATION_PROCESSOR_CLASS_NAME, ex);
}
def.setSource(source);
beanDefs.add(registerPostProcessor(registry, def, PERSISTENCE_ANNOTATION_PROCESSOR_BEAN_NAME));
}
//异步监听器
if (!registry.containsBeanDefinition(EVENT_LISTENER_PROCESSOR_BEAN_NAME)) {
RootBeanDefinition def = new RootBeanDefinition(EventListenerMethodProcessor.class);
def.setSource(source);
beanDefs.add(registerPostProcessor(registry, def, EVENT_LISTENER_PROCESSOR_BEAN_NAME));
}
//监听器工厂
if (!registry.containsBeanDefinition(EVENT_LISTENER_FACTORY_BEAN_NAME)) {
RootBeanDefinition def = new RootBeanDefinition(DefaultEventListenerFactory.class);
def.setSource(source);
beanDefs.add(registerPostProcessor(registry, def, EVENT_LISTENER_FACTORY_BEAN_NAME));
}
return beanDefs;
}
源码看起来比较多 但实际上逻辑很简单，为了初始化一些spring自身资源类注解的支持，并注入成bean。类似于@Resource，@Value等，bean内属性的注入，并非@Service的类级注解。
格外提一点扩展知识,上面的源码中能看到一个jsr250Present 和 jpaPresent 着其实是java的两个约定。感兴趣的可以去了解一下，我只说一点，比如：比如我们知道@Resource和@Autowired在很多情况下是可以互换的。
但是@Resource并非spring的注解，而是java自带的。很早以前就很困惑，为何spring要提供一个java自身注解的支持，难道不会和其他的框架或者jar冲突吗？然而事实上的确会冲突，但这个@Resource是java制定的资源加载约定注解，相当于我提供了一个接口在这，并且我建议你们遵循这个约定去实现它。
这样的注解不止@Resource一个，感兴趣的可以去了解一下。同理JPA也类似。
单看方法的话会有点奇怪，这里的返回值不重要，关键是registerPostProcessor方法。
源码：
private static BeanDefinitionHolder registerPostProcessor(
BeanDefinitionRegistry registry, RootBeanDefinition definition, String beanName) {
definition.setRole(BeanDefinition.ROLE_INFRASTRUCTURE);
//注入bean
registry.registerBeanDefinition(beanName, definition);
return new BeanDefinitionHolder(definition, beanName);
}
方法内registry.registerBeanDefinition注册了spring的内部bean。
这里讲解的顺序有问题，下一篇我们将从顶层往下看，这篇是从底层往上看因此，会有点莫名其妙。若看过源码或调试过的小伙伴应该知道到这里的时候其实已经知道了，当前上下文中使用的beanFactory是DefaultListableBeanFactory 这是一个非常关键的类，bean的整个加载流程都在内部，包括所谓的IOC容器，其实就是一个Map，这些都是后话了。
AnnotatedBeanDefinitionReader类的解析告一段落。
ClassPathBeanDefinitionScanner:
AnnotatedBeanDefinitionReader实现了bean内属性的组装。ClassPathBeanDefinitionScanner实现的是bean的扫描和加载。
构造函数源码：
public ClassPathBeanDefinitionScanner(BeanDefinitionRegistry registry, boolean useDefaultFilters, Environment environment, @Nullable ResourceLoader resourceLoader) {
.... 与AnnotatedBeanDefinitionReader相同
this.registry = registry;
if (useDefaultFilters) {
this.registerDefaultFilters();
}
}
protected void registerDefaultFilters() {
//设置Component注解过滤器
this.includeFilters.add(new AnnotationTypeFilter(Component.class));
ClassLoader cl = ClassPathScanningCandidateComponentProvider.class.getClassLoader();
try {
this.includeFilters.add(new AnnotationTypeFilter(ClassUtils.forName("javax.annotation.ManagedBean", cl), false));
this.logger.trace("JSR-250 'javax.annotation.ManagedBean' found and supported for component scanning");
} catch (ClassNotFoundException var4) {
}
try {
this.includeFilters.add(new AnnotationTypeFilter(ClassUtils.forName("javax.inject.Named", cl), false));
this.logger.trace("JSR-330 'javax.inject.Named' annotation found and supported for component scanning");
} catch (ClassNotFoundException var3) {
}
}
提供：Component、Repository、Service、Controller注解的支持,源码中只看到了配置Component，因为其他几个注解都基于Component扩展的,另外提供了javaEE 6的ManagedBean注解和JSR-330的Named注解支持。
感兴趣的可以去了解一下 JSR和JPA协议。
AnnotationConfigServletWebServerApplicationContext 类讲解到此结束。
回到上面UMl图，可以看到其拥有一个复杂的继承关系，并且上面也留了一个疑问，加载过程中的beanFactory是在什么地方初始化的？
下面将依次看一下其父类的无参构造函数都做了啥（接口除外），大部分接口内部没有逻辑代码。
按从下往上的方式去看:
ServletWebServerApplicationContext 无操作。
GenericWebApplicationContext 无操作
GenericApplicationContext
源码：
public GenericApplicationContext() {
this.customClassLoader = false;
this.refreshed = new AtomicBoolean();
// 初始化bean工厂
this.beanFactory = new DefaultListableBeanFactory();
}
这里已经知道上下文中使用的beanFactory是DefaultListableBeanFactory类
AbstractApplicationContext
源码：
public AbstractApplicationContext() {
this.logger = LogFactory.getLog(this.getClass());
this.id = ObjectUtils.identityToString(this);
this.displayName = ObjectUtils.identityToString(this);
this.beanFactoryPostProcessors = new ArrayList();
this.active = new AtomicBoolean();
this.closed = new AtomicBoolean();
this.startupShutdownMonitor = new Object();
this.applicationListeners = new LinkedHashSet();
//特殊资源路径的加载处理，非classpath*:下的资源，如：file:C:/context.xml
this.resourcePatternResolver = this.getResourcePatternResolver();
}
DefaultResourceLoader
源码：
public DefaultResourceLoader() {
this.classLoader = ClassUtils.getDefaultClassLoader();
}
-
DefaultListableBeanFactory解析
构造函数源码：
注释理解来自于源码：
public DefaultListableBeanFactory() {
// 用于检查bean定义是否为自动装配候选的解析程序
this.autowireCandidateResolver = SimpleAutowireCandidateResolver.INSTANCE;
//从依赖项类型映射到相应的自动装配值
this.resolvableDependencies = new ConcurrentHashMap(16);
//Bean定义对象的映射，以Bean名称为键。
this.beanDefinitionMap = new ConcurrentHashMap(256);
//根据名称合并 BeanDefinitionHolder持有的bean
this.mergedBeanDefinitionHolders = new ConcurrentHashMap(256);
//单例和非单例Bean名称的映射，按依赖项类型进行键控
this.allBeanNamesByType = new ConcurrentHashMap(64);
//仅依赖单例的bean名称的映射，按依赖项类型进行键控
this.singletonBeanNamesByType = new ConcurrentHashMap(64);
//Bean定义名称列表，按注册顺序
this.beanDefinitionNames = new ArrayList(256);
//手动注册的单例的名称列表，按注册顺序。
this.manualSingletonNames = new LinkedHashSet(16);
}
这个是jar包中的源码，若从github获取的源码构造函数内可能并没有，而是通过饿汉式的模式直接在定义属性的时候就初始化了，这样虽然写着方便，但看着并不直观。
构造函数内初始化的Map们就是口中常说的IOC容器
那么bean的循环依赖时如何被解决的呢？先留一个疑问，在将bean加载的流程时候再说。
DefaultListableBeanFactory也有着很复杂的继承关系，下面将结合UML图进行讲解。
只看图中蓝色的实体类继承关系。逐个类的构造函数查看。构造函数未必都是无参的，具体执行的哪一个要看子类是否有传入特定参数。
一般情况下，在非工具的实体类中很少有 static 的静态代码块，因此不需要刻意去寻找。一般都是通过构造函数完成初始化。
AbstractAutowireCapableBeanFactory
源码：
public AbstractAutowireCapableBeanFactory() {
//基于CGLB的bean动态代理创建（策略模式）
this.instantiationStrategy = new CglibSubclassingInstantiationStrategy();
//获取方法或构造函数的参数名称，这里默认通过java反射机制
this.parameterNameDiscoverer = new DefaultParameterNameDiscoverer();
//是否自动尝试解析bean之间的循环依赖
this.allowCircularReferences = true;
//在循环依赖的时候，是否可以注入原始的bean，应该是为进行属性赋值的原始bean
this.allowRawInjectionDespiteWrapping = false;
//根据类型忽略相关的实现
this.ignoredDependencyTypes = new HashSet();
//忽略相关接口
this.ignoredDependencyInterfaces = new HashSet();
// 当前创建的bean的名称，用于隐式依赖项注册
// 从用户指定的Supplier回调触发的getBean等调用上
this.currentlyCreatedBean = new NamedThreadLocal("Currently created bean");
//未完成的FactoryBean实例的缓存：BeanWrapper的FactoryBean名称
this.factoryBeanInstanceCache = new ConcurrentHashMap();
//按工厂类别缓存候选工厂方法
this.factoryMethodCandidateCache = new ConcurrentHashMap();
//过滤后的PropertyDescriptor的缓存：Bean类到PropertyDescriptor数组。
this.filteredPropertyDescriptorsCache = new ConcurrentHashMap();
this.ignoreDependencyInterface(BeanNameAware.class);
this.ignoreDependencyInterface(BeanFactoryAware.class);
this.ignoreDependencyInterface(BeanClassLoaderAware.class);
}
源码中初始化了bean的代理模式、bean循环依赖处理配置，以及缓存bean的相关工厂信息。
最后忽略了BeanNameAware、BeanFactoryAware 、 BeanClassLoaderAware三个接口的相关类。
暂时原因并不清楚，为何要排除。这里暂时先不说，等说道bean加载的时候在说。
小结
本文主要讲解了上下文构建类的初始化过程，到此仍在进行bean加载前的准备工作。上篇文章中初始化的环境对象被注入到上限文类中，继续推进初始化流程。
本文主要几点:
1.资源类注解@Resouce、@Value等，背后的支持类初始化完成。
2.bean加载相关注解，@Component、@Service，背后的支持类初始化。
3.基于condition的条件注入
4.DefaultListableBeanFactory工厂类的初始化。所谓IOC容器也是在这里进行初始化。且内部涉及到bean的循环依赖配置。
存留问题：
1.为何要在工厂类初始化的时候，移除BeanNameAware、BeanFactoryAware 、 BeanClassLoaderAware三个接口的加载？
2.spring如何解决循环依赖的问题
3.未完成的bean是如何保存的
