AutowireCapableBeanFactory探密(1)—
起因
群里有朋友抛出了个问题,问为什么Spring Cache注解未生效,示例代码如下:
@RunWith(SpringRunner.class)
@SpringBootTest
@Slf4j
public class DemoApplicationTests {
@Test
public void contextLoads() {
testGetFromDB(1);
testGetFromDB(1);
testGetFromDB(1);
}
@Cacheable("foo")
public String testGetFromDB(Integer i) {
log.info("testGetFromDB...");
return "retVal" + i;
}
}
我说,你把@Cacheable
注解的方法搬到别的类,然后再试试,结果,好了
大家如果有过类似经验,大概能一眼看出问题所在:Spring AOP方法内部调用,切面逻辑是不生效的(动态代理)。解决方案有两个,一是AopContext#currentProxy
,二是在当前类中注入自己,再用该对象进行方法内部调用
但实际上,这里隐藏了一个问题,即便通过上述的两种方式,在本案例中,@Cacheable
仍然不会生效。第一种方式会因获取到的proxy对象为空而抛出IllegalStateException
异常,第二种方式会因获取不到DemoApplicationTests
Bean而抛出NoSuchBeanDefinitionException
异常
public static Object currentProxy() throws IllegalStateException {
Object proxy = currentProxy.get();
if (proxy == null) {
throw new IllegalStateException(
"Cannot find current proxy: Set 'exposeProxy' property on Advised to 'true' to make it available.");
}
return proxy;
}
NoSuchBeanDefinitionException: No qualifying bean of type 'com.example.demo.DemoApplicationTests' available
这就很诡异了,为啥会获取不到?难道IOC容器里没有DemoApplicationTests
对象?可是,如果没有这个对象,那平时写单测的时候,那些@Resouce
、@Autowired
、@Value
注解(Spring称为:annotation-driven injection)又是如何生效的,Bean是如何注入的呢
实际上,IOC容器里还真没有DemoApplicationTests
对象,也就是说,Spring在IOC容器里压根找不到该Bean,也就不难理解方式一、二都抛了异常。
在一般的认知中,如果某个Bean想使用Spring的功能,需要让Bean注册到Spring IOC容器中,被Spring管理。那么问题就来了,既然Spring 并没有管理DemoApplicationTests
Bean,那annotation-driven injection是如何生效的呢?
解决方案
AutowireCapableBeanFactory
- BeanFactory的直接子接口,拥有自动装配的能力
- 一般不会在普通应用中直接使用
AutowireCapableBeanFactory
,因此在设计上ApplicationContext
们并没有直接实现该接口(画外音:Spring的设计者们不希望用户在应用代码中直接使用AutowireCapableBeanFactory
)。尽管如此,却提供了该问该接口的能力:通过ApplicationContext#getAutowireCapableBeanFactory
方法可拿到其实例对象 - 它真正的作用在于整合其它框架:能让Spring管理的Bean去装配和填充那些不被Spring托管的Bean(wire and populate existing bean instances that Spring does not control the lifecycle of)[重要]
原理
源码基于Spring 5.1.11.RELEASE
当在Junit测试类使用spring-test\spring-boot-test注解(如:@SpringBootTest
),并启动测试方法时,Junit框架会准备相关的测试资源,并且加载Spring环境,之后对测试类实例使用Spring进行装配,以保证依赖的服务处于可用状态。测试方法启动过程会经历如下方法:
// org.springframework.test.context.support.DependencyInjectionTestExecutionListener
protected void injectDependencies(TestContext testContext) throws Exception {
Object bean = testContext.getTestInstance(); // 测试类实例
Class<?> clazz = testContext.getTestClass(); // 测试类class(DemoApplicationTests)
AutowireCapableBeanFactory beanFactory = testContext.getApplicationContext().getAutowireCapableBeanFactory();
// 1. 使用AutowireCapableBeanFactory去装配不受Spring管理的bean
beanFactory.autowireBeanProperties(bean, AutowireCapableBeanFactory.AUTOWIRE_NO, false);
// 2. 进行初始化
beanFactory.initializeBean(bean, clazz.getName() + AutowireCapableBeanFactory.ORIGINAL_INSTANCE_SUFFIX);
testContext.removeAttribute(REINJECT_DEPENDENCIES_ATTRIBUTE);
}
从上述源码中可以看到,Bean(DemoApplicationTests)是从testContext中获取,而并没有被Spring管理,然后借助AutowireCapableBeanFactory
的能力对Bean进行装配与初始化,让Spring为非Spring托管的Bean赋能
其中,对于@Resouce、@Autowired
注入的能力,是通过beanFactory.autowireBeanProperties(bean, AutowireCapableBeanFactory.AUTOWIRE_NO, false);
来实现的,代码如下:
public void autowireBeanProperties(Object existingBean, int autowireMode, boolean dependencyCheck) throws BeansException {
if (autowireMode == AUTOWIRE_CONSTRUCTOR) {
throw new IllegalArgumentException("AUTOWIRE_CONSTRUCTOR not supported for existing bean instance");
}
// Use non-singleton bean definition, to avoid registering bean as dependent bean.
RootBeanDefinition bd =
new RootBeanDefinition(ClassUtils.getUserClass(existingBean), autowireMode, dependencyCheck);
bd.setScope(BeanDefinition.SCOPE_PROTOTYPE);
BeanWrapper bw = new BeanWrapperImpl(existingBean);
initBeanWrapper(bw);
// 填充属性
populateBean(bd.getBeanClass().getName(), bd, bw);
}
接着看populateBean
方法,该方法作用是为给定的bean填充属性,相信大家已经很熟悉这段代码了,篇幅原因,把非关键代码省略
protected void populateBean(String beanName, RootBeanDefinition mbd, @Nullable BeanWrapper bw) {
// ...(省略)
for (BeanPostProcessor bp : getBeanPostProcessors()) {
if (bp instanceof InstantiationAwareBeanPostProcessor) {
InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
// @Resouce、@Autowired 注解起作用的地方
PropertyValues pvsToUse = ibp.postProcessProperties(pvs, bw.getWrappedInstance(), beanName);
if (pvsToUse == null) {
if (filteredPds == null) {
filteredPds = filterPropertyDescriptorsForDependencyCheck(bw, mbd.allowCaching);
}
pvsToUse = ibp.postProcessPropertyValues(pvs, filteredPds, bw.getWrappedInstance(), beanName);
if (pvsToUse == null) {
return;
}
}
pvs = pvsToUse;
}
}
// ...(省略)
}
@Resouce
、@Autowired
注解之所以能生效,是因为最终执行了PropertyValues pvsToUse = ibp.postProcessProperties(pvs, bw.getWrappedInstance(), beanName);
这一行代码。有两个InstantiationAwareBeanPostProcessor
分别是CommonAnnotationBeanPostProcessor
、AutowiredAnnotationBeanPostProcessor
,分别用于处理@Resouce
、@Autowired
,达到属性填充的目的
接下来看看AutowireCapableBeanFactory
接口,一共有6个属性,15个方法
public interface AutowireCapableBeanFactory extends BeanFactory {
// ---------------------- 属性 ----------------------
// 装配模式
int AUTOWIRE_NO = 0;
int AUTOWIRE_BY_NAME = 1;
int AUTOWIRE_BY_TYPE = 2;
int AUTOWIRE_CONSTRUCTOR = 3;
// @deprecated as of Spring 3.0
int AUTOWIRE_AUTODETECT = 4;
String ORIGINAL_INSTANCE_SUFFIX = ".ORIGINAL";
// ---------------------- 方法 ----------------------
<T> T createBean(Class<T> beanClass) throws BeansException;
void autowireBean(Object existingBean) throws BeansException;
Object configureBean(Object existingBean, String beanName) throws BeansException;
Object createBean(Class<?> beanClass, int autowireMode, boolean dependencyCheck) throws BeansException;
Object autowire(Class<?> beanClass, int autowireMode, boolean dependencyCheck) throws BeansException;
void autowireBeanProperties(Object existingBean, int autowireMode, boolean dependencyCheck)
throws BeansException;
void applyBeanPropertyValues(Object existingBean, String beanName) throws BeansException;
Object initializeBean(Object existingBean, String beanName) throws BeansException;
Object applyBeanPostProcessorsBeforeInitialization(Object existingBean, String beanName)
throws BeansException;
Object applyBeanPostProcessorsAfterInitialization(Object existingBean, String beanName)
throws BeansException;
void destroyBean(Object existingBean);
<T> NamedBeanHolder<T> resolveNamedBean(Class<T> requiredType) throws BeansException;
Object resolveBeanByName(String name, DependencyDescriptor descriptor) throws BeansException;
Object resolveDependency(DependencyDescriptor descriptor, @Nullable String requestingBeanName) throws BeansException;
Object resolveDependency(DependencyDescriptor descriptor, @Nullable String requestingBeanName,
@Nullable Set<String> autowiredBeanNames, @Nullable TypeConverter typeConverter) throws BeansException;
}
5个AUTOWIRE_*指的是装配模式,接口方法中的autowireMode参数取值就从这5个里边选择
- int AUTOWIRE_NO = 0;不装配
- int AUTOWIRE_BY_NAME = 1;根据名称装配
- int AUTOWIRE_BY_TYPE = 2;根据类型装配
- int AUTOWIRE_CONSTRUCTOR = 3;根据构造器装配
- int AUTOWIRE_AUTODETECT = 4;从Spring 3.0就过期了,不作介绍
还有1个属性String ORIGINAL_INSTANCE_SUFFIX = ".ORIGINAL";
,该属性是一种约定俗成的用法:以类全限定名+.ORIGINAL 作为Bean Name,用于告诉Spring,在初始化的时候,需要返回原始给定实例,而别返回代理对象
上面的方法看似挺多,经过分类之后,也能比较好理解与记忆。其实从方法的命名上也能看出来各自的作用,这也是Spring框架优秀让人着迷的地方之一:方法命名在很多时候能让人见名知义,足够抽象而又不失准确的概括。按照接口提供能力的粒度,大体上分为三类:
- 粗粒度创建、装配Bean的方法
<T> T createBean(Class<T> beanClass) throws BeansException;
void autowireBean(Object existingBean) throws BeansException;
Object configureBean(Object existingBean, String beanName) throws BeansException;
- 细粒度控制Bean生命周期的方法(创建、装配Bean的过程涉及Bean的生命周期)。细粒度体现在两个方面,一是提供了可选的装配模式(autowireMode),二是把装配Bean的过程细化为 属性填充(populateBean) 与 初始化(initializeBean) 两个阶段。此外,还提供了BeanPostProcessors的前后置处理逻辑回调,以及销毁Bean的逻辑回调。
Object createBean(Class<?> beanClass, int autowireMode, boolean dependencyCheck) throws BeansException;
Object autowire(Class<?> beanClass, int autowireMode, boolean dependencyCheck) throws BeansException;
void autowireBeanProperties(Object existingBean, int autowireMode, boolean dependencyCheck) throws BeansException;
void applyBeanPropertyValues(Object existingBean, String beanName) throws BeansException;
Object initializeBean(Object existingBean, String beanName) throws BeansException;
Object applyBeanPostProcessorsBeforeInitialization(Object existingBean, String beanName) throws BeansException;
Object applyBeanPostProcessorsAfterInitialization(Object existingBean, String beanName) throws BeansException;
void destroyBean(Object existingBean);
- 解析注入点的代理方法,这些方法是辅助类方法,一般不需要直接使用
<T> NamedBeanHolder<T> resolveNamedBean(Class<T> requiredType) throws BeansException;
Object resolveBeanByName(String name, DependencyDescriptor descriptor) throws BeansException;
Object resolveDependency(DependencyDescriptor descriptor, @Nullable String requestingBeanName) throws BeansException;
Object resolveDependency(DependencyDescriptor descriptor, @Nullable String requestingBeanName, @Nullable Set<String> autowiredBeanNames, @Nullable TypeConverter typeConverter) throws BeansException;
上面是官方的分法,下面将按照接口的功能进行划分
- 创建Bean
- createBean(Class<T> beanClass): 用给定的class创建一个Bean实例,完整经历一个Bean创建过程的生命周期节点回调,但不执行传统的autowiring
- 提供autowire(Class<?> beanClass, int autowireMode, boolean dependencyCheck)所有能力
- 提供initializeBean(Object existingBean, String beanName)所有能力
- createBean(Class<?> beanClass, int autowireMode, boolean dependencyCheck): 与上边类似,主要区别是可以指定
autowireMode
,即可能会执行传统的autowiring
- createBean(Class<T> beanClass): 用给定的class创建一个Bean实例,完整经历一个Bean创建过程的生命周期节点回调,但不执行传统的autowiring
- 属性装配
- autowireBean(Object existingBean): 主要用于(再次)填充指定Bean被注解的元素或方法(如@Resource @Autowired),不执行传统的autowiring
- 执行InstantiationAwareBeanPostProcessor的后置处理逻辑,因为这是在
populateBean()
中执行的 - 不执行传统的autowiring
- 不执行initializeBean方法,因此也就不执行标准的BeanPostProcessor
- 执行InstantiationAwareBeanPostProcessor的后置处理逻辑,因为这是在
- autowireBeanProperties(Object existingBean, int autowireMode, boolean dependencyCheck): 与上边类似,主要区别是可以指定
autowireMode
,即可能会执行传统的autowiring - autowire(Class<?> beanClass, int autowireMode, boolean dependencyCheck): 与上边类似,主要区别是该方法首个入参是Class,框架会帮我们实例化,而上边是已实例化的对象
- autowireBean(Object existingBean): 主要用于(再次)填充指定Bean被注解的元素或方法(如@Resource @Autowired),不执行传统的autowiring
- 初始化
- initializeBean(Object existingBean, String beanName): 初始化给定的Bean
- 执行invokeAwareMethods方法(xxxAware,如BeanNameAware)
- 执行BeanPostProcessor前置处理逻辑
- 执行invokeInitMethods进行初始化,如InitializingBeanorg#afterPropertiesSet等
- 执行BeanPostProcessor后置处理逻辑
- initializeBean(Object existingBean, String beanName): 初始化给定的Bean
- 配置Bean
- configureBean(Object existingBean, String beanName): 作为
initializeBean
的超集存在,功能跟createBean(Class<T> beanClass)
类似,但要求beanName
对应的BeanDefinition
存在,否则会抛出NoSuchBeanDefinitionException
异常,使用场景很少
- configureBean(Object existingBean, String beanName): 作为
- 销毁Bean
- destroyBean(Object existingBean): 销毁Bean前,执行
DestructionAwareBeanPostProcessor
与DisposableBean
等的销毁逻辑,用于资源回收
- destroyBean(Object existingBean): 销毁Bean前,执行
- 对Bean初始化前后应用逻辑处理器
- applyBeanPostProcessorsBeforeInitialization: 执行BeanPostProcessor前置处理逻辑
- applyBeanPostProcessorsAfterInitialization: 执行BeanPostProcessor后置处理逻辑
- applyBeanPropertyValues: 真正执行Bean属性值的填充
- 解析方法,辅助类方法
- resolveNamedBean(Class<T> requiredType): 根据传入的类型,从Spring容器(包括父子容器)中查找出指定类型下唯一的Bean,并将
beanName
与beanInstance
包装成NamedBeanHolder对象返回。如果该类型下有不止一个对象(非唯一),返回null。该方法其实是BeanFactory#getBean(java.lang.Class<T>)
方法的变种,二者底层实现是一样的 - resolveBeanByName(String name, DependencyDescriptor descriptor): 根据name跟descriptor解析出一个Bean实例,该方法是
BeanFactory#getBean(java.lang.String, java.lang.Class<T>)
方法的变种 - resolveDependency(DependencyDescriptor descriptor, @Nullable String requestingBeanName): 直接调用下边的方法
- resolveDependency(DependencyDescriptor descriptor, @Nullable String requestingBeanName,
@Nullable Set<String> autowiredBeanNames, @Nullable TypeConverter typeConverter): 解析Bean依赖,非常重要的方法
- resolveNamedBean(Class<T> requiredType): 根据传入的类型,从Spring容器(包括父子容器)中查找出指定类型下唯一的Bean,并将
AbstractAutowireCapableBeanFactory
是AutowireCapableBeanFactory
的一个抽象实现类,该类的源码如果不往更底层看,其实还是比较简单(简洁)的,大家以前学习Spring Bean生命周期的时候应该见到过,因此也就不贴源码了,感兴趣的同学可以自行翻看一下
除了Junit,还有Quartz定时任务框架,与Spring集成的时候,也会用上AbstractAutowireCapableBeanFactory
。原因是定时任务Job一般需要借助Spring 管理的Service来进行业务逻辑的处理,但Job本身并没有交给Spring管理,而是通过反射生成实例,因此想要借用@Resouce
等注解,就得让AbstractAutowireCapableBeanFactory
为Job Bean 做自动装配。具体分析可参看此处
总结
Spring 提供了一种机制,能够为第三方框架赋能,让Spring管理的Bean去装配和填充那些不被Spring托管的Bean,这种机制叫AutowireCapableBeanFactory
。目前了解到的有两款著名的开源框架Junit
与Quartz
借用了这种机制为自己赋能,达到更好地与Spring契合协作的目的,也从他们的整合姿势中学习到,当我们需要设计一个框架,而且需要拥抱Spring生态,为框架使用者提供更便利的无缝整合,需以微内核 + 插件机制思想,由内核层想办法拿到AutowireCapableBeanFactory
,并在构造插件的时候,借助AutowireCapableBeanFactory
去为插件赋能,做到无限扩展的可能性