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);
1
2

比如上篇文章我们讲的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.
   * <p>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".
   * <p>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.
   * <p>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框架的生命周期完成 , 对于比较具体的细节还需要仔细的琢磨 , 谢谢大家的阅读 , 感觉文章不错的话来个一键三连吧