LOADING

Enable the browser cache if loading is slow

Bean生命周期从了解到了断

2024/3/19 tech Java Spring Bean

Spring 是 JavaWeb 技术中的核心框架，Spring 所延伸出的家族是 Java 帝国的中流砥柱，与 Java 的发展紧密相连。Spring 容器于对象的管理，即 Bean 的管理是 Spring 的极其重要的基础设施。本文将以理论、图解与代码结合的方式，循序渐进，试图讲清 Spring 对象管理的设计思路与 Java 帝国中原子公民"波澜壮阔"的一生。

在阅读本文之前，请确保您有 JavaEE 基础，对 Spring 的应用有部分了解。

本文中的所有代码演示都基于 JDK 1.8 Spring 5.3.23 SpringBoot 2.6.13。

为了优化排版，在解析源码时，[spring] 代表 org.springframework。

例如：[spring].beans.factory 代表 org.springframework.beans.factory。

容器

Spring 容器负责创建、管理和销毁应用中的对象，开发者只需要配置对象的依赖关系和相关属性，不需要手动创建对象或处理依赖。

从 Spring 开发者的角度来看：

作为容器，Spring 需要持久管理使用者所依赖的对象，这些对象称作Bean。尤其是在 MVC 架构下，Mapper Service Controller都只需要单例存在，不需要每次创建新的对象。

从 Spring 使用者的角度来看：

作为容器，Spring 需要通过 Bean 的名字来获取 Bean 的Object 对象，以此作为容器提供服务。

综上所述，HashMap 是持久管理、通过名字获取对象的不二选择。

实际上，Spring 也是这么做的。

在 [spring].beans.factory.support.DefaultSingletonBeanRegistry 中，singletonObjects 即为上述所提到的 HashMap。

public class DefaultSingletonBeanRegistry 
    extends SimpleAliasRegistry 
    implements SingletonBeanRegistry {
    // ....
    private final Map<String, Object> singletonObjects = new ConcurrentHashMap(256);
    // ....
}

作为简单的容器，我们可以通过 HashMap 长期引用 Object，以此来保证其不会被 GC 回收。

通过构建 String -> Object 映射，可以快速查询目标对象。

自此，Spring 的容器已经有了雏形。

Bean 的产生

从 Spring 开发者的角度来看。

Spring 需要管理 Bean 从创建到死亡的全过程，Bean 的死亡只需要删除 HashMap 中的映射关系，该 Bean 随后就会被 GC 标记回收。为了方便称呼，下文将记录 String -> Object 映射关系的 HashMap 叫做单例池(singletonObjects)。

Bean 的创建

在常规开发中，通常使用 new 关键字创建对象。

例如：

new String(); // 调用无参构造方法创建对象
new String("ErickRen"); // 调用有参构造方法创建对象

在 Spring 进行对象管理时，很明显无法使用 new 关键字进行对象创建。

Spring 采用反射进行对象创建，有关反射的概念、使用和原理，本文暂且按下不表。

通过反射调用构造方法，创建 Bean 的实例对象 (instance)，将实例对象与 Bean 名字建立映射，就完成了容器创建对象的流程。

以上，可以得到流程图：

Bean 注册信息

在使用者视角中，Spring 有两种方法定义 Bean：从 XML 文件定义，使用注解定义。

两种定义方法效果一致，由此可以猜测：两者的底层逻辑可能有相通指出之处，XML 和 注解 只是上层定义的一个包装。

事实也确实如此，Spring 通过引入BeanDefinition来包装 Bean 的定义信息。并将 BeanDefinition 利用 HashMap 储存，即[spring].beans.factory.support.DefaultListableBeanFactory中的beanDefinitionMap，在实例化时统一读取，统一创建。

从 XML 和 注解 扫描而来的定义信息统一封装进 BeanDefinition 中，再由容器统一读取，统一创建 Bean。

BeanDefinition 中几乎包含了所有 Bean 的信息，例如：

  • Bean 的类型
  • 是否为单例
  • 是否懒加载
  • 属性填充信息
  • 依赖其他 Bean 信息
  • …

BeanDefinition 是 Bean 创建的最高准则，是整个 Spring 管理对象最重要的参考。

XML文件定义

在 XML 文件中构造的 Bean，一般由 XML 解析器，通过将 XML 文件重新反序列化为树状文件，以此来读取并解析 Bean。

本文在此对 XML 的反序列化不作详细解释。

注解定义

一般通过扫描类注解来检查某个类是否有某个注解。

注解扫描有两种常用方法：反射 与 ASM。

反射

现有类 Demo.java:

package me.erickren.source.demos;

import org.springframework.stereotype.Component;

/**
 * DateTime: 2024/03/11 - 21:06
 * Author: ErickRen
 */
@Component
public class Demo {
    
}

通过反射方式可以获取某个类上的注解：

public static void main(String[] args){
        Class<Demo> klass = Demo.class;
        Component annotation = klass.getAnnotation(Component.class);
        System.out.println(annotation);
    }

得到结果：

@org.springframework.stereotype.Component(value=)

递归获取注解问题

在使用 Spring 时，有许多子注解，例如：@Controller @Service。

本质上 @Controller 是 @Component 的一个子注解。

package org.springframework.stereotype;

import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import org.springframework.core.annotation.AliasFor;

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
public @interface Controller {
    @AliasFor(
        annotation = Component.class
    )
    String value() default "";
}

如果使用上文提到的klass.getAnnotation(Controller.class)获取注解，无法读取到父注解 @Component。

在框架开发中，针对 Controller 等子注解判断再复用 Component 注册流程是可行的。

Spring 采取的方案是再次扫描子注解，检查其中是否有某个父注解。

以下是一个示例：

public static void main(String[] args) {
    	// 获取 Class
        Class<Demo> klass = Demo.class;
    	// 获取对象上的注解
        Annotation[] annotations = klass.getAnnotations();
    	// 获取父注解
        for (Annotation annotation : annotations) {
            Annotation[] an = annotation.annotationType().getAnnotations();
            for (Annotation target : an) {
                System.out.println(target);
            }
        }
    }

从以上来看，反射方法确实优雅而易于实现。但反射存在问题，当 Bean 设置为懒加载时，需要将 Bean 加载到内存中才能获取注解。该情况与懒加载的语义冲突，所以通过反射处理不是最优方案。

ASM

ASM 是一种分析和操作 Java 字节码(.class文件)的框架。它可以直接以二进制的形式用于修改现有类或动态生成类。相比反射，ASM 获取注解更加高效，因为其直接操作字节码，不需要将类加载到内存中。

ASM 名字的来源于 C 语言中 __asm__ 关键字，后者可以在 C 语言中内联汇编程序。

本文在此不详细说明 ASM 的具体实现。

现在，Bean 的创建流程图为：

自动生成 Bean 的名称

在类上标注 @Component，Spring 将会管理该 Bean。

前文提到，Spring 维护了 String -> Object 的映射关系，所以任何单例 Bean 都需要有一个名字。在一般开发中，使用者并不关心 Bean 的名字，这部分工作也可以由 Spring 进行。

自动生成 Bean 名字由[spring].beans.factory.support.BeanNameGenerator定义，在一般注解开发中，通常由其实现类[spring].context.annotation.AnnotationBeanNameGenerator实现。在其buildDefaultBeanName方法中，需要传入一个 BeanDefinition，并调用了Introspector.decapitalize()最终生成默认 Bean 名字。

protected String buildDefaultBeanName(BeanDefinition definition) {
    	// 获取 Bean 类全限定名
    	//例如:me.erickren.source.UserService
        String beanClassName = definition.getBeanClassName();
    	// 断言是否为 null
        Assert.state(beanClassName != null, "No bean class name set");
    	// 获取类名称 UserService
        String shortClassName = ClassUtils.getShortName(beanClassName);
    	// 生成默认 Bean 名称
        return Introspector.decapitalize(shortClassName);
    }

public static String decapitalize(String name) {
        if (name == null || name.length() == 0) {
            return name;
        }
    	// 如果第1个和第2个字符都是大写，则直接返回
    	// 这是为了处理缩写，例如 URL，不应该改写为 uRL，不符合直觉。
        if (name.length() > 1 && Character.isUpperCase(name.charAt(1)) &&
                        Character.isUpperCase(name.charAt(0))){
            return name;
        }
    	// 如果只有第1个字符为大写，则将第1个字符转为小写
    	// 例如 UserService -> userService
        char chars[] = name.toCharArray();
        chars[0] = Character.toLowerCase(chars[0]);
        return new String(chars);
    }

BeanDefinition 的统一注册与管理

BeanDefinition 全都由 BeanDefinitionRegistry 接口注册。该接口主要有两个实现包含 beanDefinitionMap，一个是 [spring].beans.factory.support.SimpleBeanDefinitionRegistry，另一个是同包下的DefaultListableBeanFactory。在一般开发中，都会使用 DefaultListableBeanFactory 作为 BeanRegistry。

BeanRegistry 中提供了一些常规方法注册、获取和使用 BeanDefinition，这赋予开发者极大的灵活性。

甚至在使用中，还可以通过一些非常手段通过容器获取 BeanRegistry 直接注册 Bean。

请注意，以下代码仅供博客演示，请勿在生产环境使用该方式。

package me.erickren.source;

import me.erickren.source.service.UserService;
import org.springframework.beans.factory.config.ConfigurableListableBeanFactory;
import org.springframework.beans.factory.support.DefaultListableBeanFactory;
import org.springframework.beans.factory.support.RootBeanDefinition;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.ConfigurableApplicationContext;

@SpringBootApplication
public class Hello {
    
    public static void main(String[] args) {
        ConfigurableApplicationContext run = SpringApplication.run(Hello.class, args);
        ConfigurableListableBeanFactory beanFactory = run.getBeanFactory();
        DefaultListableBeanFactory factory = (DefaultListableBeanFactory) beanFactory;
        RootBeanDefinition rootBeanDefinition = new RootBeanDefinition(UserService.class);
        factory.registerBeanDefinition("myBean", rootBeanDefinition);
        Object myBean = run.getBean("myBean");
        System.out.println(myBean);
    }

}

me.erickren.source.service.UserService@5c089b2f

Bean 的生命流程图：

属性填充

对于 Spring 而言，创建对象只是基本任务，Spring 为人称道更多的是因为其会自动地为对象填充属性。

这里的属性可能是常规属性，也可能是另一个 Bean。

填充属性

上文提到使用反射创建对象，可以方便地为 Bean 填充基础数据。

在填充属性时，属性大多是以<String, Object>为一对存在，通过将封装PropertyValue为 PropertyValues，在 BeanDefinition 中携带该信息，在创建 Bean 时利用反射进行填充。在通常情况下，Spring 会使用 PropertyValues 的实现类MutablePropertyValues。它使用一个 List 保存 PropertyValue。

public abstract class AbstractBeanDefinition 
    extends BeanMetadataAttributeAccessor 
    implements BeanDefinition, Cloneable {
	// ...
    @Nullable
    private MutablePropertyValues propertyValues;
    // ...
}

在创建 Bean 的核心方法AbstractAutowireCapableBeanFactory#doCreateBean中，调用this.populateBean()方法，为 Bean 填充信息。populateBean方法中，通过获取 BeanDefinition 携带的 PropertyValues 为 Bean 填充属性。

// [spring].beans.factory.support.AbstractAutowireCapableBeanFactory#populateBean
protected void populateBean(String beanName, RootBeanDefinition mbd, @Nullable BeanWrapper bw)
{
    // ...
	PropertyValues pvs = mbd.hasPropertyValues() ? mbd.getPropertyValues() : null;       
    // ...
}

填充 Bean

在上文提到，Bean 的普通属性会封装一份 PropertyValues 由 BeanDefinition 携带，而 Bean 相关的依赖也由一个数据结构定义，同样由 BeanDefinition 持有，即：BeanReference。

BeanReference 有三个实现类，其中RuntimeBeanReference最常使用。

站在开发者的角度来看，欲注入的 Bean 实际上是特殊的属性，所以可以通过 PropertyValue 封装 BeanReference。这样就实现了属性注入信息的统一封装。

在 BeanDefinitionValueResolver#resolveValueIfNecessary中，通过instanceof关键字，将 PropertyValue 封装的 BeanReference 读取、强制转换并执行注入。

public Object resolveValueIfNecessary(Object argName, @Nullable Object value) {
    	// 检查 value 是否为 BeanReference
        if (value instanceof RuntimeBeanReference) {
            // 是则强制转换
            RuntimeBeanReference ref = (RuntimeBeanReference)value;
            return this.resolveReference(argName, ref);
        } else if (value instanceof RuntimeBeanNameReference) {
            // RuntimeBeanNameReference 是 BeanReference 的另一个实现类
            // 前者只通过 Bean 名称进行引用，而后者包含了前者，并封装了 Bean 类型
            String refName = ((RuntimeBeanNameReference)value).getBeanName();
            refName = String.valueOf(this.doEvaluate(refName));
            if (!this.beanFactory.containsBean(refName)) {
                throw new BeanDefinitionStoreException("Invalid bean name '" + refName + "' in bean reference for " + argName);
            } else {
                return refName;
            }
        }
    // ...
}

到现在，Bean 的生命流程如下：

AOP 增强

AOP(Aspect Oriented Programming) 全称面向切面编程，通过预编译和运行期间动态代理来实现程序功能的一种技术。

AOP 是 Spring 的另一个核心基础设施，一般使用动态代理技术实现。

在 Spring 运行期间通过动态代理技术动态生成对象，代理对象方法执行时进行增强功能的介入。

请注意，本文不会介绍 AOP 在 Spring 中的应用，只会从表面原理对其进行简单解析。

AOP 的术语解释

为了方便解释，给定一个场景。

现给定一个类 UserService.java

package me.erickren.source.service;

import org.springframework.stereotype.Service;

/**
 * DateTime: 2024/03/13 - 20:03
 * Author: ErickRen
 */
@Service
public class UserService {
    
    public void login() {
        System.out.println("用户正在登录。。。");
    }
    
    public void logout() {
        System.out.println("用户退出。。。");
    }
    
}

其中定义方法login和logout，都只进行简单打印。

再给定一类 Aspect.java

package me.erickren.source.aspect;

import lombok.extern.slf4j.Slf4j;
import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.After;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.springframework.stereotype.Component;

/**
 * DateTime: 2024/03/13 - 20:06
 * Author: ErickRen
 */
@Aspect
@Component
@Slf4j
public class Aspect {
    
    @Before("execution(* me.erickren.source.service.UserService.*.*(..))")
    public void before(JoinPoint joinPoint) {
        log.info("前置通知执行");
    }
    
    @After("execution(* me.erickren.source.service.UserService.*.*(..))")
    public void after(JoinPoint joinPoint) {
        System.out.println("后置通知执行");
    }
    
}

此时，UserService 的两个方法均已加强。

现解释术语：

  • Join Point(连接点)：具体被拦截的对象，Spring 只支持方法拦截，所以被拦截的是方法。即上述场景的UserService#login和UserService#logout。
  • Point Cut(切点)：当需要批量连接点时，通常使用切点表达式来匹配多个连接点，多个连接点组成的集合即称为切点。即上述场景的execution(* me.erickren.source.service.UserService.*.*(..))表达式所匹配到的(UserService#login,UserService#logout)集合。
  • Advice(通知/增强)：AOP 增强的具体实现，分为前置、后置、异常、环绕和最终五种，即上述场景的Aspect#before和Aspect#after。
  • Aspect(切面)：由 切点 和 通知 组成的对象集合。上述场景的 UserService和Aspect都是切面。
  • Target(目标)：承载连接点的对象，即上述场景的UserService类。
  • Weaving(织入)：是一个操作，具体指将切面应用到目标生成代理类的过程。这个过程通常发生在编译期(静态代理)，运行期(动态代理)。
  • Proxy(代理)：通过各种手段生成的代理对象，其本质上是一个对象，不同于UserService和Aspect，是自动生成的对象。这个对象有着和UserService类似的方法，但其中的方法都经过增强。

实现动态代理的两种技术

本文主要讲解 Bean 生命全流程，所以动态代理的实现技术暂且提起顶层设计。

JDK 动态代理

在 Spring 中，对于实现接口的类，会使用java.lang.reflect.Proxy类来创建代理对象。代理对象会在运行时实现代理接口，覆盖其中的方法，在方法调用前后执行切面逻辑。

CGLIB 动态代理

对于未实现接口的类，会使用 CGLIB 库生成代理对象。CGLIB 通过字节码技术创建目标类的子类，在子类中重写目标方法并在方法前后插入切面逻辑。

对于 Spring 来说，动态代理技术最后生成的代理对象才是运行需要的对象。即容器中最终存储的是代理对象。

此时，Bean 的生命流程为：

上文中的 AOP 为什么会在属性填充之前，会在下文中有详细解释。

上下文与 Bean 工厂

从上文来看，容器的基本功能已经实现，但这个容器包含了 BeanDefinition 的创建，Bean 的扫描，还需要管理各种对 Bean 的加强类等，未来还可能会添加的容器相关功能，整个项目的结构已经变得非常复杂，难以维护，所以 Spring 将容器与 Bean 的创建剥离，维护了一套层级结构，即ApplicationContext与BeanFactory。

在本质上，ApplicationContext 是 BeanFactory 的顶层实现：

BeanFactory 主要负责 Bean 的创建，而 ApplicationContext 集成了更多功能，例如：容器生命周期管理，Bean 的扫描，与其他框架的融合。

该举是为了将整个框架分为底层服务与上层应用，便于管理与拓展。

分层思想是计算机科学中常见的开发思想，其将复杂系统分为多层，极大系统拓展性与简洁性。在计算机科学中著名的分层系统有：计算机网络OSI七层模型,计算机网络TCP/IP四层模型,WEB开发MVC三层模型。

Bean 行为的拓展

通过上述流程，Bean 已经基本成形，现需要为 Bean 提供更多的灵活性。

通过长期实践，两个点位最为适宜：Bean 初始化后与Bean 销毁前。分别称为 init-method和destroy-method。

这种在固定点位被自动调用的方法，叫做钩子方法(Hook Method)。

在 Spring 中，有四种方法配置这两种方法。

  • @Bean 注解填写参数
  • @PostConstruct 和 @PreDestroy 注解
  • InitializingBean 和 DisposableBean
  • XML 配置

篇幅所限，本文不在此细说使用方式。

执行顺序分析

给定场景：

UserService.java

package me.erickren.source.service;

import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;

/**
 * DateTime: 2024/03/15 - 17:42
 * Author: ErickRen
 */
public class UserService implements InitializingBean, DisposableBean {

    public UserService() {
        System.out.println("构造函数执行");
    }

    public void init_bean () {
        System.out.println("@Bean 上定义的 Init 方法");
    }
    
    public void destroy_bean () {
        System.out.println("@Bean 上定义的 Destroy 方法");
    }
    
    @PostConstruct
    public void init_post() {
        System.out.println("@PostConstruct 上定义的 Init 方法");
    }
    
    @PreDestroy
    public void destroy_post() {
        System.out.println("@PreDestroy 上定义的 Destroy 方法");
    }

    @Override
    public void afterPropertiesSet() throws Exception {
        System.out.println("InitializingBean 重写的 afterPropertiesSet 方法");
    }
    
    @Override
    public void destroy() {
        System.out.println("DisposableBean 重写的 destroy 方法");
    }
}

BeanConfig.java：

package me.erickren.source.config;

import me.erickren.source.service.UserService;
import org.springframework.context.annotation.Bean;

/**
 * DateTime: 2024/03/15 - 17:41
 * Author: ErickRen
 */
public class BeanConfig {
    
    
    @Bean(initMethod = "init_bean", destroyMethod = "destroy_bean")
    public UserService userService() {
        return new UserService();
    }
    
}

main 函数：

public static void main(String[] args) {
        AnnotationConfigApplicationContext context = 
            new AnnotationConfigApplicationContext(BeanConfig.class);
        context.getBean("userService");
        context.close();
    }

通过检测，可以得到顺序为：

  • 构造函数
  • @PostConstruct 上定义的 Init 方法
  • InitializingBean 重写的 afterPropertiesSet 方法
  • @Bean 上定义的 Init 方法
  • @PreDestroy 上定义的 Destroy 方法
  • DisposableBean 重写的 destroy 方法
  • @Bean 上定义的 Destroy 方法

由此可知，@PostConstruct 与 @PreDestroy 是最先执行的，随后是 InitializingBean 和 DisposableBean 重写的两个方法，最后是 Bean 定义。

原理解析

从名称上来看，这几种方法锁针对的细分位置也不一样。

例如：InitializingBean 中的方法叫做 afterPropertiesSet，这表明这个方法是在填充属性后调用的。

从原理上看，@PostConstruct 和 @PreDestroy 最终生成了InitDestroyAnnotationBeanPostProcessor，而重写 afterPropertiesSet 方法 和 @Bean 定义的 Init 方法实际上都术语 InitMethod 的范畴。

通过断点调试，这三种方法的顺序由AbstractAutowireCapableBeanFactory#initializeBean控制。

protected Object initializeBean(String beanName, Object bean, @Nullable RootBeanDefinition mbd) {
        if (System.getSecurityManager() != null) {
            AccessController.doPrivileged(() -> {
                this.invokeAwareMethods(beanName, bean);
                return null;
            }, this.getAccessControlContext());
        } else {
            this.invokeAwareMethods(beanName, bean);
        }

        Object wrappedBean = bean;
        if (mbd == null || !mbd.isSynthetic()) {
            // 调用初始化前 PostProcessor
            wrappedBean = this.applyBeanPostProcessorsBeforeInitialization(bean, beanName);
        }

        try {
            // 调用初始化方法
            this.invokeInitMethods(beanName, wrappedBean, mbd);
        } catch (Throwable var6) {
            throw new BeanCreationException(mbd != null ? mbd.getResourceDescription() : null, beanName, "Invocation of init method failed", var6);
        }

        if (mbd == null || !mbd.isSynthetic()) {
            // 调用初始化后 PostProcessor
            wrappedBean = this.applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
        }

        return wrappedBean;
    }

因为初始化前 PostProcessor 最先调用，所以封装为 PostProcessor 的 @PostConstruct 最先调用。之后是其他两种方法，重写 afterPropertiesSet 和 @Bean 定义本质都到了 invokeInitMethods中。

protected void invokeInitMethods(String beanName, Object bean, @Nullable RootBeanDefinition mbd) throws Throwable {
    	// 处理是否实现 InitializingBean
        boolean isInitializingBean = bean instanceof InitializingBean;
        if (isInitializingBean && (mbd == null || !mbd.hasAnyExternallyManagedInitMethod("afterPropertiesSet"))) {
            if (this.logger.isTraceEnabled()) {
                this.logger.trace("Invoking afterPropertiesSet() on bean with name '" + beanName + "'");
            }

            if (System.getSecurityManager() != null) {
                try {
                    AccessController.doPrivileged(() -> {
                        ((InitializingBean)bean).afterPropertiesSet();
                        return null;
                    }, this.getAccessControlContext());
                } catch (PrivilegedActionException var6) {
                    throw var6.getException();
                }
            } else {
                // 调用重写的 afterPropertiesSet 方法
                ((InitializingBean)bean).afterPropertiesSet();
            }
        }
		// 处理自定义的 初始化方法
        if (mbd != null && bean.getClass() != NullBean.class) {
            String initMethodName = mbd.getInitMethodName();
            if (StringUtils.hasLength(initMethodName) && (!isInitializingBean || !"afterPropertiesSet".equals(initMethodName)) && !mbd.hasAnyExternallyManagedInitMethod(initMethodName)) {
                // 调用自定义的初始化方法 即 @Bean 定义的方法 与 XML 定义等价
                this.invokeCustomInitMethod(beanName, bean, mbd);
            }
        }

    }

由此，我们可以得到新的流程：

前面提到的是 Bean 的初始化方法，当容器关闭(调用context.close())时，容器会进行关闭，并进行 Bean 的销毁流程。

public void close() {
        synchronized(this.startupShutdownMonitor) {
            this.doClose();
            if (this.shutdownHook != null) {
                try {
                    Runtime.getRuntime().removeShutdownHook(this.shutdownHook);
                } catch (IllegalStateException var4) {
                }
            }

        }
    }
// 上述代码的 doClose() 方法
protected void doClose() {
        if (this.active.get() && this.closed.compareAndSet(false, true)) {
            if (this.logger.isDebugEnabled()) {
                this.logger.debug("Closing " + this);
            }

            if (!NativeDetector.inNativeImage()) {
                LiveBeansView.unregisterApplicationContext(this);
            }

            try {
                this.publishEvent((ApplicationEvent)(new ContextClosedEvent(this)));
            } catch (Throwable var3) {
                this.logger.warn("Exception thrown from ApplicationListener handling ContextClosedEvent", var3);
            }

            if (this.lifecycleProcessor != null) {
                try {
                    this.lifecycleProcessor.onClose();
                } catch (Throwable var2) {
                    this.logger.warn("Exception thrown from LifecycleProcessor on context close", var2);
                }
            }
		   // 销毁 Bean 
            this.destroyBeans();
            // 关闭 BeanFactory 这个下文会详细讲解
            this.closeBeanFactory();
            this.onClose();
            // 关闭监听器 这个下文也会讲到
            if (this.earlyApplicationListeners != null) {
                this.applicationListeners.clear();
                this.applicationListeners.addAll(this.earlyApplicationListeners);
            }
		   // 设置活动标志符为 false 标志容器已关闭
            this.active.set(false);
        }

    }

在核心方法 DisposableBeanAdapter#destroy中，与上述初始化方法一样，通过代码顺序确定了三种销毁方法的执行顺序，分别为：processor.postProcessBeforeDestruction(this.bean, this.beanName)、((DisposableBean)this.bean).destroy()和 this.invokeCustomDestroyMethod(this.destroyMethod)。篇幅所限，本文在此不再赘述。

注意：多例 Bean 在本质上不由容器管理生命周期，所以只执行初始化方法，不执行销毁方法。

流程图：

PostProcessor

PostProcessor 本质上是 Hook 处理器，下文可能会简称为处理器。其在特定位置被调用执行，干预 Bean 的生命流程。

上文提到，@PostConstruct 和 @PreDestroy 本质上都是 InitDestroyAnnotationBeanPostProcessor，PostProcessor　是 Spring 中非常重要的拓展机制，主要分为两类：

  • BeanFactoryPostProcessor：主要作用于 BeanFactory。
  • BeanPostProcessor：主要作用于 Bean。

BeanFactoryPostProcessor

BeanFactoryPostProcessor是对BeanFactory进行操作的后置 Hook 处理器。

在 BeanFactory 中，暴露出接口可以对 BeanDefinition 进行操作。BeanFactory 中包含 BeanDefinition。

因此，Spring 提供了有一个更细粒度的后置处理器接口BeanDefinitionRegistryPostProcessor，参数为BeanDefinitionRegistry，主要对 BeanDefinition 进行操作。

使用

BeanFactoryPostProcess 一般通过作为 Bean 注册到 Spring 容器中，在执行时通过：

postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);

获取所有 processor，并执行。

或者通过直接向容器中插入 processor 的形式使用 BeanFactoryPostProcess。

AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(BeanConfig.class);
        context.addBeanFactoryPostProcessor(processor);

从上述代码可以看出，BeanFactoryPostProcessor 由 ApplicationContext 管理和维护，因为其本身操作 BeanFactory，所以不应由 BeanFactory 管理和维护。

调用

这两个处理器主要在AnnotationConfigApplicationContext#refresh中调用执行：

refresh：

public void refresh() throws BeansException, IllegalStateException {
        synchronized(this.startupShutdownMonitor) {
            // ...
            try {
                this.postProcessBeanFactory(beanFactory);
                StartupStep beanPostProcess = this.applicationStartup.start("spring.context.beans.post-process");
                // 执行 BeanFactoryPostProcessor 后置处理器
                this.invokeBeanFactoryPostProcessors(beanFactory);
                // 注册 BeanPostProcessor
                this.registerBeanPostProcessors(beanFactory);
                beanPostProcess.end();
                // ...
                // 注册监听器
                this.registerListeners();
                // ...
            } catch (BeansException var10) {
                if (this.logger.isWarnEnabled()) {
                    this.logger.warn("Exception encountered during context initialization - cancelling refresh attempt: " + var10);
                }
			   // 如果遇到异常，则销毁 Bean
                this.destroyBeans();
                this.cancelRefresh(var10);
                throw var10;
            } finally {
                this.resetCommonCaches();
                contextRefresh.end();
            }

        }
    }

执行顺序问题

排序接口

BeanFactoryPostProcessor 有特定的执行顺序，在[spring].context.support.PostProcessorRegistrationDelegate中，定义了方法invokeBeanFactoryPostProcessors，其中决定了执行顺序。

public static void invokeBeanFactoryPostProcessors(ConfigurableListableBeanFactory beanFactory, List<BeanFactoryPostProcessor> beanFactoryPostProcessors) {
        // ...
    for(var10 = 0; var10 < var9; ++var10) {
        ppName = var16[var10];
        // 先执行实现了 PriorityOrdered 的处理器
        if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) {
            currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
            processedBeans.add(ppName);
        }
    }
    // ...
    for(var10 = 0; var10 < var9; ++var10) {
        ppName = var16[var10];
        // 再执行实现了 Ordered 的处理器
        if (!processedBeans.contains(ppName) && beanFactory.isTypeMatch(ppName, Ordered.class)) {
            currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
            processedBeans.add(ppName);
        }
    }
    // ...
    for(int var26 = 0; var26 < var10; ++var26) {
        String ppName = var19[var26];
        // 最后再执行剩余的处理器
        if (!processedBeans.contains(ppName)) {
            currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
            processedBeans.add(ppName);
            reiterate = true;
        }
    }
    
    // ...
    }

由上述源码分析，Spring 会优先执行实现了PriorityOrderedD的处理器，再执行Ordered的处理器，最后执行普通的处理器。

注册方式

上文提到，BeanFactoryPostProcessor 是容器的概念，所以 ApplicationContext 持有并维护处理器。

BeanFactoryPostProcessor 的调用链为：refresh() -> invokeBeanFactoryPostProcessors() -> invokeBeanFactoryPostProcessors()，其中在invokeBeanFactoryPostProcessors中会向下一级调用传入List<BeanFactoryPostProcessor>类型的参数，由getBeanFactoryPostProcessors()获取，该 List 由AbstractApplicationContext维护。

本质上，context.addBeanFactoryPostProcessor(processor)就向该 List 新增了一个处理器。

在invokeBeanFactoryPostProcessors中，传入的 List 会被首先调用，本文因篇幅所限，不再详细展示代码。

有兴趣的读者可以参阅[spring].context.support.PostProcessorRegistrationDelegate自行分析。

因此，手动注册的处理器会先于 Spring 自动扫描的处理器执行。

实现类型

依旧是在invokeBeanFactoryPostProcessors方法中，Spring 会显示先匹配BeanDefinitionRegistryPostProcessor，再匹配BeanFactoryPostProcessor。

在此不再赘述。

至此，得到 Bean 生命周期的流程图：

BeanPostProcessor

BeanPostProcessor 是对Bean的处理器，其提供了两个点位的处理器：初始化前、初始化后。

public interface BeanPostProcessor {
    @Nullable
    // 初始化前处理器
    default Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        return bean;
    }

    @Nullable
    // 初始化后处理器
    default Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        return bean;
    }
}

接口的默认方法为不对 Bean 进行任何处理。

BeanPostProcessor 是 Spring 中极其重要的 Hook 处理器，AOP 的实现高度依赖于 BeanPostProcessor。

使用

BeanPostProcessor 与 BeanFactoryPostProcessor 一样，可以注册为 Bean 被 Spring 扫描后执行，也可以向容器中手动注册，不过注册位置与后者有所不同：

context.getBeanFactory().addBeanPostProcessor(processor);

从上述代码可以看出，BeanPostProcessor 由 BeanFactory 管理和维护。

ApplicationContext 继承了 BeanFactory，同时使用变量维护 BeanFactory。

执行点位

BeanPostProcessor 是修改 Bean 的处理器，从理论上说需要在创建 Bean 时调用。

Spring 中，BeanPostProcessor 基本由AbstractAutowireCapableBeanFactory进行调用，调用链如下：

doCreateBean() -> initializeBean()：

initializeBean 方法：

protected Object initializeBean(String beanName, Object bean, @Nullable RootBeanDefinition mbd) {
    	// 处理 Aware 下文会详细提到 如果没有概念请忽略
        if (System.getSecurityManager() != null) {
            AccessController.doPrivileged(() -> {
                this.invokeAwareMethods(beanName, bean);
                return null;
            }, this.getAccessControlContext());
        } else {
            this.invokeAwareMethods(beanName, bean);
        }
		// 执行初始化前处理器
        Object wrappedBean = bean;
        if (mbd == null || !mbd.isSynthetic()) {
            wrappedBean = this.applyBeanPostProcessorsBeforeInitialization(bean, beanName);
        }

        try {
            // 执行初始化方法
            this.invokeInitMethods(beanName, wrappedBean, mbd);
        } catch (Throwable var6) {
            throw new BeanCreationException(mbd != null ? mbd.getResourceDescription() : null, beanName, "Invocation of init method failed", var6);
        }

        if (mbd == null || !mbd.isSynthetic()) {
            // 执行初始化后处理器
            wrappedBean = this.applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
        }

        return wrappedBean;
}

AOP 的切入

上文 AOP 增强部分提到，AOP 发生在属性注入之后，这是因为 AOP 实际上依赖了 BeanPostProcessor 的后置处理器。

在[spring].aop.framework.autoproxy包中有 BeanPostProcessor 的实现类AbstractAutoProxyCreator，其在重写 postProcessAfterInitialization方法中调用wrapIfNecessary，生成代理对象。

public Object postProcessAfterInitialization(@Nullable Object bean, String beanName) {
        if (bean != null) {
            Object cacheKey = this.getCacheKey(bean.getClass(), beanName);
            if (this.earlyProxyReferences.remove(cacheKey) != bean) {
                // 调用　wrapIfNecessary
                return this.wrapIfNecessary(bean, beanName, cacheKey);
            }
        }

        return bean;
    }

protected Object wrapIfNecessary(Object bean, String beanName, Object cacheKey) {
       // ...
        Object[] specificInterceptors = 
            this.getAdvicesAndAdvisorsForBean(bean.getClass(), beanName, (TargetSource)null);
                if (specificInterceptors != DO_NOT_PROXY) {
                    this.advisedBeans.put(cacheKey, Boolean.TRUE);
                    // 创建代理对象
                    Object proxy = 
                        this.createProxy(bean.getClass(), beanName, specificInterceptors, new SingletonTargetSource(bean));
                    this.proxyTypes.put(cacheKey, proxy.getClass());
                    return proxy;
                } else {
                    this.advisedBeans.put(cacheKey, Boolean.FALSE);
                    return bean;
                }
    }

所以，在执行属性填充后，才会创建代理对象。也因此，BeanPostProcessor 是 Spring 框架尤其重要的拓展接口。

由此可得，Bean 的流程图：

InstantiationAwareBeanPostProcessor

在 BeanPostProcessor 之上，有一个更细粒度的接口InstantiationAwareBeanPostProcessor。

其主要定义了三个方法：

  • postProcessBeforeInstantiation，返回值为 Object 为 Bean 对象。
  • postProcessAfterInstantiation，返回值为 boolean，如果为 false，则postProcessProperties 不会执行。
  • postProcessProperties，返回值为 PropertyValues。

注意：BeanPostProcessor 维护方法 postProcessBeforeInitialization 和 postProcessAfterInitialization。

而 InstantiationAwareBeanPostProcessor 维护的是 postProcessBeforeInstantiation 和 postProcessAfterInstantiation。两者是不同的，Initialization 和 Instantiation。

Instantiation 译作：实例化，特指创建 Bean 对象。

Initialization 译作：初始化，特指进行 Bean 属性填充等必要步骤。

执行顺序为：Instantiation -> properties -> Initialization

从流程图来理解，即为这样：

运行原理

在AbstractAutowireCapableBeanFactory的 createBean 中，其会先执行 BeforeInstantiation，之后再执行 doCreateBean 创建 Bean 实例。

 protected Object createBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args) throws BeanCreationException {
       // ...

        Object beanInstance;
        try {
            // 执行 BeforeInstantiation 方法
            beanInstance = this.resolveBeforeInstantiation(beanName, mbdToUse);
            // 如果 beanInstance 不为空，则已经有对象了，所以直接返回，不进行后续步骤。 
            if (beanInstance != null) {
                return beanInstance;
            }
        }
     	// ...

        try {
            // 调用 doCreateBean
            beanInstance = this.doCreateBean(beanName, mbdToUse, args);
            if (this.logger.isTraceEnabled()) {
                this.logger.trace("Finished creating instance of bean '" + beanName + "'");
            }

            return beanInstance;
        }
     	// ...
    }

因为 AfterInstantiation 在初始化后，属性赋值前执行，Spring 将其放在了populateBean中执行：

protected void populateBean(String beanName, RootBeanDefinition mbd, @Nullable BeanWrapper bw) {
        // ...
                while(var4.hasNext()) {
                    InstantiationAwareBeanPostProcessor bp = (InstantiationAwareBeanPostProcessor)var4.next();
                    // 当返回为 false 则直接返回
                    if (!bp.postProcessAfterInstantiation(bw.getWrappedInstance(), beanName)) {
                        return;
                    }
                }
        // ...
    }

拓展

感知

Spring 依赖注入的最大特点是所有的 Bean 对 Spring 容器的存在是没有意识的，这是 Spring 为了隔离业务代码和框架代码所做的努力。在 Spring 的思想中，解耦并不只是业务代码间的解耦，还包括业务代码与框架间的解耦。在没有感知(Aware)的情况下，Bean 作为业务方无法感知到容器的存在。但在实际项目中，又不可避免地要使用到 Spring 容器本身的功能。Aware 的目的是让 Bean 获得容器服务。

Aware 接口

package org.springframework.beans.factory;

public interface Aware {
    
}

Aware 接口是一个标记接口，其下有极其多实现。Aware 的子接口表示需要使用的 Spring 资源。

例如：BeanNameAware，BeanClassLoaderAware，BeanFactoryAware，ResourceLoaderAware。

Aware的实现

在 Bean 创建过程中会实现一部分 Aware，主要在AbstractAutowireCapableBeanFactory#invokeAwareMethods，该方法在同类下initializeBean方法中调用：

 protected Object initializeBean(String beanName, Object bean, @Nullable RootBeanDefinition mbd) {
        if (System.getSecurityManager() != null) {
            AccessController.doPrivileged(() -> {
                this.invokeAwareMethods(beanName, bean);
                return null;
            }, this.getAccessControlContext());
        } else {
            // 执行 Aware 方法
            this.invokeAwareMethods(beanName, bean);
        }

        Object wrappedBean = bean;
        if (mbd == null || !mbd.isSynthetic()) {
            wrappedBean = this.applyBeanPostProcessorsBeforeInitialization(bean, beanName);
        }

        try {
            this.invokeInitMethods(beanName, wrappedBean, mbd);
        } catch (Throwable var6) {
            throw new BeanCreationException(mbd != null ? mbd.getResourceDescription() : null, beanName, "Invocation of init method failed", var6);
        }

        if (mbd == null || !mbd.isSynthetic()) {
            wrappedBean = this.applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
        }

        return wrappedBean;
    }

invokeInitMethods：

private void invokeAwareMethods(String beanName, Object bean) {
        if (bean instanceof Aware) {
            // BeanName Aware 实现
            if (bean instanceof BeanNameAware) {
                ((BeanNameAware)bean).setBeanName(beanName);
            }
		   // BeanClassLoader Aware 实现
            if (bean instanceof BeanClassLoaderAware) {
                ClassLoader bcl = this.getBeanClassLoader();
                if (bcl != null) {
                    ((BeanClassLoaderAware)bean).setBeanClassLoader(bcl);
                }
            }
		   // BeanFactory Aware 实现
            if (bean instanceof BeanFactoryAware) {
                ((BeanFactoryAware)bean).setBeanFactory(this);
            }
        }
    }

Spring 在初始化 Bean 的过程中，判断 Bean 实现的 Aware 子接口的类型，调用相关的 set 方法将 Spring 内部对象注入到 Bean 中。

在 Spring 内部只执行了少部分 Aware，实际上，其他的 Aware 都依靠 BeanPostProcessor 进行注入。

例如：在[spring].context.support.ApplicationContextAwareProcessor 中，实现了BeanPostProcessor中的postProcessBeforeInitialization方法，对感知进行扫描与执行。

ApplicationContextAwareProcessor 中实现的 postProcessBeforeInitialization：

@Nullable
    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        // 检查 Bean 是否实现了本 Processor 负责的感知接口
        if (
            !(bean instanceof EnvironmentAware) && 
            !(bean instanceof EmbeddedValueResolverAware) && 
            !(bean instanceof ResourceLoaderAware) && 
            !(bean instanceof ApplicationEventPublisherAware) && 
            !(bean instanceof MessageSourceAware) && 
            !(bean instanceof ApplicationContextAware) && 
            !(bean instanceof ApplicationStartupAware)) {
            return bean;
        } else {
            AccessControlContext acc = null;
            if (System.getSecurityManager() != null) {
                acc = this.applicationContext.getBeanFactory().getAccessControlContext();
            }

            if (acc != null) {
                AccessController.doPrivileged(() -> {
                    this.invokeAwareInterfaces(bean);
                    return null;
                }, acc);
            } else {
                // 执行感知扫描并设置
                this.invokeAwareInterfaces(bean);
            }

            return bean;
        }
    }

invokeAwareInterfaces 方法：

private void invokeAwareInterfaces(Object bean) {
    	// 匹配并执行
        if (bean instanceof EnvironmentAware) {
            ((EnvironmentAware)bean).setEnvironment(this.applicationContext.getEnvironment());
        }

        if (bean instanceof EmbeddedValueResolverAware) {
            ((EmbeddedValueResolverAware)bean).setEmbeddedValueResolver(this.embeddedValueResolver);
        }

        if (bean instanceof ResourceLoaderAware) {
            ((ResourceLoaderAware)bean).setResourceLoader(this.applicationContext);
        }

        if (bean instanceof ApplicationEventPublisherAware) {
            ((ApplicationEventPublisherAware)bean).setApplicationEventPublisher(this.applicationContext);
        }

        if (bean instanceof MessageSourceAware) {
            ((MessageSourceAware)bean).setMessageSource(this.applicationContext);
        }

        if (bean instanceof ApplicationStartupAware) {
            ((ApplicationStartupAware)bean).setApplicationStartup(this.applicationContext.getApplicationStartup());
        }

        if (bean instanceof ApplicationContextAware) {
            ((ApplicationContextAware)bean).setApplicationContext(this.applicationContext);
        }

    }