Java 深入源码：Spring Bean 作用域、生命周期与自动装配解析

在 Controller 中注入这些 Bean 时，行为会有所不同。直接通过 context.getBean() 获取会触发新实例创建（针对原型等）。当使用 @Autowired 或 @Resource 注入 Prototype 作用域的 Bean 时，注入操作仅在初始化阶段执行一次，后续访问的是最初注入的实例，不会自动重新注入。

这里有个坑：Request 作用域。当使用 @Autowired 注入 Request 作用域的 Bean 到单例 Bean 中时，Spring 实际上注入的是一个代理对象而非真实实例。这个代理对象在应用启动时就被注入，但真实实例的创建被延迟到 HTTP 请求发生时。代理内部持有当前 HTTP 请求上下文的引用，调用方法时会从上下文中查找或创建新的真实实例。这种机制确保了每个请求线程都能获得独立的实例。

• Singleton(单例)：默认作用域，每个 Spring 容器中仅存在一个 Bean 实例。
• Prototype(原型)：每次请求 Bean 时都会创建一个新的实例。
• Request(请求)：每个 HTTP 请求创建一个新的 Bean 实例，仅在 Web 应用中有效。
• Session(会话)：每个用户会话创建一个 Bean 实例，仅在 Web 应用中有效。
• Application(应用)：整个 Web 应用共享一个 Bean 实例。

Bean 的生命周期

Bean 的生命周期指的是对象从创建到销毁的整个过程，主要分为五个阶段：

1. 实例化：容器通过反射调用构造器创建对象实例。
2. 属性赋值：容器注入依赖的属性值（例如 @Autowired）。
3. 初始化：
   • 通知方法调用：通过特定接口（如 BeanNameAware）注入框架相关依赖。
   • 前置处理：进行准备工作，如参数校验、资源加载。
   • 初始化回调：触发自定义逻辑（如实现 InitializingBean 接口的 afterPropertiesSet 方法）。
   • 后置处理：流程结束后执行清理或结果处理（如 AOP 中的 @After 通知）。
4. 使用 Bean：Bean 进入就绪状态，可被应用程序调用。
5. 销毁 Bean：容器关闭时触发。

示例代码

/**
 * 实现类
 */
@Component
@Slf4j
public class BeanLifeComponent implements BeanNameAware, BeanPostProcessor, InitializingBean {
    private Cat cat;

    // 1. 实例化：执行构造方法
    public BeanLifeComponent() {
        log.info("1.实例化：执行构造方法");
    }

    // 2. 属性赋值：执行 setter 方法
    @Autowired
    public void setCat(Cat cat) {
        log.info("2.属性赋值：执行 setter 方法");
        this.cat = cat;
    }

    // 3.1 通知方法调用
    @Override
    public void setBeanName(String name) {
        log.info("3.1 通知方法调用，bean name is {}", name);
    }

    // 3.2 前置处理
    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        log.info("3.3 前置处理，bean:{},beanName:{}", bean, beanName);
        return BeanPostProcessor.super.postProcessBeforeInitialization(bean, beanName);
    }

    // 3.3 初始化回调
    @Override
    public void afterPropertiesSet() {
        log.info("3.2 初始化回调");
    }

    // 3.4 后置处理
    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        log.info("3.4 后置处理，bean:{},beanName:{}", bean, beanName);
        return BeanPostProcessor.super.postProcessAfterInitialization(bean, beanName);
    }

    // 4. 使用 Bean
    public void use() {
        log.info("4.使用 Bean");
    }

    // 5. 销毁 Bean
    @PreDestroy
    public void preDestroy() {
        log.info("5.销毁 Bean");
    }
}

运行测试后，日志显示的顺序往往是：invokeInitMethods (初始化回调) → applyBeanPostProcessorsBeforeInitialization (前置处理) → applyBeanPostProcessorsAfterInitialization (后置处理)。这看起来与理论流程相矛盾，具体原因在源码解析部分说明。

源码解析

核心类是 AbstractAutowireCapableBeanFactory，它负责 Bean 的创建、依赖注入及初始化管理。

1. createBean 方法：调用了 doCreateBean 方法。
2. doCreateBean 方法：依次调用了 createBeanInstance（实例化）、populateBean（属性赋值）和 initializeBean（初始化）。
3. initializeBean 方法：这是初始化的核心，依次调用了 invokeAwareMethods、applyBeanPostProcessorsBeforeInitialization、invokeInitMethods 和 applyBeanPostProcessorsAfterInitialization。

为什么日志顺序看起来'冲突'？

根据源码，正确的生命周期流程应该是：前置处理 → 初始化回调 → 后置处理。那为什么实际日志里 initMethods 跑在了前面？

关键点在于：BeanPostProcessor 本身也是 Bean。当 Spring 初始化一个 BeanPostProcessor 实现类（比如上面的 BeanLifeComponent）时，这个过程是递归的。

• 创建普通 Bean：按照源码顺序正常执行 Before → Init → After。
• 创建 BeanPostProcessor Bean 时：Spring 需要先让这个 BeanPostProcessor 对象本身完成初始化（调用 invokeInitMethods），然后才能将它加入到 BeanPostProcessor 列表中，供后续其他 Bean 使用。
• 对于 BeanPostProcessor 自己来说：它的 afterPropertiesSet 方法会在 invokeInitMethods 中执行（即日志里的 3.2），但它自己的 postProcessBeforeInitialization / postProcessAfterInitialization 方法不会在它自己的创建过程中被调用！

所以日志显示的情况其实是：一个 BeanPostProcessor 实现类的初始化过程。3.2 是该 BeanPostProcessor 自己的 afterPropertiesSet，而 3.3 和 3.4 是其他已注册的 BeanPostProcessor 对这个 Bean 的处理。这就解释了为什么看起来顺序反了。

SpringBoot 自动装配

自动装配的作用是注册 Bean 到 Spring 容器，不需要手动配置。通过约定大于配置的方式减少复杂性。简单来说，就是将依赖 Jar 包中的配置类以及 Bean 加载到 Ioc 容器的过程。

加载 Bean 的原理

在 pom.xml 引入第三方依赖后，SpringBoot 项目启动时能识别这些依赖并自动加载。如果将自定义代码作为第三方依赖引入，需要保证扫描路径正确。

1. @ComponentScan

告诉 Spring 容器去哪里扫描被 @Component、@Service 等注解标记的类。

@SpringBootApplication
@ComponentScan("com.example.springprincicle.component")
public class SpringPrincipleApplication {
    public static void main(String[] args) {
        SpringApplication.run(SpringPrincipleApplication.class, args);
    }
}

2. @Import

用于将一个或多个配置类导入到当前上下文。

用法一：导入单个类

@SpringBootApplication
@Import(TestConfig.class)
public class SpringPrincipleApplication { ... }

用法二：ImportSelector 接口

public class MyImportSelector implements ImportSelector {
    @Override
    public String[] selectImports(AnnotationMetadata importingClassMetadata) {
        return new String[]{"com.example.springprincicle.component.TestConfig"};
    }
}

为了更友好，通常由依赖开发者提供一个封装了 @Import 的自定义注解。

@SpringBootApplication 源码解析

这是一个组合注解，包含三个核心功能：

1. @ComponentScan：默认扫描路径为标注类的类路径。排除不需要扫描的配置类，防止重复注册。
2. @SpringBootConfiguration：标记该类为 Spring 配置类，并提供索引支持加速启动。
3. @EnableAutoConfiguration：这是自动装配的核心。

AutoConfigurationImportSelector 实现了 DeferredImportSelector 接口，负责动态加载自动配置类。在 Spring Boot 3.x 中，遵循'约定优于配置'，第三方依赖库需将其自动配置类定义在 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件中。

启动时，getCandidateConfigurations 方法会扫描类路径下的 .imports 文件，读取所有找到的自动配置类名，并进行过滤和去重，最终加载到容器中。这也体现了 Spring Framework 的向后兼容性设计，保留了 spring.factories 的支持机制。