Spring源码分析-171主机测评

参考原文链接：

https://blog.csdn.net/weixin_39651041/article/details/129674784

核心类图

顶层父类接口和类作用定义及详细类图

BeanFactory

BeanFactory 是访问 Spring Bean 容器的根接口

定义根据 Bean name 获取 Bean 的接口

SimpleJndiBeanFactory

基于 JNDI ¹的 Spring BeanFactory 接口的简单实现

不支持枚举 bean 定义，因此不实现 org.springframework.beans.factory.ListableBeanFactory 接口

ListableBeanFactory

扩展 BeanFactory 接口，可以枚举其所有的 Bean 实例

预加载所有 Bean 定义的 BeanFactory 实现（例如基于 XML 的工厂）可以实现此接口

HierarchicalBeanFactory

扩展 BeanFactory 的接口，实现了 Bean 工厂的分层，扩展了工厂分层的功能

AutowireCapableBeanFactory

扩展 BeanFactory 接口，使有能力自动装配 ApplicationContext 管理之外的 Bean

ApplicationContext 接口没有继承 AutowireCapableBeanFactory，因为应用代码很少用到此功能，如果需要的话，可以调用 ApplicationContext 的 getAutowireCapableBeanFactory 方法，来获取此接口的实例

StaticListableBeanFactory

BeanFactory 的静态实现，它允许以编程方式注册现有的单例实例

不支持原型 Bean ²或别名

作为 ListableBeanFactory 接口的简单实现的示例，管理现有的 Bean 实例，而不是基于 Bean 定义创建新的实例，并且不实现任何扩展的 SPI ³接口（如 org.springframework.beans.factory.config.ConfigurableBeanFactory）

对于基于 Bean 定义的成熟工厂，请查看 DefaultListableBeanFactory

StubBeanFactory

StaticListableBeanFactory 的扩展，它实现了 AutowireCapableBeanFactory，以便允许 ApplicationContextAware 单例的 Bean 初始化

ConfigurableBeanFactory

大多数 bean factories 要实现的配置接口。提供用于配置 Bean 工厂的工具，以及 BeanFactory 接口中的 Bean 工厂客户端方法

此接口不适用于普通应用程序代码：坚持使用 BeanFactory 或 org.springframework.beans.factory.ListableBeanFactory 以满足典型需求

此扩展接口只是为了允许框架内部即插即用⁴⁵⁶⁷和对 Bean 工厂配置方法的特殊访问

ConfigurableListableBeanFactory

大多数可列出的 Bean 工厂要实现的配置接口。除了 ConfigurableBeanFactory 之外，它还提供了分析和修改 Bean 定义以及预实例化单例的工具

BeanFactory 的这个子接口不适合在普通应用程序代码中使用：对于典型用例，请坚持使用 org.springframework.beans.factory.BeanFactory 或 ListableBeanFactory

此接口只是为了允许框架内部即插即用⁴⁵⁶⁷，即使需要访问 Bean 工厂配置方法也是如此

ApplicationContext

Spring的核心，定义上下文骨架，为应用程序提供配置的中央接口

在应用程序运行时是只读的，可以通过重新加载，来实现支持此功能

主要是各种属性的 get 方法

WebApplicationContext

专门为Web 应用程序提供配置的接口

从 WebApplicationContext 中可以获得 ServletContext 的引用；会定义一个众所周知的应用程序属性名称，根上下文必须在引导过程中绑定到该名称

与 ApplicationContext 一样，WebApplicationContext 也是分层的。每个应用程序都有一个根上下文，而应用程序中的每个 servlet（包括 MVC 框架中的调度程序 servlet）都有自己的子上下文

ConfigurableApplicationContext

框架内部扩展接口

此处封装了配置和生命周期方法⁸，以避免它们对 ApplicationContext 客户端代码显而易见。当前方法应仅由启动和关闭代码使用

主要是各种属性的配置

AbstractApplicationContext

ApplicationContext 的抽象实现

不强制要求用于配置的存储类型；只是实现通用上下文功能

使用模板方法设计模式，需要具体的子类来实现抽象方法

AbstractRefreshableApplicationContext

ApplicationContext 实现的基类

主要是和容器的刷新与创建有关，调用 refreshBeanFactory 方法完成 applicationContext.xml 的解析操作，完成容器的初始化操作

AbstractRefreshableConfigApplicationContext

用于添加对指定配置位置的通用处理；直白一点就是加载容器刷新时的配置文件的通用操作

该类的两个子类，都是基于 xml 配置文件，将会有各自的定制的读取配置文件操作，所以该类提供的是读取配置文件通用操作，提供拓展点

AbstractXmlApplicationContext

从包含 Bean 定义的 XML 文件加载 Bean 的方便基类；使用 XmlBeanDefinitionReader 进行解析 XML

子类只需要实现 getConfigResources 和/或 getConfigLocations 方法

它们可能会覆盖 getResourceByPath 钩子⁶以特定于环境的方式解释相对路径，和/或 getResourcePatternResolver 以扩展模式解析

FileSystemXmlApplicationContext

独立的 XML 应用程序上下文，从文件系统或 URL 获取上下文定义文件，将纯路径解释为相对文件系统位置（例如“mydir/myfile.txt”）。适用于测试工具以及独立环境

有盘符表示的是文件绝对路径， file: 前缀可加可不加

也可以使用 classpath 路径，如果要使用，需要前缀 classpath:

ClassPathXmlApplicationContext

从类路径中获取上下文定义文件，将普通路径解释为包含包路径的类路径资源名称

从 classpath 路径下加载 xml 配置文件

默认是指项目的 classpath 路径下面， classpath: 前缀是可加可不加的

如果要使用绝对路径，需要加上 file: 前缀，表示这是绝对路径

AbstractRefreshableWebApplicationContext

AbstractRefreshableApplicationContext 的子类，AbstractRefreshableApplicationContext 的 Web 环境

AnnotationConfigWebApplicationContext

org.springframework.web.context.WebApplicationContext 实现，处理 @Configuration @Component 以及使用jakarta.inject 注解的 JSR-330 兼容类

允许逐个注册类（将类名指定为配置位置）以及通过类路径扫描（将基本包指定为配置位置）

这实质上相当于 Web 环境的 org.springframework.context.annotation.AnnotationConfigApplicationContext

XmlWebApplicationContext

org.springframework.web.context.WebApplicationContext 实现，它从 XML 文档中获取其配置，由XmlBeanDefinitionReader 来解析

这实质上相当于 Web 环境的 org.springframework.context.support.GenericXmlApplicationContext

根 context 默认从 /WEB-INF/applicationContext.xml 获取配置文件

GroovyWebApplicationContext

org.springframework.web.context.WebApplicationContext 实现，它从 Groovy 文档中获取其配置，由 org.springframework.beans.factory.groovy.GroovyBeanDefinitionReader 来解析

这实质上相当于 Web 环境的 org.springframework.context.support.GenericGroovyApplicationContext

根 context 默认从 /WEB-INF/applicationContext.groovy 获取配置文件

GenericApplicationContext

通用的 ApplicationContext 实现；采用混合方式（XML、注解等）处理 bean 的定义，而不是采用特定的 bean 定义方式来创建bean

内部有一个 DefaultListableBeanFactory 实例；实现 BeanDefinitionRegistry 接口，以便允许对其应用任何 Bean 定义读取器

GenericXmlApplicationContext

具有内置 XML 支持的便捷应用程序上下文

是 ClassPathXmlApplicationContext 和 FileSystemXmlApplicationContext 的灵活替代方案，可通过 setter 进行配置，最终 refresh() 调用激活上下文

GenericGroovyApplicationContext

org.springframework.context.ApplicationContext 实现，它扩展了 GenericApplicationContext 并实现了 GroovyObject，以便可以使用 Groovy 语法代替 getBean 来检索 bean

AnnotationConfigApplicationContext

注解配置的 ApplicationContext 实现

处理 @Configuration，包括使用 jakarta.inject 注解的纯 @Component 类型和符合 JSR-330 的类

ConfigurableWebApplicationContext

ConfigurableApplicationContext 的 Web 实现

StaticApplicationContext

ApplicationContext 实现，它支持以编程方式注册 bean 和消息，而不是从外部配置源读取 Bean 定义。主要用于测试

StubWebApplicationContext

接受对象实例注册的 Stub WebApplicationContext

Aware

Spring 的依赖注入最大亮点就是所有的 Bean 对 Spring 容器的存在是没有意识的

但是在实际项目中，我们不可避免的要用到 Spring 容器本身提供的资源，这时候要让 Bean 主动意识到 Spring 容器的存在，才能调用 Spring 所提供的资源，这就是 Spring Aware

LifeCycle

定义启动/停止生命周期控制方法的通用接口

public interface Lifecycle {

/**
* Start this component.
*/
void start();

/**
* Stop this component, typically in a synchronous fashion, such that the component is
* fully stopped upon return of this method.
*/
void stop();

/**
* Check whether this component is currently running.
*/
boolean isRunning();

}

InitializingBean

Spring 提供的拓展性接口，InitializingBean 接口为 Bean 提供了属性初始化后的处理方法，它只有一个 afterPropertiesSet() 方法，凡是继承该接口的类，在 Bean 的属性初始化后都会执行该方法，进行其总体配置和最终初始化验证

public interface InitializingBean {

/**
* Invoked by the containing {@code BeanFactory} after it has set all bean properties
* and satisfied {@link BeanFactoryAware}, {@code ApplicationContextAware} etc.
* This method allows the bean instance to perform validation of its overall
* configuration and final initialization when all bean properties have been set.
* @throws Exception in the event of misconfiguration (such as failure to set an
* essential property) or if initialization fails for any other reason
*/
void afterPropertiesSet() throws Exception;

}

ResourceLoader

用于加载资源（例如，类路径或文件系统资源）的策略接口

Spring 中整合了获取资源的工具，就是使用 Resource 接口。此接口是 Spring 为了统一读取诸如本地文件、classpath 项目路径下的文件、url 互联网上的文件等不同类型渠道的资源，封装隐藏如打开流、关闭流、报错处理等大量重复模板代码，而专程设计提供的接口类

而 Spring 框架为了更方便的获取资源，尽量弱化程序员对各个 Resource 接口实现类的感知与分辨，降低学习与使用成本，定义了另一个接口，就是：ResourceLoader接口

public interface ResourceLoader {

/** Pseudo URL prefix for loading from the class path: "classpath:". */
String CLASSPATH_URL_PREFIX = ResourceUtils.CLASSPATH_URL_PREFIX;

/**
* Return a {@code Resource} handle for the specified resource location.
*/
Resource getResource(String location);

/**
* Expose the {@link ClassLoader} used by this {@code ResourceLoader}.
*/
@Nullable
ClassLoader getClassLoader();
}

ApplicationEventPublisher

封装事件发布功能的接口

函数式接口

@FunctionalInterface
public interface ApplicationEventPublisher {

/**
* Notify all matching listeners registered with this
* application of an application event. Events may be framework events
* (such as ContextRefreshedEvent) or application-specific events.
*/
default void publishEvent(ApplicationEvent event) {
publishEvent((Object) event);
}

/**
* Notify all matching listeners registered with this
* application of an event.
*/
void publishEvent(Object event);
}

AutoCloseable

当一个资源类实现了该接口 close 方法，在使用 try-with-resources 语法创建的资源抛出异常后，JVM 会自动调用 close 方法进行资源释放；当没有抛出异常正常退出 try 代码块时也会自动调用 close 方法。像数据库链接类 Connection，io 类 InputStream 或 OutputStream 都直接或者间接实现了该接口

public interface AutoCloseable {
/**
* Closes this resource, relinquishing any underlying resources.
* This method is invoked automatically on objects managed by the
* {@code try}-with-resources statement.
*/
void close() throws Exception;
}

配置文件加载Bean

加载配置文件

new ClassPathXmlApplicationContext(); 初始化

使用构造函数传入配置文件路径，初始化

setConfigLocations(configLocations); 按顺序、覆盖规则加载配置文件路径，需要对路径进行处理，调用的方法比较多

refresh(); refresh() 方法是 ApplicationContext 接口的一个核心方法，用于初始化和刷新 Spring 应用程序上下文

prepareRefresh(); 为上下文刷新做准备，包括设置Spring容器启动时间、活跃状态/关闭状态刷新、初始化context environment（上下文环境）中的占位符属性来源、验证必要属性

obtainFreshBeanFactory(); 重新创建一个Bean工厂

refreshBeanFactory(); 刷新Bean工厂

DefaultListableBeanFactory beanFactory = createBeanFactory(); 定义Bean工厂

beanFactory.setSerializationId(getId()); 设置序列化ID，用于分布式环境

customizeBeanFactory(beanFactory); 自定义和配置BeanFactory的行为

loadBeanDefinitions(beanFactory); 加载bean定义到 BeanFactory

new XmlBeanDefinitionReader(beanFactory); 从XML配置文件中读取bean定义

initBeanDefinitionReader(beanDefinitionReader); 初始化BeanDefinitionReader 实例

loadBeanDefinitions(beanDefinitionReader); 加载BeanDefinitionReader 实例到上下文

prepareBeanFactory(beanFactory); 为后续的bean注册和初始化过程做好准备，包括设置类加载器ClassLoader ，注册相关配置

postProcessBeanFactory(beanFactory); 上下文的子类可以对Bean工厂进行后置处理

invokeBeanFactoryPostProcessors(beanFactory); 实例化并调用所有已注册的bean

对不同类型的Bean分类添加到链表: BeanFactoryPostProcessor 和 BeanDefinitionRegistryPostProcessor，作用时BeanDefinitionRegistryPostProcessor 允许在 bean 定义注册阶段动态添加 Bean 定义；而 BeanFactoryPostProcessor 则在所有 Bean 定义加载完成后、Bean 实例化之前执行，用于修改现有 Bean 定义的属性

BeanDefinitionRegistryPostProcessor 实现，查找Bean名称、遍历同时也是PriorityOrdered 接口的实例，对其根据PriorityOrdered接口的优先级值排序，然后执行

继续处理 BeanDefinitionRegistryPostProcessor 的实现，同理，不过按照 Ordered 接口查找和排序

调用所有剩余的 BeanDefinitionRegistryPostProcessor 实例，迭代处理，因为一个Bean可能会注册新的Bean，按Ordered 接口排序

递归调用

invokeBeanFactoryPostProcessors*(registryProcessors, beanFactory); invokeBeanFactoryPostProcessors*(regularPostProcessors, beanFactory);

registerBeanPostProcessors(beanFactory); 从Spring容器中找出的BeanPostProcessor接口的bean，并设置到BeanFactory的属性中，进行注册

PostProcessorRegistrationDelegate.*registerBeanPostProcessors*(beanFactory, this); 委托给了PostProcessorRegistrationDelegate 进行调用

String[] postProcessorNames = beanFactory.getBeanNamesForType(BeanPostProcessor.class, true, false); 通过Bean的类型获取Bean的名称

注册BeanPostProcessorChecker ，当一个bean在BeanPostProcessor 实例化期间被创建时且当一个bean不符合被所有BeanPostProcessor处理的条件时，记录一条信息消息

对Bean按实现不同接口进行分类PriorityOrdered 、Ordered 和其他

注册实现了PriorityOrdered 接口的BeanPostProcessors

注册实现了Ordered 接口的BeanPostProcessors

注册其他常规BeanPostProcessors

重新注册所有内部BeanPostProcessors

检测Bean中是否有实现ApplicationListener接口的内部Bean，并将其注册为应用程序事件监听器

beanPostProcess.end(); 空方法，表示后处理阶段已经完成，可自定义

initMessageSource(); 国际化

initApplicationEventMulticaster(); 在Spring容器中初始化事件广播器，事件广播器用于事件的发布

getBeanFactory(); 获取当前Bean实例

是否存在ApplicationEventMulticaster ，没有就创建默认的SimpleApplicationEventMulticaster ，并为单例供其他Bean使用

onRefresh(); 初始化特定上下文子类中的其他特殊bean

registerListeners(); 检查并注册监听器Bean

首先注册静态指定的监听器

注册Bean名称为监听器的监听器

处理早期事件，处理在应用上下文刷新之前捕获的早期事件。这些事件可能在应用上下文完全初始化之前就已经发布，因此它们被存储在一个集合中，然后在ApplicationEventMulticaster可用时进行处理。earlyApplicationEvents集合在处理完这些事件后被设置为null

finishBeanFactoryInitialization(beanFactory); 实例化所有剩余非懒加载单例

初始化转换服务

如果BeanFactory中没有注册任何嵌入式值解析器，它会添加一个默认的解析器

初始化LoadTimeWeaverAware beans，查找所有实现了LoadTimeWeaverAware接口的beans，并提前初始化它们。这样做是为了允许这些beans注册它们的转换器

停止使用临时ClassLoader 进行类型匹配

冻结配置，不希望配置有进一步的更改

实例化所有剩余的非懒加载单例

finishRefresh() 发布，结束刷新

clearResourceCaches(); 清除上下文级别的资源缓存

initLifecycleProcessor(); 初始化生命周期处理器，同样为单例，存在就创建，不存在就创建默认的new DefaultLifecycleProcessor();

getLifecycleProcessor().onRefresh(); 首先将刷新同步到生命周期

publishEvent(new ContextRefreshedEvent(this)); 发布事件到Spring框架的事件传播机制中

检查传入的事件对象是否是ApplicationEvent的实例，如果是，就直接使用这个实例；如果不是，则创建一个新的PayloadApplicationEvent实例，并将原始事件作为有效载荷（payload）。如果eventType为null，则尝试从PayloadApplicationEvent实例中获取ResolvableType

处理早期事件

如果存在父上下文（parent），则尝试将事件发布到父上下文中。如果父上下文是AbstractApplicationContext的实例，则调用其publishEvent方法；否则，调用父上下文的publishEvent方法

LiveBeansView.registerApplicationContext(this); 若非原生镜像，则在非原生镜像（native image）环境中注册应用程序上下文到LiveBeansView MBean，使其可以通过JMX（Java Management Extensions）进行监控和管理

resetCommonCaches(); 位于finally块中，用于清除缓存，清除用于加速反射操作缓存、加速注解处理缓存、处理泛型类型缓存、JavaBean属性和方法的内省结果的缓存

contextRefresh.end(); 标记上下文刷新结束

获取Bean

applicationContext.getBean("A"); 获取Bean

assertBeanFactoryActive(); 安全检查，检查Spring容器中的BeanFactory是否处于活动状态

getBeanFactory().getBean(name); 获取Bean，AbstractApplicationContext 的方法

doGetBean(name, null, null, false); AbstractBeanFactory 的泛型方法，获取Bean

接受四个参数：

name：要获取的bean的名称

requiredType：期望返回的bean的类型，可以为null

args：创建bean时需要的参数，可以为null

typeCheckOnly：如果为true，则只进行类型检查，不实际创建bean

transformedBeanName(name); 转换Bean名称，传入的bean名称转换为实际使用的名称，例如，处理别名

检查单例缓存，如果bean已经在单例缓存中，并且不需要额外参数来创建bean，则直接从缓存中获取返回，如果bean不在单例缓存中，进行后续操作

处理循环引用，抛出异常

检查父工厂，如果当前工厂不包含bean定义，则尝试从父工厂中获取

标记bean为已创建

处理依赖关系，检查并创建当前bean依赖的其他bean

创建Bean实例，根据bean的作用域（单例、原型、其他自定义作用域），创建bean实例

处理异常和清理

对Bean实例进行适配操作以满足requiredType的要求然后返回

可以调用方法或进行其他后续操作

配置文件加载Bean总结

为什么在Bean加载时要使用这么多的super关键字？

因为ApplicationContext 存在层级结构，在加载子类构造函数前必须先加载父类的构造函数，如果不使用super关键字默认会加载父类的无参构造函数，这可能不是我们想要的，所以需要显示的指定加载父类的那个构造方法，使父类加载某些特定的资源，确保从最顶层的父类开始，逐层向下初始化，直到当前子类，保证整个初始化过程完成

this()的作用是什么？

this()会加载本类中的其他构造方法，默认通过参数列表识别要掉的构造方法，不允许递归调用

Spring中的层级结构作用是什么？

Spring框架中的层级结构主要指的是ApplicationContext的层级结构，主要具有以下作用：

配置隔离：不同的上下文可以加载不同的配置文件，这样可以在不同的层次上隔离配置，使得配置更加模块化和灵活，例如在父上下文中定义全局的配置，而在子上下文中定义特定环境的配置

属性和Bean的继承：子上下文可以继承父上下文的属性和Bean。这意味着在父上下文中定义的Bean和属性可以被子上下文直接使用，无需重复定义，同时也可以针对特定场景进行拓展和覆盖

灵活调用：子上下文可以灵活调用父上下文的方法，父上下文中可能调用了其他包或类中的多个方法并进行了封装，子类在调用时直接调用父类的方法就可以，类似于工厂模式中通过抽象接口解耦具体实现，上下文层级通过父接口定义标准行为，子类实现具体逻辑，但上下文层级更强调配置的继承与隔离，区别在于上下文有多层

共享资源：在父子上下文中共享资源，例如主题资源、消息源等，可以减少资源的冗余，提高资源利用率

应用分层：在多层架构的应用中，可以为不同的层（如表示层、业务逻辑层、数据访问层）创建不同的上下文，这样可以更好地组织和管理不同层的Bean

refresh()方法使用synchronized关键字的原因？

创建互斥锁，防止并发刷新导致容器状态不一致，避免加载出错，也避免Bean还没有加载完成就被调用

StartupStep的作用是什么？

StartupStep是一个用于记录和测量应用程序在启动过程中的各个阶段耗时的工具，对于性能调优和故障排查非常有用

为什么要使用这么多的预加载机制，比如prepareRefresh()？

使用预加载机制能够保证必要的资源优先加载，正确和完整的被加载

符合单一职责原则，环境等资源的加载不应该和上下文和Bean等具体的加载耦合在一起，好处是修改代码或调用的时更加灵活

为什么要使用许多contextRefresh.end()这样的空方法？

使用这些方法的原因是为了方便用户重写这些方法，便于自定义加载结束后的行为，比如记录日志、回调等

符合开放封闭原则，提供重写方法，用户不必要修改原有代码，对扩展开放，对修改封闭

注释

JNDI是Java平台中用于访问命名和目录服务的API，为Java应用程序提供了一种统一的方式来访问各种不同的命名和目录服务，如LDAP、DNS、RMI等，而不需要关心底层的具体实现细节 ↩︎

原型Bean在Spring框架中的应用场景通常涉及到需要每次使用时都创建一个新实例的情况，他们之间相互隔离，从而避免了由于实例之间的数据共享所带来的潜在冲突或安全问题，通常使用@Scope("prototype")定义原型Bean ↩︎

SPI是一种服务发现机制，它允许框架或应用程序在运行时动态加载服务的实现，是专门提供给服务提供者或扩展框架功能的开发者使用的一个接口。它通过接口定义服务行为，并允许多个服务提供者在运行时为该接口提供不同的实现。不同于API的是，API是提供一组标准化的接口，是被调用方依赖的，即应用程序需要引入API所在的库才能使用其功能。而SPI是调用方依赖的，即框架或库需要引入第三方实现类的库才能加载和调用。SPI允许在运行时动态加载和替换实现类，提供了一种灵活的扩展机制 ↩︎

框架内部即插即用（Plug-and-Play）是一种设计模式，它允许框架在运行时动态加载和卸载模块或组件，而无需停止和重新启动整个系统，框架设计时预留扩展点，如回调、钩子和事件，允许开发者在特定时机插入自定义代码 ↩︎ ↩︎

回调是一种将函数作为参数传递给另一个函数，以便在某个操作完成或特定事件发生时被调用的技术。在编程中，回调通常用于异步编程和事件驱动编程 ↩︎ ↩︎

钩子是一种允许用户或框架自定义或扩展某些操作的机制。在软件中，钩子通常用于拦截和修改系统或库的内部操作 ↩︎ ↩︎ ↩︎

事件是一种通知机制，用于在发生特定动作或状态改变时通知感兴趣的对象。事件驱动编程是一种编程范式，其中对象之间的交互是通过事件的产生和消费来实现的 ↩︎ ↩︎

bean的生命周期方法指的是在bean的创建、初始化、使用和销毁过程中，Spring容器会自动调用的一系列方法。这些方法允许开发者在bean的不同生命周期阶段插入自定义逻辑，其中关键方法包括构造函数、@PostConstruct注解方法（依赖注入完成后调用，通常用于初始化工作）、init-method属性（依赖注入完成后调用，可以在xml配置文件中指定一个方法作为初始化方法）、@PreDestroy注解方法（在bean销毁前调用，通常用于清理工作）、destroy-method属性（在bean销毁前调用，可以在xml配置文件中指定一个方法作为销毁方法）、DisposableBean接口（实现DisposableBean接口的destroy()方法也会在bean销毁时被调用）、BeanPostProcessor接口（BeanPostProcessor接口提供了两个方法：postProcessBeforeInitialization和postProcessAfterInitialization。这两个方法分别在bean的初始化前后被调用，允许开发者插入自定义逻辑） ↩︎