Bean
的生成过程
1.生成 BeanDefinition
Spring
启动的时候会进行扫描,会先调用org.springframework.context.annotation.ClassPathScanningCandidateComponentProvider#scanCandidateComponents(String basePackage)
扫描某个包路径,并得到BeanDefinition
的Set
集合。
Spring
扫描底层流程:https://www.processon.com/view/link/61370ee60e3e7412ecd95d43
- 首先,通过
ResourcePatternResolver
获得指定包路径下的所有.class
文件(Spring
源码中将此文件包装成了Resource
对象) - 遍历每个
Resource
对象 - 利用
MetadataReaderFactory
解析Resource
对象得到MetadataReader
(在Spring
源码中MetadataReaderFactory
具体的实现类为CachingMetadataReaderFactory
,MetadataReader
的具体实现类为SimpleMetadataReader
) - 利用
MetadataReader
进行excludeFilters
和includeFilters
,以及条件注解@Conditional
的筛选(条件注解并不能理解:某个类上是否存在@Conditional
注解,如果存在则调用注解中所指定的类的match
方法进行匹配,匹配成功则通过筛选,匹配失败则pass掉。) - 筛选通过后,基于
metadataReader
生成ScannedGenericBeanDefinition
- 再基于
metadataReader
判断是不是对应的类是不是接口或抽象类 - 如果筛选通过,那么就表示扫描到了一个
Bean
,将ScannedGenericBeanDefinition
加入结果集
MetadataReader
表示类的元数据读取器,主要包含了一个AnnotationMetadata
,功能有
- 获取类的名字、
- 获取父类的名字
- 获取所实现的所有接口名
- 获取所有内部类的名字
- 判断是不是抽象类
- 判断是不是接口
- 判断是不是一个注解
- 获取拥有某个注解的方法集合
- 获取类上添加的所有注解信息
- 获取类上添加的所有注解类型集合
值得注意的是,CachingMetadataReaderFactory
解析某个.class
文件得到MetadataReader
对象是利用的ASM
技术,并没有加载这个类到JVM
。并且,最终得到的ScannedGenericBeanDefinition
对象,beanClass
属性存储的是当前类的名字,而不是class
对象。(beanClass
属性的类型是Object
,它即可以存储类的名字,也可以存储class
对象)
最后,上面是说的通过扫描得到BeanDefinition
对象,我们还可以通过直接定义BeanDefinition
,或解析spring.xml
文件的<bean/>
,或者@Bean
注解得到BeanDefinition
对象。(后面会分析@Bean
注解是怎么生成BeanDefinition
的)。
2.合并 BeanDefinition
通过扫描得到所有BeanDefinition
之后,就可以根据BeanDefinition
创建Bean
对象了,但是在Spring
中支持父子BeanDefinition
,和Java
父子类类似,但是完全不是一回事。
父子BeanDefinition
实际用的比较少,使用是这样的,比如:
<bean id="parent" class="com.zhouyu.service.Parent" scope="prototype"/>
<bean id="child" class="com.zhouyu.service.Child"/>
这么定义的情况下,child
是单例Bean
。
<bean id="parent" class="com.zhouyu.service.Parent" scope="prototype"/>
<bean id="child" class="com.zhouyu.service.Child" parent="parent"/>
但是这么定义的情况下,child
就是原型Bean
了。
因为child
的父BeanDefinition
是parent
,所以会继承parent
上所定义的scope
属性。
而在根据child
来生成Bean
对象之前,需要进行BeanDefinition
的合并,得到完整的child
的BeanDefinition
。
3.加载类
BeanDefinition
合并之后,就可以去创建Bean
对象了,而创建Bean
就必须实例化对象,而实例化就必须先加载当前BeanDefinition
所对应的class
,在AbstractAutowireCapableBeanFactory
类的createBean()
方法中,一开始就会调用:
Class<?> resolvedClass = resolveBeanClass(mbd, beanName);
这行代码就是去加载类,该方法是这么实现的:
if (mbd.hasBeanClass()) {
return mbd.getBeanClass();
}
if (System.getSecurityManager() != null) {
return AccessController.doPrivileged((PrivilegedExceptionAction<Class<?>>) () ->
doResolveBeanClass(mbd, typesToMatch), getAccessControlContext());
}
else {
return doResolveBeanClass(mbd, typesToMatch);
}
public boolean hasBeanClass() {
return (this.beanClass instanceof Class);
}
如果beanClass
属性的类型是Class
,那么就直接返回,如果不是,则会根据类名进行加载(doResolveBeanClass
方法所做的事情)
会利用BeanFactory
所设置的类加载器来加载类,如果没有设置,则默认使用ClassUtils.getDefaultClassLoader()
所返回的类加载器来加载。
ClassUtils.getDefaultClassLoader()
- 优先返回当前线程中的
ClassLoader
- 线程中类加载器为
null
的情况下,返回ClassUtils
类的类加载器 - 如果
ClassUtils
类的类加载器为空,那么则表示是Bootstrap
类加载器加载的ClassUtils
类,那么则返回系统类加载器
4.实例化前
当前BeanDefinition
对应的类成功加载后,就可以实例化对象了,但是在Spring
中,实例化对象之前,Spring
提供了一个扩展点,允许用户来控制是否在某个或某些Bean
实例化之前做一些启动动作。这个扩展点叫InstantiationAwareBeanPostProcessor.postProcessBeforeInstantiation()
。比如:
@Component
public class ZhouyuBeanPostProcessor implements InstantiationAwareBeanPostProcessor {
@Override
public Object postProcessBeforeInstantiation(Class<?> beanClass, String beanName) throws BeansException {
if ("userService".equals(beanName)) {
System.out.println("实例化前");
}
return null;
}
}
如上代码会导致,在userService
这个Bean
实例化前,会进行打印。
值得注意的是,postProcessBeforeInstantiation()
是有返回值的,如果这么实现:
@Component
public class ZhouyuBeanPostProcessor implements InstantiationAwareBeanPostProcessor {
@Override
public Object postProcessBeforeInstantiation(Class<?> beanClass, String beanName) throws BeansException {
if ("userService".equals(beanName)) {
System.out.println("实例化前");
return new UserService();
}
return null;
}
}
userService
这个Bean
,在实例化前会直接返回一个由我们所定义的UserService
对象。如果是这样,表示不需要Spring
来实例化了,并且后续的Spring
依赖注入也不会进行了,会跳过一些步骤,直接执行初始化后这一步。
5.实例化
在这个步骤中就会根据BeanDefinition
去创建一个对象了。
5.1Supplier
创建对象
首先判断BeanDefinition
中是否设置了Supplier
,如果设置了则调用Supplier
的get()
得到对象。
得直接使用BeanDefinition
对象来设置Supplier
,比如:
AbstractBeanDefinition beanDefinition = BeanDefinitionBuilder.genericBeanDefinition().getBeanDefinition();
beanDefinition.setInstanceSupplier(new Supplier<Object>() {
@Override
public Object get() {
return new UserService();
}
});
context.registerBeanDefinition("userService", beanDefinition);
5.2工厂方法创建对象
如果没有设置Supplier
,则检查BeanDefinition
中是否设置了factoryMethod
,也就是工厂方法,有两种方式可以设置factoryMethod
,比如:
方式一:
<bean id="userService" class="com.zhouyu.service.UserService" factory-method="createUserService" />
对应的UserService
类为:
public class UserService {
public static UserService createUserService() {
System.out.println("执行createUserService()");
UserService userService = new UserService();
return userService;
}
public void test() {
System.out.println("test");
}
}
方式二:
<bean id="commonService" class="com.zhouyu.service.CommonService"/>
<bean id="userService1" factory-bean="commonService" factory-method="createUserService" />
对应的CommonService
的类为:
public class CommonService {
public UserService createUserService() {
return new UserService();
}
}
Spring
发现当前BeanDefinition
方法设置了工厂方法后,就会区分这两种方式,然后调用工厂方法得到对象。
值得注意的是,我们通过@Bean
所定义的BeanDefinition
,是存在factoryMethod
和factoryBean
的,也就是和上面的方式二非常类似,@Bean
所注解的方法就是factoryMethod
,AppConfig
对象就是factoryBean
。如果@Bean
所所注解的方法是static
的,那么对应的就是方式一。
5.3推断构造方法
推断完构造方法后,就会使用构造方法来进行实例化了。
在推断构造方法逻辑中除开会去选择构造方法以及查找入参对象意外,还会判断是否在对应的类中是否存在使用@Lookup
注解了方法。如果存在则把该方法封装为LookupOverride
对象并添加到BeanDefinition
中。
在实例化时,如果判断出来当前BeanDefinition
中没有LookupOverride
,那就直接用构造方法反射得到一个实例对象。如果存在LookupOverride
对象,也就是类中存在@Lookup
注解了的方法,那就会生成一个代理对象。
@Lookup
注解就是方法注入,使用demo
如下:
@Component
public class UserService {
private OrderService orderService;
public void test() {
OrderService orderService = createOrderService();
System.out.println(orderService);
}
@Lookup("orderService")
public OrderService createOrderService() {
return null;
}
}
6. BeanDefinition
的后置处理
Bean
对象实例化出来之后,接下来就应该给对象的属性赋值了。在真正给属性赋值之前,Spring
又提供了一个扩展点MergedBeanDefinitionPostProcessor.postProcessMergedBeanDefinition()
,可以对此时的BeanDefinition
进行加工,比如:
@Component
public class ZhouyuMergedBeanDefinitionPostProcessor implements MergedBeanDefinitionPostProcessor {
@Override
public void postProcessMergedBeanDefinition(RootBeanDefinition beanDefinition, Class<?> beanType, String beanName) {
if ("userService".equals(beanName)) {
beanDefinition.getPropertyValues().add("orderService", new OrderService());
}
}
}
在Spring
源码中,AutowiredAnnotationBeanPostProcessor
就是一个MergedBeanDefinitionPostProcessor
,它的postProcessMergedBeanDefinition()
中会去查找注入点,并缓存在AutowiredAnnotationBeanPostProcessor
对象的一个Map
中(injectionMetadataCache
)。
7.实例化后
在处理完BeanDefinition
后,Spring
又设计了一个扩展点:InstantiationAwareBeanPostProcessor.postProcessAfterInstantiation()
,比如:
@Component
public class ZhouyuInstantiationAwareBeanPostProcessor implements InstantiationAwareBeanPostProcessor {
@Override
public boolean postProcessAfterInstantiation(Object bean, String beanName) throws BeansException {
if ("userService".equals(beanName)) {
UserService userService = (UserService) bean;
userService.test();
}
return true;
}
}
上述代码就是对userService
所实例化出来的对象进行处理。
这个扩展点,在Spring
源码中基本没有怎么使用。
8.自动注入
这里的自动注入指的是Spring
的自动注入(AUTOWIRE_BY_NAME
和 AUTOWIRE_BY_TYPE
),目前已经弃用
后续依赖注入课程中单独讲
9.处理属性
这个步骤中,就会处理@Autowired、@Resource、@Value
等注解,也是通过InstantiationAwareBeanPostProcessor.postProcessProperties()
扩展点来实现的,比如我们甚至可以实现一个自己的自动注入功能,比如:
@Component
public class ZhouyuInstantiationAwareBeanPostProcessor implements InstantiationAwareBeanPostProcessor {
@Override
public PropertyValues postProcessProperties(PropertyValues pvs, Object bean, String beanName) throws BeansException {
if ("userService".equals(beanName)) {
for (Field field : bean.getClass().getFields()) {
if (field.isAnnotationPresent(ZhouyuInject.class)) {
field.setAccessible(true);
try {
field.set(bean, "123");
} catch (IllegalAccessException e) {
e.printStackTrace();
}
}
}
}
return pvs;
}
}
关于@Autowired、@Resource、@Value
的底层源码,会在后续的依赖注入课程中详解。
10.执行Aware
完成了属性赋值之后,Spring
会执行一些回调,包括:
BeanNameAware
:回传beanName
给bean
对象。BeanClassLoaderAware
:回传classLoader
给bean
对象。BeanFactoryAware
:回传beanFactory
给对象。
11.初始化前
初始化前,也是Spring
提供的一个扩展点:BeanPostProcessor.postProcessBeforeInitialization()
,比如
@Component
public class ZhouyuBeanPostProcessor implements BeanPostProcessor {
@Override
public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
if ("userService".equals(beanName)) {
System.out.println("初始化前");
}
return bean;
}
}
利用初始化前,可以对进行了依赖注入的Bean
进行处理。
在Spring
源码中:
InitDestroyAnnotationBeanPostProcessor
会在初始化前这个步骤中执行@PostConstruct
的方法,ApplicationContextAwareProcessor
会在初始化前这个步骤中进行其他Aware
的回调:
a.EnvironmentAware
:回传环境变量
b.EmbeddedValueResolverAware
:回传占位符解析器
c.ResourceLoaderAware
:回传资源加载器
d.ApplicationEventPublisherAware
:回传事件发布器
e.MessageSourceAware
:回传国际化资源
f.ApplicationStartupAware
:回传应用其他监听对象,可忽略
g.ApplicationContextAware
:回传Spring
容器ApplicationContext
12.初始化
- 查看当前
Bean
对象是否实现了InitializingBean
接口,如果实现了就调用其afterPropertiesSet()
方法 - 执行
BeanDefinition
中指定的初始化方法
13.初始化后
这是Bean
创建生命周期中的最后一个步骤,也是Spring
提供的一个扩展点:BeanPostProcessor.postProcessAfterInitialization()
,比如:
@Component
public class ZhouyuBeanPostProcessor implements BeanPostProcessor {
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
if ("userService".equals(beanName)) {
System.out.println("初始化后");
}
return bean;
}
}
可以在这个步骤中,对Bean
最终进行处理,Spring
中的AOP
就是基于初始化后实现的,初始化后返回的对象才是最终的Bean
对象。
总结 BeanPostProcessor
InstantiationAwareBeanPostProcessor.postProcessBeforeInstantiation()
- 实例化
MergedBeanDefinitionPostProcessor.postProcessMergedBeanDefinition()
InstantiationAwareBeanPostProcessor.postProcessAfterInstantiation()
- 自动注入
InstantiationAwareBeanPostProcessor.postProcessProperties()
Aware
BeanPostProcessor.postProcessBeforeInitialization()
- 初始化
BeanPostProcessor.postProcessAfterInitialization()
Bean
的销毁过程
两种方式:
一、在Spring
容器关闭时
AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);
UserService userService = (UserService) context.getBean("userService");
userService.test();
context.close();
二、在进程关闭时
注册进程关闭钩子
AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);
context.registerShutdownHook();
UserService userService = (UserService) context.getBean("userService");
userService.test();
销毁 Bean
在Bean
创建过程中,在最后(初始化之后),有一个步骤会去判断当前创建的Bean
是不是DisposableBean
:
- 当前
Bean
是否实现了DisposableBean
接口 - 或者,当前
Bean
是否实现了AutoCloseable
接口 BeanDefinition
中是否指定了destroyMethod
,包括自定义销毁方法为(inferred)
,会调用close
和shutdown
方法- 调用
DestructionAwareBeanPostProcessor.requiresDestruction(bean)
进行判断
a.ApplicationListenerDetector
中直接使得ApplicationListener
是DisposableBean
b.InitDestroyAnnotationBeanPostProcessor
中使得拥有@PreDestroy
注解了的方法就是DisposableBean
- 把符合上述任意一个条件的
Bean
适配成DisposableBeanAdapter
对象,并存入disposableBeans
中(一个LinkedHashMap
)
在Spring
容器关闭过程时:
- 首先发布
ContextClosedEvent
事件 - 调用
lifecycleProcessor
的onCloese()
方法 - 销毁单例
Bean
a. 遍历disposableBeans
ⅰ. 把每个disposableBean
从单例池中移除
ⅱ. 调用disposableBean
的destroy()
ⅲ. 如果这个disposableBean
还被其他Bean
依赖了,那么也得销毁其他Bean
ⅳ. 如果这个disposableBean
还包含了inner beans
,将这些Bean
从单例池中移除掉 (inner bean
参考https://docs.spring.io/spring-framework/docs/current/spring-framework-reference/core.html#beans-inner-beans)
b. 清空manualSingletonNames
,是一个Set
,存的是用户手动注册的单例Bean
的beanName
c. 清空allBeanNamesByType
,是一个Map
,key
是bean
类型,value
是该类型所有的beanName
数组
d. 清空singletonBeanNamesByType
,和allBeanNamesByType
类似,只不过只存了单例Bean
这里涉及到一个设计模式:适配器模式
在销毁时,Spring
会找出实现了DisposableBean
接口的Bean
。
但是我们在定义一个Bean
时,如果这个Bean
实现了DisposableBean
接口,或者实现了AutoCloseable
接口,或者在BeanDefinition
中指定了destroyMethodName
,那么这个Bean
都属于“DisposableBean
”,这些Bean
在容器关闭时都要调用相应的销毁方法。
所以,这里就需要进行适配,将实现了DisposableBean
接口、或者AutoCloseable
接口等适配成实现了DisposableBean
接口,所以就用到了DisposableBeanAdapter
。
会把实现了AutoCloseable
接口的类封装成DisposableBeanAdapter
,而DisposableBeanAdapter
实现了DisposableBean
接口。