Bean的原始版本与最终版本不一致?记一次Spring IOC探索之旅

前言

在这个信息技术发展迅速的时代,万万没想到,Spring自2003年发展至今,仍是技术选型中的首选,某些项目甚至有Spring全家桶的情况。

在Java开发者面试当中,Spring的原理也常被面试官用于考察候选人的技术深度,同时也能反映候选人对技术是否有热情,是否具有探索精神。

本文带着一个开发中遇到的实际问题,对问题寻根问底,对Spring IOC进行一次探索之旅,其中会介绍到:

  1. 了解上述异常是什么,及其发生原理
  2. 了解Spring IOC中“获取Bean”、“创建Bean”的过程
  3. 了解@Async如何与Spring IOC协作实现异步方法的特性
  4. 了解Spring AOP如何与Spring IOC协作实现“面向切面编程”的特性

阅读本文,你能够了解Spring IOC的基本原理。
收藏本文,四舍五入你也是了解Spring原理的人啦。

问题背景

最近,在使用Spring过程中遇到一个问题:

开发同学开发完需求,并在开发环境完整地自测完毕,满怀自信地将其发布到测试环境,却发现测试环境连启动都起不起来,需求刚提测就被测试同学驳回。同样的代码回到开发人员的环境却又是正常的。

测试环境报的异常是这样的:

2020-08-01 09:54:48.490 ERROR 628 --- [ restartedMain] o.s.boot.SpringApplication : Application run failed
org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'appleService': Bean with name 'appleService' has been injected into other beans [boyService] in its raw version as part of a circular reference, but has eventually been wrapped. This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.

简单翻译,大概讲在循环引用情况下,一个Bean注入到其它Bean后被包装了,导致注入到其它Bean的对象与该Bean最后被包装的对象不一致。

看着异常信息,心有疑问:

  1. 这个异常具体表示什么? 什么情况下会发生?
  2. 为什么会出现此异常?
  3. 这个异常为什么在开发者的机器上没出现,在测试环境却出现了?

什么是BeanCurrentlyInCreationException

BeanCurrentlyInCreationException,查看注释,可知这个异常是引用“正在创建中的Bean”时发生的异常,通常发生在“构造方法自动装配”匹配到“当前正在构造的Bean”的时候。

这个异常有两个构造方法,其中一个构造方法可以自定义beanName和异常消息。我们遇到的这个异常信息,很明显是自定义的异常消息了,那这个异常消息具体表示什么呢?

根据上述异常,简单翻译一下:

创建名称为“appleService”的bean发生错误:因为循环引用,“appleService” bean的原始版本已注入到其它bean中(“boyService” bean),但“appleService” bean最终被包装了。
这意味着其它bean不是使用“appleService” bean的最终版本。
这通常是“急于进行类型匹配”的结果,比如可以考虑关闭“allowEagerInit”使用“getBeanNamesOfType”。

从异常信息中,可以发现几个关键信息:

  1. 循环引用
  2. bean的原始版本
  3. 包装
  4. bean的最终版本

通过上面几个信息,可以判断出很可能跟循环引用代理相关。

  1. 循环引用,很明显是Bean之前的循环引用
  2. 代理,是“代理模式”,代理模式在Spring中很常用,比如AOP、@Transactional、@Asnyc都用到了

于是,我们开始检查代码,看报错信息中涉及的代码是否有蛛丝马迹。

结果发现相关Bean确实存在循环引用,并且部分Bean的方法有使用异步注解@Asnyc。

“循环引用”和“@Asnyc”都是Spring比较常用的功能,究竟是不是它们引发这个异常呢?

如何复现?

根据发生异常的Bean的写法,撇除其它干扰因素,用独立的简单应用复现。

先准备最简单的Spring Boot脚手架,这里使用的版本是2.2.2.RELEASE:

	<parent>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-parent</artifactId>
		<version>2.2.2.RELEASE</version>
		<relativePath/>
	</parent>

添加两个bean,分别是AppleService和BoyService,它们包含两个特征:

1、循环引用。AppleService包含BoyService类型的属性,BoyService也包含AppleService类型的属性,它们互相引用

2、异步方法。AppleService中包含一个异步方法,用@Async注解实现

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.scheduling.annotation.Async;
import org.springframework.stereotype.Service;

@Service
public class AppleService {

    @Autowired
    private BoyService boyService;

    @Async
    public String color() {
        return "red";
    }

}
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class BoyService {

    @Autowired
    private AppleService appleService;

    public String color() {
        return "white";
    }

}

然后在Spring Boot的启动类中添加支持异步注解的注解:@EnableAsync

执行Spring Boot的启动类,就会看到以下报错日志(这是在Windows操作系统下运行的结果,在其他操作系统下运行有可能是正常的):

2020-10-23 00:55:33.878 ERROR 2348 --- [  restartedMain] o.s.boot.SpringApplication               : Application run failed

org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'appleService': Bean with name 'appleService' has been injected into other beans [boyService] in its raw version as part of a circular reference, but has eventually been wrapped. This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:624) ~[spring-beans-5.2.2.RELEASE.jar:5.2.2.RELEASE]
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:517) ~[spring-beans-5.2.2.RELEASE.jar:5.2.2.RELEASE]
	at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:323) ~[spring-beans-5.2.2.RELEASE.jar:5.2.2.RELEASE]
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) ~[spring-beans-5.2.2.RELEASE.jar:5.2.2.RELEASE]
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:321) ~[spring-beans-5.2.2.RELEASE.jar:5.2.2.RELEASE]
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202) ~[spring-beans-5.2.2.RELEASE.jar:5.2.2.RELEASE]
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:879) ~[spring-beans-5.2.2.RELEASE.jar:5.2.2.RELEASE]
	at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:878) ~[spring-context-5.2.2.RELEASE.jar:5.2.2.RELEASE]
	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:550) ~[spring-context-5.2.2.RELEASE.jar:5.2.2.RELEASE]
	at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:141) ~[spring-boot-2.2.2.RELEASE.jar:2.2.2.RELEASE]
	at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:747) [spring-boot-2.2.2.RELEASE.jar:2.2.2.RELEASE]
	at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:397) [spring-boot-2.2.2.RELEASE.jar:2.2.2.RELEASE]
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:315) [spring-boot-2.2.2.RELEASE.jar:2.2.2.RELEASE]
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:1226) [spring-boot-2.2.2.RELEASE.jar:2.2.2.RELEASE]
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:1215) [spring-boot-2.2.2.RELEASE.jar:2.2.2.RELEASE]
	at com.nickxhuang.springbootexercise.SpringbootexerciseApplication.main(SpringbootexerciseApplication.java:14) [classes/:na]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_191]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_191]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_191]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_191]
	at org.springframework.boot.devtools.restart.RestartLauncher.run(RestartLauncher.java:49) [spring-boot-devtools-2.2.2.RELEASE.jar:2.2.2.RELEASE]

跟着上述堆栈,我们开始探索为什么会引发此异常。

代码版本说明

如无特别说明,下文使用的版本是Spring Boot 2.2.2.RELEASEJDK 1.8

	<parent>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-parent</artifactId>
		<version>2.2.2.RELEASE</version>
		<relativePath/>
	</parent>

Bean的循环引用是什么?

在上述复现异常的章节中,我们展示了循环引用的类的代码,用类图表示是这样的:

当然,两个Bean组成的循环引用是最简单的情况,更多的情况下,是3个或3个以上的Bean组成的循环引用:

随着业务发展,应用会越来越复杂,Bean也会越来越多,循环引用在很多应用中不可避免会存在。广泛使用的Spring支持循环引用吗?

Spring如何创建循环引用的Bean?

原型模式下不允许循环依赖的Bean,为什么?

Spring Bean的模式,常用的有单例模式和原型模式(Prototype模式)。当定义Bean为原型模式时,Bean就是多实例的,每次调用方法获取Bean时,都会新建一个Bean实例。

为什么原型模式下不允许循环依赖?

因为原型模式下,每获取一次Bean,都会新建一个该Bean的新实例,如果遇到循环依赖的情况,就会出现死循环,比如:

appleService > boyService > appleService > boyService > appleService 如此不断循环

所以,Spring在创建Bean的过程中使用校验禁止了这种情况的发生,代码坐标:org.springframework.beans.factory.support.AbstractBeanFactory#doGetBean的264-268行。

其原理是使用一个变量缓存“多实例模式下正在创建的Bean的名字”,以此缓存来判断是否存在已在创建中的Bean再进行创建动作,如有则抛出异常。

单例模式支持解决循环引用?有什么前提条件吗?

“单例模式”下基于“Setter方式注入属性”支持循环引用

在项目开发中,Bean随着业务的复杂越来越多,循环引用,在使用中似乎难以避免。

而循环引用,真的无法解决吗?细想好像不是的。

创建一个Bean,大致能分为两步:实例化和填充值。如果我们把实例化完但还没填充值得Bean缓存起来,在填充值的时候想办法从缓存中获取依赖Bean的引用,这样似乎可行。

比如AppleService、BoyService循环引用,那么创建过程可以是这样的:

在绿色方框获取AppleService的对象时,将我们在蓝色方框步骤缓存起来的AppleService拿出来,这时的AppleService应该是已实例化但还未完成创建完成的。

没错,Spring就是用这个原理支持“单例模式”下基于“Setter方式注入属性”的循环引用的Bean。

实例化Bean,并将未完全创建完毕的Bean缓存起来,这就是上文异常信息中说的“EagerInit”(急切的初始化),也是下文所说的“提前暴露对象”。

本节描述的创建Bean的过程是经过抽象的,因为要兼容AOP等其他特性的扩展,Spring创建Bean的实现比上面描述的要复杂很多。

Spring获取Bean的过程是怎样的?

如何快速地找到Spring获取bean的入口?

从调用堆栈中寻找是最快的,在上述“如何复现?”章节中有一个堆栈信息,观察方法名很容易能发现端倪,我们节选了堆栈中的一段:

org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:624) ~[spring-beans-5.2.2.RELEASE.jar:5.2.2.RELEASE]
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:517) ~[spring-beans-5.2.2.RELEASE.jar:5.2.2.RELEASE]
	at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:323) ~[spring-beans-5.2.2.RELEASE.jar:5.2.2.RELEASE]
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) ~[spring-beans-5.2.2.RELEASE.jar:5.2.2.RELEASE]
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:321) ~[spring-beans-5.2.2.RELEASE.jar:5.2.2.RELEASE]
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)

堆栈中的方法名要么是getBean,要么是createBean,我们从最上层的org.springframework.beans.factory.support.AbstractBeanFactory.getBean开始查看。

Spring如何获取Bean?

getBean的方法的具体坐标是org.springframework.beans.factory.support.AbstractBeanFactory#getBean(java.lang.String)方法。

查看其中,可发现实际调用的是org.springframework.beans.factory.support.AbstractBeanFactory#doGetBean方法。

doGetBean方法是获取Bean的实际实现方法,这个方法有挺多细节,从顶层抽象视角来看,它通过两种方式获取Bean:

  1. 从缓存中获取Bean
  2. 从缓存没获取到Bean,需创建Bean

除了上述两个大的抽象步骤,还有许多细节,比如在“从缓存中获取Bean”之后、“调用创建Bean的方法”之前,有几个检测、委托获取的步骤。

下图是逻辑流程图,图中标注了该逻辑的具体实现代码行数,可以对照着看(代码的版本查看“代码版本说明”章节):

1、从缓存中获取Bean。Spring的Bean常用有的单例模式(默认)和原型模式(多实例模式)。

单例模式下,如果一个Bean之前就创建过,那当然已经缓存起来了,第2+次获取直接从缓存中获取就好了。

上述从缓存中获取已经创建好的Bean是最简单的情况,为支持循环引用,Spring用3个级别的缓存来获取尚未完全创建完的Bean,下面会详细讨论。

2、检测“原型模式”下的Bean是否在创建中。为什么呢?

从上面的介绍中,我们知道因为死循环的原因,“原型模式”下是不允许循环引用的,所以这里对“原型模式下的Bean是否在创建中”进行校验,如果当前需要创建的Bean已经在创建中了,说明存在循环引用,会抛出异常。

这里用一个ThreadLocal类型的变量做缓存,存放正在创建中的Bean名称,通过此缓存来判断对应的Bean是否正在创建中的。

具体判断细节可见代码org.springframework.beans.factory.support.AbstractBeanFactory#isPrototypeCurrentlyInCreation,这里不做赘述。

维护此缓存的代码为org.springframework.beans.factory.support.AbstractBeanFactory#beforePrototypeCreation,ThreadLocal类型的缓存在只存一个Bean的时候存放的是一个字符创,如果存在多个Bean时,存放的则是Set类型(包含多个字符串)。

3、如果存在“父BeanFactory”,且beanName未定义在本BeanFactory中,调用“父BeanFactory”获取Bean

4、如果存在“depends on属性”依赖的Bean,先加载依赖的Bean。

5、创建Bean。创建的Bean可以分为3种模式,分别是单例模式、原型模式、其它Scope模式。

由于我们是排查BeanCurrentlyInCreationException问题,所以我们下面从单例模式这一条线介绍如何创建Bean。(单例模式也是默认的模式,是大家最常用的模式)

从缓存中获取Bean?为什么需要三级缓存?

获取Bean方法的第一步,是从缓存中获取Bean。

从缓存中获取Bean,代码坐标是org.springframework.beans.factory.support.DefaultSingletonBeanRegistry#getSingleton(java.lang.String),具体业务逻辑如下图:

可见分了3个层级的缓存:

  1. 第一级缓存是“已创建的单例缓存”(singletonObjects),这里很好理解。

  2. 第二级缓存是“提前暴露对象的缓存”(earlySingletonObjects),为了解决循环依赖,需要提前暴露没创建完毕的对象,所以有了此缓存的存在,也很好理解。

  3. 第三级缓存是“单例工厂缓存”(singletonFactories)。提前暴露对象,看起来通过第二级缓存就能解决了,为什么还需要第三级缓存呢?

我们先看singletonFactories是哪里维护的:

可以发现有一个可疑的维护点:org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#doCreateBean,这个方法的579-589行是创建Bean时提前暴露对象的实现点,如果计算所得的earlySingletonExposure为true表示需要提前暴露对象,则将“提前暴露对象工厂”放入“单例工厂缓存”中。

跟踪进去查看“提前暴露对象工厂”封装的“获取提前暴露对象引用的方法”(org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#getEarlyBeanReference),可以发现里面调用一系列SmartInstantiationAwareBeanPostProcessor扩展处理器,这些扩展处理的返回结果赋予exposedObject从而替换原来的Bean。

可见,为了支持这些扩展处理器,使用第三级缓存来存放单例工厂,到真正需要获取“提前暴露对象”时,才调用工厂方法获取“提前暴露对象”,触发调用扩展处理器。

另外,这里是Spring IOC与Spring AOP协作的一个点,Spring IOC在这里会调用一个Spring AOP实现的SmartInstantiationAwareBeanPostProcessor扩展处理器,处理器会返回创建好的Bean的代理对象,替换原来Bean对象。

Spring如何创建Bean?

查看org.springframework.beans.factory.support.AbstractBeanFactory#doGetBean的319-373行,就是创建Bean的逻辑了,代码篇幅太长,就不贴了。

可以发现,无论单例模式还是原型模式、其它模式,都是使用这个方法创建Bean的:org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#createBean(java.lang.String, org.springframework.beans.factory.support.RootBeanDefinition, java.lang.Object[])

回调方式 + 模板方式模式,复用“创建Bean的逻辑”

单例模式创建Bean这里用得很巧妙,用了“简单工厂模式”对此方法进行封装,然后传入org.springframework.beans.factory.support.DefaultSingletonBeanRegistry#getSingleton(java.lang.String, org.springframework.beans.factory.ObjectFactory<?>)进行调用。

查看getSingleton的逻辑,会发现逻辑主要是维护各个缓存。这种实现方式是不是似曾相识,像不像模板方法模式?我们经常通过继承抽象类的方式实现模板方法模式,而这里使用回调方式来实现模板方式模式,从而复用“创建Bean的逻辑”,“缓存维护逻辑”则封装在模板方法中,干得漂亮。

创建Bean的过程是怎么样的?

接下来看创建Bean的过程是怎么样的?

从大的步骤来讲,创建Bean会经历下面4个大的步骤:

  1. 实例化
  2. 解决循环依赖
  3. 填充属性值
  4. 调用初始化方法

但上述4个大步骤中其实还有许多细节,进一步补充细节后,步骤如下:

  1. ★ 调用“实例化前扩展处理器”
  2. 实例化Bean
  3. ★ 为解决循环引用,这里判断是否需要提前暴露对象,如需,将“提前暴露引用工厂”放入“单例工厂缓存”
  4. ★ 处理实例化后扩展处理器
  5. 填充属性值
  6. ★ 处理初始化的前置处理
  7. 调用初始化方法
  8. ★ 初始化的后置处理
  9. ★ 检测Bean的原始版本与最终版本是否一致

其中带★号的点,与本文讨论话题关联较大,所以下文会分点介绍。
下图是逻辑流程图,图中标注了该逻辑的具体实现代码行数,可以对照着看(代码的版本查看“代码版本说明”章节):

调用「实例化前扩展处理器」

代码坐标:org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#createBean(java.lang.String, org.springframework.beans.factory.support.RootBeanDefinition, java.lang.Object[])的504-514行,是处理“实例化前扩展处理器”的代码。

如果返回的bean对象不为null,则直接返回,不走后面的创建Bean的工作了,这是一个截断的动作。也就是说如果有“实例化扩展处理器”的方法返回的Bean不为null,则使用这个返回的Bean,后面的创建Bean的动作被省略了。

这里有个知识点,Spring IOC与Spring AOP协作的其中一个地方就是这里:

我们用最简单的Spring Boot脚手架加上AOP特性调试,就能发现有个实例化前扩展处理器叫org.springframework.aop.aspectj.annotation.AnnotationAwareAspectJAutoProxyCreator,这是Spring IOC与Spring AOP协作的一个地方,下文“Spring IOC与Spring AOP如何协作对Bean生成代理”会详细介绍。

为解决循环引用,提前暴露引用

为解决循环依赖,这里会判断是否需要提前暴露引用,如需,将“提前暴露引用的方法”封装成工厂对象,放入“单例工厂缓存”。坐标:org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#doCreateBean中583-589行。

“是否需要提前暴露引用”的判断条件有3个,是“并且”的关系:

  1. 此bean是否定义为单例
  2. 全局配置是否允许循环引用
  3. 此单例是否正常创建中

具体代码如下:

如果需要提前暴露引用,会将获取提前暴露引用的方法封装成对象工厂(ObjectFactory),以beanName为键放入“单例工厂缓存”中。“单例工厂缓存”则会在上述的获取缓存方法中使用到,具体是在第3级缓存中使用到。

具体代码如下:

我们需要继续看getEarlyBeanReference方法:

可以发现里面调用一系列SmartInstantiationAwareBeanPostProcessor扩展处理器,这些扩展处理的返回结果赋予exposedObject从而替换原来的Bean。

与本文讨论话题相关的扩展处理器有1个:
org.springframework.aop.aspectj.annotation.AnnotationAwareAspectJAutoProxyCreator,IOC与AOP连接的地方,详见下文“Spring IOC与Spring AOP如何协作对Bean生成代理”章节。

调用“初始化后扩展处理器”

坐标:org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#initializeBean(java.lang.String, java.lang.Object, org.springframework.beans.factory.support.RootBeanDefinition)中1799-1801行。

可以通过扩展处理器对Bean进行加工。

与本文讨论话题相关的处理器有1个:

org.springframework.aop.aspectj.annotation.AnnotationAwareAspectJAutoProxyCreator,IOC与AOP连接的地方,详见下文“Spring IOC与Spring AOP如何协作对Bean生成代理”章节。

检测Bean的原始版本与最终版本是否不一致

查看org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#doCreateBean的607-632行,可以知道触发BeanCurrentlyInCreationException要同时满足以下条件:

  1. Bean存在循环引用

  2. Bean提前暴露对象(即上文说了3个条件),并且将提前暴露的对象注入到其它Bean中

  3. Bean使用了一些特性,这些特性会在上面的扩展处理器替换Bean对象,导致Bean对象与最初的对象不一致

用本文的案例遇到的异常来分析:

我们的代码中同时存在循环依赖和@Async,通过查看“Spring IOC与@Async如何协作对Bean生成代理”章节,可以发现@Async的实现实际上是在“初始化后扩展处理器”中对Bean进行包装代理。

结合循环依赖的Bean需要提前暴露对象,就造成了提前暴露对象时暴露的是Bean的原始版本,而@Async的实现对Bean进行代理包装后的是最终版本,所以Bean的最终版本不等于原始版本,就触发了上述异常,导致应用启动不起来了。

Spring IOC如何跟其它特性协作?

Spring IOC与@Async如何协作对Bean生成代理?

如果Spring IOC管理的Bean使用@Async实现异步调用,Spring是如何为相关Bean生成代理对象的呢?

通过调试代码,观察Bean在哪个节点变化成代理对象,发现下述地方会对Bean生成代理对象:初始化后扩展处理器。

@Async的初始化后扩展处理器的实现类是:org.springframework.scheduling.annotation.AsyncAnnotationBeanPostProcessor,实际方法是由父类实现的:org.springframework.aop.framework.AbstractAdvisingBeanPostProcessor#postProcessAfterInitialization

查看该方法,可以看到如果满足条件,最后会触发AbstractAdvisingBeanPostProcessor类92行的方法创建代理对象:

继续跟踪进去,来到org.springframework.aop.framework.DefaultAopProxyFactory#createAopProxy,可以发现创建代理的方式有两种,如果有实现接口,则使用JDK动态代理的方式(JdkDynamicAopProxy),否则使用CGLIB(ObjenesisCglibAopProxy)。

有个疑问,既然循环依赖和@Async会引发偶现的BeanCurrentlyInCreationException,而AOP与@Async底层都是依赖代理,循环依赖和AOP同时使用的情况下会有同样的问题吗?

后续章节我们会对AOP进行讨论,@Transactional是否有对循环依赖的情况做支持呢?请自行探究哈。

Spring IOC与Spring AOP如何协作对Bean生成代理?

如果Spring IOC维护的Bean涉及面向切面编程,需要Spring AOP为之生成代理对象,那么Spring IOC和Spring AOP是在哪里协作的呢?

通过调试代码,观察Bean在哪里产生代理对象,发现下述3处地方有可能会对Bean生成代理对象。

  1. 实例化前扩展处理器

  2. 获取提前暴露的引用的扩展处理器

  3. 初始化后扩展处理器

实例化前扩展处理器

代码坐标:org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator#postProcessBeforeInstantiation

这里是实例化的前置处理,也就是说目标对象还没有实例化,那么有个疑问,如何对还未实例化的对象进行代理?

阅读如下代码可知,这里是处理配置了customTargetSourceCreators代理的地方,这个特性用得貌似不多,反正我没使用过。也就是说,如果没配置customTargetSourceCreators,并不是在这里创建代理:

获取提前暴露的引用的扩展处理器

代码坐标:org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator#getEarlyBeanReference

这里是提前暴露引用的扩展处理器,如上文描述,多个单例Bean存在循环依赖的情况下,创建这些Bean的时候会提前暴露引用,提前暴露引用前会处理“获取提前暴露的引用的扩展处理器”,这是其中一个,用于处理提前暴露引用的Bean需要进行AOP处理的情况。

初始化后扩展处理器

代码坐标:org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator#postProcessAfterInitialization

这里是常规的生成代理对象的地方,生成代理对象是使用wrapIfNecessary方法:

Spring AOP是否兼容提前暴露对象?

查看了这3个扩展处理器,其中包含“获取提前暴露的引用的扩展处理器”。并且在3个扩展处理器中均会获取cacheKey,然后根据cacheKey来判断是否已经处理,如处理了就不重复处理了,所以Spring AOP是兼容提前暴露对象的:

为什么启动失败是偶现的?因为不同环境下Bean加载顺序不一致

因为加载Bean的顺序取决于从文件系统中获取Bean的顺序,而从文件系统获取Bean文件是通过java.io.File#listFiles()方法获取一个文件夹下的文件列表的,查看这个方法的注释可以发现它是不保证顺序的。

而Spring通过java.io.File#listFiles()获取需加载的Bean文件列表后,会对文件进行重新排序,这个重新排序旧版本与新版本的实现有些不一样,我们下面介绍3个版本,它们的实现方式也是不断地迭代优化中。代码坐标为org.springframework.core.io.support.PathMatchingResourcePatternResolver#doRetrieveMatchingFiles

spring-core-5.1.9的Bean加载顺序

在spring-core-5.1.9(spring-boot-starter-parent 2.2.2.RELEASE)中,可以发现获取一个目录的文件列表已经封装了一个叫listDirectory的方法,在此方法里依赖自定义的文件名对比器进行排序:

spring-core-4.3.12的Bean加载顺序

而在spring-core-4.3.12(spring-boot-starter-parent 1.5.8.RELEASE)中,则通过数组工具类的方式使用File默认的java.io.File#compareTo进行排序:

spring-core-4.2.8的Bean加载顺序

而在spring-core-4.2.8(spring-boot-starter-parent 1.3.8.RELEASE)中,使用java.io.File#listFiles()获取到文件列表后,没对文件列表进行排序,然后就开始便利文件列表继续递归调用。

会有哪些问题呢?

spring-core-4.2.8的Bean加载顺序,会有哪些问题呢?

1、这样有可能导致不同操作系统加载Bean的顺序是不一致的,比如使用此版本的Spring,同样的代码在Windows加载Bean的顺序跟在Linux很可能不一致。
如何验证?这个场景比较容易复现,在Spring脚手架中定义多个Bean,然后在各个Bean的默认构造方法打印一下日志,分别在Windows和Linux环境中启动,然后观察各个Bean默认构造方法的执行顺序即可。

2、甚至同一操作系统在多次不同的启动时可能不一致?因为java.io.File#listFiles()返回的文件列表是不保证顺序的,它依赖与各操作系统的JDK的逻辑以及各操作系统的底层实现。我们跟踪java.io.File#listFiles(),就能发现它依赖的是java.io.FileSystem#list,我看的Windows的JDK源码,这里使用的是WinNTFileSystem:

为什么Bean加载顺序不一致会导致有时成功,有时失败呢?

结合上面介绍“提前暴露对象”和“检测Bean的原始版本与最终版本是否不一致”的内容,可以知道触发BeanCurrentlyInCreationException要同时满足以下条件,结合“如何复现”章节的代码看是否满足:

  1. Bean存在循环引用(AppleService、BoyService循环引用,满足)

  2. Bean提前暴露对象(即上文说了3个条件),并且将提前暴露的对象注入到其它Bean中(AppleService、BoyService都会提前暴露引用,先加载的Bean会将提前暴露的对象注入到后加载的Bean中,所以,AppleService先加载满足,BoyService先加载不满足)

  3. Bean使用了一些特性,这些特性会在上面的扩展处理器替换Bean对象,导致Bean对象与最初的对象不一致(AppleService使用了@Async特性,会通过扩展处理器创建代理对象,AppleService满足)

假如AppleService、BoyService循环引用,AppleService中包含@Async方法。

假设先创建AppleService,再创建BoyService,会引发该异常。因为AppleService提前暴露了原始对象,并注入到BoyService的属性中,后来因为它有@Async,需要创建代理对象,最后发现原始对象与最终的代理对象不一致。具体见下图蓝色分支:

假设先创建BoyService,再创建AppleService,不会引发该异常,过程跟先加载AppleService并无不同,不同点在于最后一个红色的节点,由于BoyService并无@Async(也就是先加载的Bean没使用创建代理的特性),所以不会创建代理对象,自然就不会引发“提前暴露的引用与最终的引用不一致”的异常。

如何解决?

我们知道了问题的原因,那解决方法自然手到擒来,有许多解决方法,比如:

  1. 将@Async方法提取到其它相关的Bean中,将@Async与循环引用分开
  2. 使用@Lazy等方式控制Bean的加载顺序,以避免具有@Async与循环引用的Bean先加载
  3. 用其它替代方式实现,比如使用@Async的,则用多线程方式处理

解决方法不仅仅上面3种,还有很多很多,请自行挖掘。

参考的优秀书籍与文章

  1. 书籍 - Spring源码深度解析

  2. 书籍 - Spring技术内幕 第2版

  3. 文章 - 跳出源码地狱,Spring巧用三级缓存解决循环依赖-原理篇

最后

小弟不才,学识有限,如有错漏,欢迎指正哈。
如果本文对你有帮助,记得“一键三连”(“点赞”、“评论”、“收藏”)哦!

posted @ 2020-11-05 23:41  nick_huang  阅读(1120)  评论(1编辑  收藏  举报