Spring框架(三) Ben生命周期源码解析

感兴趣的话大家可以关注一下公众号 : 猿人刘先生 , 欢迎大家一起学习 , 一起进步 , 一起来交流吧!

本篇文章主要说明的是一个Bean是在Spring中如何创建的 , 也就是Bean的生命周期 , ​ 在传统的Java应用中，bean的生命周期很简单，使用Java关键字 new 进行Bean 的实例化，然后该Bean 就能够使用了。一旦bean不再被使用，则由Java自动进行垃圾回收。

​ 相比之下，Spring管理Bean的生命周期就复杂多了，正确理解Bean 的生命周期非常重要，因为Spring对Bean的管理可扩展性非常强 , 接下来我们慢慢的分析

流程图

我们可以先来看一下Bean生命周期的流程图 , 也就是一个Bean在创建的过程中经历了这些步骤

其实结合前面两篇文章的内容 , 我们也可以知道大概在Spring容器启动的时候 , 大概会做两件事情
1.扫描
2.创建非懒加载单例Bean

一.扫描

除了Spring启动等扫描可以说是Bean生命周期的第一步 , 扫描哪些类实现需要成为Bean的 , 我只有先扫描到哪些类是需要成为Bean的 , 我才能进行实例化 , 依赖注入 , 初始化等等步骤 , 而在构造方法的this()方法中会初始化读取器和扫描器
那么扫描的逻辑就是在扫描器ClassPathBeanDefinitionScanner中的scan()方法 , scan()方法会调用doScan()真正的逻辑是在doScan()中

我们来看doScan()方法

protected Set<BeanDefinitionHolder> doScan(String... basePackages) 

首先doScan()方法需要一个入参 , 也就是一个包路径 , 然后Spring会调用findCandidateComponents()方法然后进行扫描 ,然后解析并得到一个BeanDefinition的集合

Set<BeanDefinition> candidates = findCandidateComponents(basePackage);

我们再来看findCandidateComponents()方法

索引文件

上面的if的作用就是判断你是否定义了索引文件 , 因为这样扫描所有的class从而判断你是否能成为一个Bean的方式相对来说比较慢 , 那么Spring也提供了一种机制, 就是定义索引文件

比如这样定义一个配置文件

然后加入如下内容

com.lyh.service.UserService=org.springframework.stereotype.Component

这样的话就相当于直接定义我当前这个项目里边有哪些Bean , 就相当于直接告诉Spring , 我UserService这个类上有@Component注解 , 那么Spring会怎么做呢?

它会判断你有没有索引 , 也就是上面定义的spring.components文件 , 如果有调用addCandidateComponentsFromIndex()方法来解析 , 我们来看看这个方法

进来之后 , 我们会发现它首先循环你定义的过滤的内容 ,比如我定义的就是一个过滤component的一个过滤器

String stereotype = extractStereotype(filter);

然后它就会拿到你过滤的这个注解 , 也就是@Conponent

types.addAll(index.getCandidateTypes(basePackage, stereotype));

getCandidateTypes()方法就是获取配置文件的内容 ,然后过滤

然后它会把符合的类型都放到一个集合 , 然后使用元数据读取器解析, 并使用ScannedGenericBeanDefinition封装成为BeanDefinition , 当然UserService也是要加@Component注解的

其实简单一点就是之前Spring不知道你那个类需要成为Bean , 所以对所有文件进行扫描, 现在你在配置文件直接告诉Spring , 然后Spring取到你配置文件的内容 , 然后解析封装成为BeanDefintion , 然后扫描完成了 , 不明白的话直接debug一波, 就清楚啦

默认情况下我们进的是下面的分析 , 也就是else的分支 , 我们来看scanCandidateComponents()方法:

1.构造一个LinkedHashSet , 用来存放最后扫描的结果

Set<BeanDefinition> candidates = new LinkedHashSet<>();

2.解析包路径

// 获取basePackage下所有的文件资源
String packageSearchPath = ResourcePatternResolver.CLASSPATH_ALL_URL_PREFIX +
					resolveBasePackage(basePackage) + '/' + this.resourcePattern;
Resource[] resources = getResourcePatternResolver().getResources(packageSearchPath);

CLASSPATH_ALL_URL_PREFIX

this.resourcePattern

resolveBasePackage()方法的作用是将 . 替换为 /

比如说我们的包名是 : com.lyh.service
那么解析之后的包路径就是 : “classpath*:com/lyh/service/**/*.class”
然后根据解析得到的包路径并利用ResourcePatternResolver资源加载器来加载资源

加载资源的就是包路径下的class文件
得到的就是一个一个的class文件的file对象

3.将class解析为元数据读取器

第2步通过包路径然后加载class文件 , 并存放到一个数组中 , 也就是Resource[] , 然后遍历这个数组 , 如果当前资源可以读 , 那么就会把这个类解析为一个资源读取器

// 参数resource为当前正在遍历的资源
MetadataReader metadataReader = getMetadataReaderFactory().getMetadataReader(resource);

这样解析为一个元数据读取器之后 ,这个读取器就可以读取当前这个资源的信息 , 比如一些注解的信息 , 一些类的名称 , 是否是抽象类 , 包括这个类实现的接口等等一系列东西

它的底层使用的是ASM技术

4.过滤

这个过滤也就是过滤的我们通过以下这种方式排除或符合的Bean

@ComponentScan(value = "com.lyh",
  excludeFilters = {@ComponentScan.Filter(
             type = FilterType.ASSIGNABLE_TYPE, 
             classes = UserService.class)}.)
public class AppConfig {
}

也就是这个判断 , 我们点进去isCandidateComponent()方法看一下底层实现

@ComponentScan(value = "com.lyh",
  includeFilters = {@ComponentScan.Filter(
             type = FilterType.ASSIGNABLE_TYPE, 
             classes = UserService.class)})
public class AppConfig {
}
​

if (isCandidateComponent(metadataReader))

他在这里会判断如果是否需要排除或者符合条件的Bean , 只有符合条件的Bean才会真正的成为Bean , 如果有@Component注解 , 那么就会进入到isConditionMatch()方法来判断 , 然后重要的就是这个shouldSkip()方法

它会判断你是否有@Conditional注解 , 如果没有就跳过

如果有@Conditional注解 , 它会解析注解的条件是否匹配 , 如果匹配 , 那么就不跳过, 如果不匹配 , 那么就跳过, 就表示不能成为一个Bean

5.判断是否是顶级类或接口等

if (isCandidateComponent(sbd))

metadata.isIndependent() : 判断是否是顶级类或者是内部类
metadata.isConcrete() : 判断是否是接口或者是抽象类
metadata.isAbstract() && metadata.hasAnnotatedMethods(Lookup.class.getName()))) : 如果是抽象类但是这个抽象类内部有随便一个方法加了@Lookup注解 , 那么它也可以成为一个Bean

@Lookup注解

我们通过一个demo来演示这个注解的作用
新建一个User类 , 并且使他的作用域为原型

@Component
@Scope(scopeName = "prototype")
public class User {
	
}

@Component
public class UserService {


	@Resource
	private User user;

	public void test1(){
		System.out.println("user : " + user);
	}
}	

然后我们这样多调用几次 , 那么每次输出user的值会一样吗?

public class TestSpring {

	public static void main(String[] args){

		AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
		// 返回getObject()方法返回的Bean
		UserService userService = (UserService)applicationContext.getBean("userService");
		userService.test1();
		userService.test1();
		userService.test1();
		userService.test1();
	}
}	

测试发现, 它们的值相同 , 为什么呢?

因为UserService是单例的 , 所以user也只会被赋一次值 , 那么如果想要体现出原型的效果 , 怎么做呢?

把UserService这样改造一下

@Component
public class UserService {

	@Resource
	private User user;

	public void test1(){
		System.out.println("user : " + a());
	}

	@Lookup("user")
	public User a(){
		return null;
	}

定义一个方法 , 然后加上@Lookup注解

这个时候就体现除了原型的效果, 关于@Lookup注解的源码 , 我会在后续的文章来解释 , 此处只明白它的用法就行

6.添加扫描过滤结果到集合

最开始不是定义了一个BeanDefinition的集合吗, 如果第五步的判断也通过了 , 难么就添加到这个集合 , 并返回

到此为止 , 也扫描到了好多类 , 也生成了Beanfinition ,而现在的Beanfinition只有一个BeanClass属性 ,其他的属性还没有解析 , 然后我们在回到doScan()方法来看 , 刚刚我们说的是这个方法

我们接着往下看

7.解析Scope属性

ScopeMetadata scopeMetadata = this.scopeMetadataResolver.resolveScopeMetadata(candidate);
candidate.setScope(scopeMetadata.getScopeName());

然后我们进入到这个实现类

我们可以看到 , 它就会解析Scope注解 , 然后放到Meta中,

然后设置到BeanDefinition中

8.生成Bean的名字

String beanName = this.beanNameGenerator.generateBeanName(candidate, this.registry);

我们进入到generateBeanName()方法 , 点进入这个类

它会获取你注解上指定的名称 , 就比如这样定义@Component(“user”)

接着看isStereotypeWithNameValue()方法
它就会判断你是否定义了这些注解

COMPONENT_ANNOTATION_CLASSNAME : org.springframework.stereotype.Component

如果有的话 , 它就会取你这个注解的值

Object value = attributes.get("value");

那么我得到的这个value就是Bean的名称 , 如果写了@Component但是没有指定值 , 那么就会返回空 , 因为beanName属性默认是空 , 如果是空 , 那么它就会默认去生成
也就是下面这一段

然后点进入buildDefaultBeanName()方法, 直到下面的方法 , 它就会把类的首字母小写 , 作为Bean的名称


如果长度大于1 , 并且类的第一个第二字字母都是大写 , 那么就直接返回, 就是比如我们定义了一个名为这样的类 : ABtest , 那么这个类的名称就是ABtest
否则的话就将首字母小写 , 然后返回

9.是否实现了AbstractBeanDefinition接口

if (candidate instanceof AbstractBeanDefinition) {
	postProcessBeanDefinition((AbstractBeanDefinition) candidate, beanName);
}

如果实现了AbstractBeanDefinition接口, 那么它会给当前BeanDefinition赋一些默认值

10.是否实现了AnnotatedBeanDefinition接口

if (candidate instanceof AnnotatedBeanDefinition) {
	// 解析@Lazy、@Primary、@DependsOn、@Role、@Description
	AnnotationConfigUtils.processCommonDefinitionAnnotations((AnnotatedBeanDefinition) candidate);
}

如果实现了AnnotatedBeanDefinition , 那么它就会解析@Lazy、@Primary、@DependsOn、@Role、@Description这些注解 ,我们来看看processCommonDefinitionAnnotations()方法

相关注解的作用我都会放在后面来说明

11.检查Spring容器中是否存在该Bean

	if (checkCandidate(beanName, candidate)) {
		BeanDefinitionHolder definitionHolder = new BeanDefinitionHolder(candidate, beanName);
		definitionHolder = AnnotationConfigUtils.applyScopedProxyMode(scopeMetadata, definitionHolder, this.registry);
		beanDefinitions.add(definitionHolder);
        // 注册
		registerBeanDefinition(definitionHolder, this.registry);
   }

那么注册会注册到哪呢?
我们点进来看一下registerBeanDefinition()方法 , 进入到下面这个方法

我们会看到这样一行代码

也就是说注册到了Map中 , 这个Map之前的文章中有提到过 , 可以把这个Map理解为Spring容器 , 也可以把单例池理解为Spring容器

this.beanDefinitionMap.put(beanName, beanDefinition);

所以它检查的时候就会判断根据beanName去beanDefinitionMap中判断

可以看到, 如果存在的话就抛了异常 , 也就是Bean的名称重复了
那isCompatible()方法又是什么意思呢?
我们把AppConfig复制一份 , 不需要改变任何内容
然后我们这样来测试

public class TestSpring {

	public static void main(String[] args){

		AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext();
		applicationContext.register(AppConfig.class);
		applicationContext.register(AppConfig1.class);
		applicationContext.refresh();
	}
}

它这里会扫描两次, 因为AppConfig和AppConfig1的内容是相同的, 那么扫描两次 , 按照上面的逻辑 , beanName冲突不是会报错吗 , 这里测试发现是不会报错的 , 那么为什么呢?就是因为isCompatible()方法它会判断这两个Bean的source是不是相同 , 如果相同 , 那么就不会注册第二次了, 所以就没有问题

到此为止 , 扫描的主要逻辑就讲完了 , 上面我们还遗留了一点小问题

二.实例化非懒加载单例Bean

我们直接来看refresh()的finishBeanFactoryInitialization()方法的beanFactory.preInstantiateSingletons();这个方法

1.合并BeanDefinition

在哪里体现是非懒加单例Bean呢?

if (!bd.isAbstract() && bd.isSingleton() && !bd.isLazyInit())

它就会判断是不是单例, 是不是懒加载, 如果不是 , 就不会做任何操作
而 !bd.isAbstract() 这个并不是判断是否是抽象类 , 而是判断是否是抽象的BeanDefinition , 那么抽象的BeanDefinition一般是通过xml的方式来定义的 , 比如这样定义

也就是说抽象的BeanDefinition是不会创建Bean的

那么抽象的BeanDefinition有什么作用呢?比如我们在xml是这样定义的

这个时候虽然userService是单例的 , 但是由于它继承了id为member的 BeanDefinition(注意这里是继承BeanDefinition , 并不是继承类) , 所以userService也就成为了原型 , 虽然抽象BeanDefinition不能生成Bean , 但是继承它的BeanDefinition可以成为 Bean , 这就是它的作用 , 而这个userService成为原型的过程被称为合并BeanDefinition , 也就是这行代码

RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName);

它会合并父子BeanDefinition , 如果子类自己没有定义 , 那么就会用父类的 , 如果子类定义了 , 那么就用自己的 , 而合并BeanDefinition 会产生第三个BeanDefinition , 而 并非改之前的BeanDefinition , 因为可能一个父BeanDefinition被好多个类继承 , 如果改了父BeanDefinition , 那么其他子类也就一块跟着改了 , 所以合并不会 修改原来的BeanDefinition , 只会产生新的 , 而新的BeanDefinition就称为RootBeanDefinition

2.创建非懒加载单例Bean

如果通过非懒加载的条件之后 ,它他会判断当前bean是否是一个FactoryBean , 如果不是一个FactoryBean , 那么就会调用getBean()创建非懒加载单例Bean

那么他它是怎么判断是否是一个FactoryBean的呢?

首先它会转换名字 , 就是截取&符号
逻辑大概分为三段
1.从单例池获取Bean的实例 , 如果实现了FactoryBean接口接口 , 那么就是一个FactoryBean
2.如果从单例池获取不到 , 就会判断父Bean工厂有没有
3.如果单例池没有 , 那么就根据BeanDefinition的类型去判断（获取BeanDefinition的beanClass属性) , 代码如下

然后缓存一下这个属性

mbd.isFactoryBean = result;

下一次再来判断的时候就会

Boolean result = mbd.isFactoryBean;

直接获取

如果是一个FactoryBean , 那么就会去创建一个Bean , 这个对象就是实现了FactoryBean的这个Bean

// FACTORY_BEAN_PREFIX  : &
Object bean = getBean(FACTORY_BEAN_PREFIX + beanName);

比如上篇文章我们讲的FactoryBean会创建两个对象

// 创建两个对象 , 一个是LyhFactoryBean  , 一个是getObject()方法返回的
public class LyhFactoryBean implements FactoryBean {

比如这里Object bean = getBean(FACTORY_BEAN_PREFIX + beanName);创建的就是LyhFactoryBean ,并把这个创建好的Bean强转为FactoryBean

isEagerInit = (factory instanceof SmartFactoryBean &&
  ((SmartFactoryBean<?>) factory).isEagerInit());

如果实现了SmartFactoryBean , 并且isEagerInit()返回true , 才会调用getBean()去创建getObject()返回的Bean

@Component
public class LyhFactoryBean implements SmartFactoryBean {


	@Override
	public boolean isEagerInit() {
		return true;
	}

	@Override
	public Object getObject() throws Exception {
		return new UserService();
	}

	@Override
	public Class<?> getObjectType() {
		return UserService.class;
	}
}

说白了就是如果实现了SmartFactoryBean并且isEagerInit()返回true , 那么它才会调用getBean()去创建 getObject()对象

3.执行SmartInitializingSingleton

所有非懒加载单例Bean创建完毕之后 , 它会根据Bean名称获取到单例Bean的实例,

Object singletonInstance = getSingleton(beanName);

然后判断是否实现了SmartInitializingSingleton , 如果实现了 , 那么就执行afterSingletonsInstantiated()方法

三.获取或创建Bean

上面说了扫描和解析以及实例化非懒加载单例Bean , 下面我们说一下Bean的获取以及获取不到时的创建

首先就是转换BeanName , 然后从单例池获取 ,能获取到就返回 , 获取不到呢? 也就是这段else的逻辑

它判断这个Bean是否有对应的BeanDefinition , 如果没有的话 , 就转换一下BeanName然后去父Bean工厂找

紧接它会获取合并之后的BeanDefinition , 然后检查这个BeanDefinition是不是抽象的 , 如果是的话是创建不了Bean的 , 然后就会通过getDependsOn()获取它所依赖的Bean

@DependsOn

这个注解表示依赖的意思 , 就比如MemberService加上@DependsOn注解之后 , 就表示在创建MemberService之前 , 要先把依赖的Bean创建好 , MemberService的这种写法是集合的形式, 而UserService的写法是单个的形式

拿到锁依赖的Bean之后就会把依赖的Bean注册到Map中

对应的就是这两个Map

但是有一种情况会抛异常的
如果是这样声明的话就会产生循环依赖 , 通过@DependsOn注解产生的循环依赖是无法解决的

我们接着来看的getBean()源码然后紧接着会调用getBean()创建所依赖的Bean , 然后创建锁依赖的Bean之后 , 才去真正的创建这个当前需要创建的Bean

简单回想一下Bean的生命周期 , 扫描, 接下来就要去创建实例化 , 属性注入…等等操作
, 它就会先判断当前需要创建的Bean的作用域是原型还是单例还是其他的作用域 ,

我们先来看一下原型的逻辑

原型的话就是直接调用createBean()方法创建 , 也没有放到单例池等操作
再来看单例Bean
这一块其实是一个lambda表达式 , 然后lambda执行的时候就会调用createBean()去创建Bean

我们接着来看getSingleton()方法

先从单例池获取 , 如果获取不到 , 那么就会执行刚刚的lanbda表达式 , 就会调用createBean()方法去创建一个对象

然后会移除这个正在创建的标志并添加到单例池
原型和单例大概都讲完了 , createBean()的逻辑我们之后再看 , 再来看看第三种情况 , Bean的作用域除去原型和单例的话 , 如果考虑SpringMVC的话 , 还有一些其他的作用域 ,如request , application , session , 也就是说一次请求 , 拿到的Bean肯定是同一个Bean ,那么要怎样保证呢?其实实现原理和创建单例对象时候的逻辑差不多

这里会传一个lambda表达式 , 如果可以getAttribute()获取不为空 , 那么就返回 , 否则就创建

在set设置的时候就会有区分

不管Bean的作用域是什么总归还是要去创建的 , 所以接下来我们就看看createBean()方法

四.加载类

再创建Bean的时候肯定是要加载类的 , 所以createBean()方法第一步就是加载类


如果加载过的话就直接返回 , 否则的话就加载类 ， 就会先去获取类加载器



当然 ，我们也可以这样自定义

然后就会获取类的名称 ， 然后如果有Spring表达式 ， 那么就解析

这种使用方法的Spring表达式时很少使用的 ， 比如是这样定义的（语法错误 ， 为了演示）

然后就会加载类并返回

return dynamicLoader.loadClass(className);

接下来就是这个功能

这个功能会和@Lookup注解有关系 ， 放到后面来说

五.实例化前

加载完类之后紧接着就是实例化之前需要做的一些操作

之前的文章我们提到过实现BeanPostProcessors接口可以在Bean初始化前后去对Bean进行一些额外的处理 , 那么在初始化前也提供了这个功能 , 就是InstantiationAwareBeanPostProcessor这个接口

@Component
public class TestInstantiationAwareBeanPostProcessor implements InstantiationAwareBeanPostProcessor {


	@Override
	public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
		// 实例化前
		return null;
	}


	@Override
	public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
		// 实例化后
		return null;
	}
}

而初始化前就是做这一步操作的

它会先从缓存判断你是否有实现了InstantiationAwareBeanPostProcessor接口的类 , 如果有 , 那么就执行对应的postProcessBeforeInstantiation()方法

比如我们可以这样写

按理说得到的应该是userService这个Bean , 但是由于我们实现了接口 , 那么它就会在实例化前执行 , 然后返回你自己所定义的结果

不等于空就直接返回了

六.推断构造方法

推断构造方法的过程在后面有单独的文章说明

七.实例化

如果在实例化前没有做什么事情 , 那么正常进行实例化

八.BeanDefinition后置处理器

那么实例化之后就会专门的处理合并之后的BeanDefinition

也就是这个接口

实现这个接口 , 我们就可以在实例化之后设置BeanDefinition的一些属性 , 但是有一部分是设置不了的

九.实例化后

实例化后在populateBean()这个方法中 , 在属性赋值之前 , 其实和实例化之前差不多 .InstantiationAwareBeanPostProcessor接口实现之后可以重写postProcessBeforeInitialization()和postProcessAfterInitialization()方法, 而实例化前后就是找出实现了InstantiationAwareBeanPostProcessor接口的类分表调用这两个方法

十.属性填充

再往下看

这个其实为了支持Spring的自带的依赖注入功能 , 但是已经过时了 , 不怎么用 , 但是如果使用的话必须添加一个set方法

public class OrderService {

	private MemberService memberService;

	public void setMemberService(MemberService memberService) {
		this.memberService = memberService;
	}

	public void test(){
		System.out.println(this.memberService);
	}
}

然后在AppConfig添加如下配置

	@Bean(autowire = Autowire.BY_TYPE)
	public MemberService memberService(){
		return new MemberService();
	}

这个时候OrderService中的MemberService就是有值的 , 如果配置的是 Autowire.BY_TYPE , 那么它会根据set方法入参的类型去寻找Bean

如果是 Autowire.BY_NAME , 那么就是截取set方法名 , 去掉set然后首字母小写

十一.属性填充后

然后Spring自带的注入完毕之后 , 又会去调用InstantiationAwareBeanPostProcessor的postProcessProperties()方法 , 这个方法可以去处理自己的注解 , 比如AutowiredAnnotationBeanPostProcessor就会去处理@Autowired注解

这里还有个pvs , 这个pvs就是通过自定义的方式来给属性赋值 , 比如这样

也就是说在属性填充之前 , 它会去检查你有没有通过这种方式自定义给属性赋值 , 如果赋值了 , 那么@Autowired是不生效的

十二.初始化前

紧接着就是到了初始化这一步 , 我们接着分析源码

那么首先会初始化各种Aware回调

接下来就是初始化前的操作了

找出实现了BeanPostProcessor接口的类 , 然后执行postProcessBeforeInitialization()方法

十三.初始化

判断是否实现了InitializingBean接口 , 实现了就调用afterPropertiesSet()方法 , 或者说指定了初始化方法 , 那么就去执行这个方法

十四.初始化后

初始化后和初始化前是差不多的 , 只不过是执行的方法不同 , 初始化后执行的是postProcessAfterInitialization

初始化完成之后 , 就算真正的创建出了一个Bean对象 , 随后就会有循环依赖相关的处理逻辑 , 循环依赖可以看我之前的文章

十五.Bean销毁

最后就是去判断你有没有定义一些Bean销毁的逻辑

我们可以通过实现一个接口来定义Bean销毁的逻辑

public class OrderService implements DisposableBean {

	@Override
	public void destroy() throws Exception {
		System.out.println("销毁");
	}
}

而这个销毁逻辑方法被调用是当我们Spring容器关闭的时候被触发
关闭的方式有两种

1.向JVM注册一个关闭的钩子 , 当进程结束 , 容器关闭
applicationContext.registerShutdownHook();
2. 手动调用close()方法关闭
applicationContext.close();

但是这两种方法最后都调用的是doClose()方法


也就是这段源代码

	/**
	 * Actually performs context closing: publishes a ContextClosedEvent and
	 * destroys the singletons in the bean factory of this application context.
	 * 
Called by both {@code close()} and a JVM shutdown hook, if any.
	 * @see org.springframework.context.event.ContextClosedEvent
	 * @see #destroyBeans()
	 * @see #close()
	 * @see #registerShutdownHook()
	 */
	@SuppressWarnings("deprecation")
	protected void doClose() {
		// Check whether an actual close attempt is necessary...
		// 检查上下文是否属于激活状态
		if (this.active.get() && this.closed.compareAndSet(false, true)) {
			if (logger.isDebugEnabled()) {
				logger.debug("Closing " + this);
			}

			if (!NativeDetector.inNativeImage()) {
				// 移除应用上下文的注册
				LiveBeansView.unregisterApplicationContext(this);
			}

			try {
				// Publish shutdown event.
				// 发布上下文已关闭事件 ContextClosedEvent
				publishEvent(new ContextClosedEvent(this));
			}
			catch (Throwable ex) {
				logger.warn("Exception thrown from ApplicationListener handling ContextClosedEvent", ex);
			}

			// Stop all Lifecycle beans, to avoid delays during individual destruction.
			if (this.lifecycleProcessor != null) {
				try {
					// 调用生命周期管理器的 onClose() 方法，终止对容器中各个bean的生命周期管理
					this.lifecycleProcessor.onClose();
				}
				catch (Throwable ex) {
					logger.warn("Exception thrown from LifecycleProcessor on context close", ex);
				}
			}

			// Destroy all cached singletons in the context's BeanFactory.
			//销毁容器中所有的（单例）bean
			//这里的容器指的是高级容器内嵌的低级容器 beanFactory，bean都是放在内置的beanFactory中的
			destroyBeans();

			// Close the state of this context itself.
			//关闭内置的beanFactory
			closeBeanFactory();

			// Let subclasses do some final clean-up if they wish...
			//预留的扩展点，在关闭beanFactory后做一些额外操作
			onClose();

			// Reset local application listeners to pre-refresh state.
			//重置存储监听器的2个成员变量
			if (this.earlyApplicationListeners != null) {
				this.applicationListeners.clear();
				this.applicationListeners.addAll(this.earlyApplicationListeners);
			}
			//设置上下文的激活状态为false
			// Switch to inactive.
			this.active.set(false);
		}
	}

	/**
	 * Template method for destroying all beans that this context manages.
	 * The default implementation destroy all cached singletons in this context,
	 * invoking {@code DisposableBean.destroy()} and/or the specified
	 * "destroy-method".
	 * 
Can be overridden to add context-specific bean destruction steps
	 * right before or right after standard singleton destruction,
	 * while the context's BeanFactory is still active.
	 * @see #getBeanFactory()
	 * @see org.springframework.beans.factory.config.ConfigurableBeanFactory#destroySingletons()
	 * 
	 * 销毁容器中所有的（单例）bean。
	 * 如果bean实现了 DisposableBean 接口，或使用 destroy-method 属性指定了销毁方法，会调用对应的销毁方法
	 */
	protected void destroyBeans() {
		getBeanFactory().destroySingletons();
	}

	/**
	 * Template method which can be overridden to add context-specific shutdown work.
	 * The default implementation is empty.
	 * 
Called at the end of {@link #doClose}'s shutdown procedure, after
	 * this context's BeanFactory has been closed. If custom shutdown logic
	 * needs to execute while the BeanFactory is still active, override
	 * the {@link #destroyBeans()} method instead.
	 * 
	 * 预留给子类的扩展点，可以在内置的beanFactory关闭后做一些自定义处理
	 * 
	 */
	protected void onClose() {
		// For subclasses: do nothing by default.
	}

到此为止 , Spring框架的生命周期完成 , 对于比较具体的细节还需要仔细的琢磨 , 谢谢大家的阅读 , 感觉文章不错的话来个一键三连吧