最新消息: 电脑我帮您提供丰富的电脑知识,编程学习,软件下载,win7系统下载。

从一个Spring动态代理Bug聊到循环依赖

IT培训 admin 3浏览 0评论

从一个Spring动态代理Bug聊到循环依赖

文章目录

        • Bug复现
        • 结论
        • @PostConstruct的在Bean的生命周期的哪一步
        • 一般代理类的生成时机在生命周期的哪一步
        • 解决办法
          • 两个思路
          • 1.不生成代理类
          • 2.在生成代理类之后再进行数据的初始化
        • 解决方法的原理
        • 早期代理Bean是什么时候生成的
        • 循环依赖
        • 结语

喜欢省流太长不看的同学们
东老师vme50解决bug
bug是由于postconstuct注解使用时代理类未生效的问题
由于东老师的胡搅蛮缠,讲了讲bug的原因
没有深入讲源码,因为东老师给的钱不够
顺便讲了讲解决思路及原理
解决方案1.自己注入自己 2.使用编程式事务
动态代理及循环依赖的大体逻辑

上周四需要对一个老功能进行迭代,功能开发完毕后,有数个表增加了些字段,需要对相关表模型老数据进行数据清洗。
负责这个功能的好兄弟东老师在预发环境遇到了一个问题,抛给我看看是咋回事,demo代码如下
这个场景很常见

需求改了之前的逻辑,历史数据需要清洗
如果线上和预发环境是一个库(我们就是),为了方便大多数会在预发环境对线上的数据进行清洗

东老师:浪啊帮我看看这段代码有问题吗
东老师是我的hxd,所以对于这样的诚恳请求
我很有礼貌:滚 没时间
东东老师发出了一段神秘的代码:kfcVYou50
我:不好意思,东老师,刚才怪我我声音太大,咱们互帮互助,我义不容辞,哪个分支我看下,对了,v50到我微信
接着check out,pull
我心想凭借这么多年写bug的经验 ,还有什么风浪没见过
果然这bug只是个别致的小东西罢了
只是东老师像个刚被我抛弃的怨妇,非要我深入讲讲
为了这个神秘的代码kfcvme50,我也只好由着东老师的性子来谈谈这段代码的逻辑
我告诉东老师这次我只在旁边蹭蹭不进去,不深入聊源码
东老师还是大怒,我给了钱的
我说你想吃三碗的粉,只给一碗的钱,想讲源码,得加钱
当然了,我也不会告诉东老师,源码太多,我也不太会,只能说没时间

Bug复现

粗略看了下代码,没啥问题呀,d老师莫不是耍我。
先启动下看看,嚯,还真报错了

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'testPostConstructServiceImpl': Invocation of init method failed; nested exception is java.lang.IllegalStateException: Cannot find current proxy: Set 'exposeProxy' property on Advised to 'true' to make it available, and ensure that AopContext.currentProxy() is invoked in the same thread as the AOP invocation context.at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor.postProcessBeforeInitialization(InitDestroyAnnotationBeanPostProcessor.java:160) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:415) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1786) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:594) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:516) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:324) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:322) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:897) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:879) ~[spring-context-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:551) ~[spring-context-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:141) ~[spring-boot-2.2.13.RELEASE.jar:2.2.13.RELEASE]at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:747) ~[spring-boot-2.2.13.RELEASE.jar:2.2.13.RELEASE]at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:405) ~[spring-boot-2.2.13.RELEASE.jar:2.2.13.RELEASE]at org.springframework.boot.SpringApplication.run(SpringApplication.java:315) ~[spring-boot-2.2.13.RELEASE.jar:2.2.13.RELEASE]at com.zhanghl.first.FirstApplication.main(FirstApplication.java:26) [classes/:na]
Caused by: java.lang.IllegalStateException: Cannot find current proxy: Set 'exposeProxy' property on Advised to 'true' to make it available, and ensure that AopContext.currentProxy() is invoked in the same thread as the AOP invocation context.at org.springframework.aop.framework.AopContext.currentProxy(AopContext.java:69) ~[spring-aop-5.2.12.RELEASE.jar:5.2.12.RELEASE]at com.zhanghl.first.controller.TestPostConstructServiceImpl.addProduct(TestPostConstructServiceImpl.java:33) ~[classes/:na]at com.zhanghl.first.controller.TestPostConstructServiceImpl.init(TestPostConstructServiceImpl.java:59) ~[classes/:na]at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_201]at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_201]at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_201]at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_201]at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleElement.invoke(InitDestroyAnnotationBeanPostProcessor.java:389) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleMetadata.invokeInitMethods(InitDestroyAnnotationBeanPostProcessor.java:333) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor.postProcessBeforeInitialization(InitDestroyAnnotationBeanPostProcessor.java:157) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]... 16 common frames omittedDisconnected from the target VM, address: '127.0.0.1:60861', transport: 'socket'

报错找不到当前的代理对象

Cannot find current proxy: Set ‘exposeProxy’ property on Advised to ‘true’ to make it available, and ensure that AopContext.currentProxy() is invoked in the same thread as the AOP invocation context.

很容易定位到引起这个报错的代码

((TestPostConstructServiceImpl)AopContext.currentProxy()).save();

说明一下这个地方为什么要用AopContext.currentProxy(),大伙熟悉**@Transactional**注解的应该都很清楚,有如下几种情况导致事务注解会失效

1.非public修复的方法
2.同一个类普通方法调用事务方法
3.rollobackFor属性异常类不对
4.异常被catch
5.数据库本身不支持事务等

这个demo代码中符合上面的第二种情形,东老师使用的没毛病。
当然了,也可以使用编程式事务的方式可以代替注解的使用,从而不需要使用AopContext.currentProxy(),也就能避免这种情况的发生,但本文就这种情况进行讨论。


首先我们来注释掉@PostConstruct正常调用下接口看看,返回正常


再看下添加了@PostConstruct之后的报错提示

Cannot find current proxy

结论

回想一下之前看过的Spring源码,背过的八股文,Bean的生命周期,Spring动态代理,Bean的循环依赖。
得出结论:@PostConstruct起作用时,TestPostConstructServiceImpl的代理类并没有生成。

东老师:怎么得出来的这个结论
我:你这属于技术咨询,得加钱
东老师大怒:歪日 你这黑心商人,v你50 你忘了,我举报你
我一看东老师宁为玉碎,不为瓦全的铁骨铮铮模样,决定大发慈悲,拯救下无知的办公室老年人了


@PostConstruct的在Bean的生命周期的哪一步

根据异常信息,我们很容易就可以定位到报错的那行代码。
AbstractAutowireCapableBeanFactory 的initializeBean() Bean的初始化方法,在Bean populateBean() 填充属性之后
initializeBean 的主要作用有如下几点

  1. 如果实现了Aware接口,回调相关Aware接口的逻辑 例如 BeanNameAware、BeanClassLoaderAware、BeanFactoryAware等接口
  2. 执行BeaPostProcessor的前置回调方法
  3. 执行初始化方法
  4. 执行BeanPostProcessor的后置回调方法

其中@PostConstruct执行的地方在第二步applyBeanPostProcessorsBeforeInitialization()前置回调,在将断点打在这里,进去看看堆栈信息,和执行过程。

这里我们快速定位到CommonAnnotationBeanPostProcessor,通过名字我们就知道它的作用了,通用的注解后置处理器
在执行CommonAnnotationBeanPostProcessor的前置回调时,看到了我们遇到的报错信息,没有找到代理类。

一般代理类的生成时机在生命周期的哪一步

一般,注意我们这里说的一般代理类,Spring中代理类的生成时机不止一个地方,后面我们的解决方案也会再讲一下。
一般代理类生成时机是在我们上面说的第四步

执行BeanPostProcessor的后置回调方法

我们去掉@PostConstruct注解再次Debug看下
AnnotationAwareAspectJAutoProxyCreator Spring代理实现核心AbstractAutoProxyCreator的子类
AnnotationAwareAspectJAutoProxyCreator 在后置处理方法中对原有目标类进行代理,生成了代理类。

Spring的动态代理核心逻辑就在这里,很重要,建议自己debug瞅瞅
AbstractAutoProxyCreator 的wrapIfNecessary()方法
AbstractAutoProxyCreator 的wrapIfNecessary()方法
AbstractAutoProxyCreator 的wrapIfNecessary()方法
它实现了 BeanPostProcessor、SmartInstantiationAwareBeanPostProcessor 和 InstantiationAwareBeanPostProcessor 三个接口,那么这个类就是 Spring AOP 的入口,在这里将 Advice 织入我们的 Bean 中,创建代理对象。

这块后置逻辑处理完,可以看到我们收获了当前类的代理类

东老师:你小子不戳哦,那我该怎么解决呢


解决办法

两个思路
1.不生成代理类

这种很好理解,这种思路是不通过切面代理的方式对方法进行事务处理
比如说将事务方法单独抽出一个类
当然更好的方式是使用编程式事务,此处不再赘述
或者在应用程序启动完毕之后,通过调用接口的方式对数据进行初始化

2.在生成代理类之后再进行数据的初始化

东老师:既然上面的方法可以了,你可以告退了
我意犹未尽:东老师,难道你不想做我就是我不一样的花火吗,难道你就想和外面的妖艳贱货一样吗,难道你不想进去看看吗
东老师挣扎了下,想起来自己还v我50不能亏决定继续听我bb。

正如我上面所说一般代理类生成时机是在Bean的初始化之后,
也就是上面说的AbstractAutowireCapableBeanFactory 的initializeBean()第四步,这种场景下我们无法实现。
基于上述的业务场景,Spring作为当前Java生态里最流行的框架,当然也提供了解决方法。
自己注入自己

我们可以看下执行结果


解决方法的原理

带着疑问来看看为什么Bean自己注入自己的方式能生效
我们只需要专注以下两个个问题

1.是否生成了代理类
2.如果是,那么代理类是在什么时候生成的

和上文分析一样,我们还是使用之前的断点,看下@PostConstruct注解被执行的时候上下文,也就是initializeBean()方法中执行BeanPostProcessor接口前置回调方法时候,其中CommonAnnotationBeanPostProcessor的前置回调方法,会处理@PostConstruct注解。
看下CommonAnnotationBeanPostProcessor的类注释

执行初始化的方法

invokeInitMethods(Object target, String beanName)
Target就是我们的当前类,看下图的堆栈信息当前Target是一个普通对象,这个对象包含两个属性
1.productMapper不重要不谈
2.testPostConstructService 重点

这不是我们当前Bean注入自己的属性嘛
可以看到这个属性是个代理类,解答了我们的第一个问题 --‘是否生成了代理类’
这个属性可以看到它本身的另外两个属性是空的,说明这个代理类是个不成熟的Bean(早期Bean,说到这是不是想到了什么)
注意哈 此时Spring中对于TestPostConstructServiceImpl demo类存在两个Bean,一个 当前Bean,一个早期代理Bean


当前Target,也就是TestPostConstructServiceImpl要执行的init方法。


从上述分析可知,在Bean的初始化完成之前,Bean自己注入自己,会产生一个早期代理对象来当作属性。
接下来我们的问题是
早期代理Bean是什么时候生成的
以及
为什么要生成早期代理Bean


早期代理Bean是什么时候生成的

当前场景下,TestPostConstructServiceImpl自己注入自己,注入的这个Bean是个早期代理对象

那么我们只需要看Bean在属性填充的时候,是怎么生成这个代理对象的就可以了。

断点打在AbstractAutowireCapableBeanFactorypopulateBean() 填充属性的方法上。

populateBean()方法内部,逻辑很多,如下所示,InstantiationAwareBeanPostProcessor这个后置处理器就是我们寻找了好久的小宝贝,
这个接口InstantiationAwareBeanPostProcessor在SpringBean的生命周期中占据着核心位置。
在这里插入图片描述AutowiredAnnotationBeanPostProcessor实现了InstantiationAwareBeanPostProcessor,其中
postProcessProperties()中
inject()方法也是我们通常所说的依赖注入的由来
看下类注释
此处将@Autowired 修饰的属性注入到当前Bean

循环依赖

1.对于普通的Bean注入这块逻辑很简单,再去获取需要注入Bean的实例,走一遍创建的逻辑,将需要注入进来的Bean实例化给当前Bean即可
2.对于我们这个场景,你想到了什么,自己注入自己,自己依赖自己,这不就妥妥的循环依赖嘛
来看下第二点,这种循环依赖是怎么解决的
继续跟着inject,往里面探究,是怎么给当前Bean注入自己的。

注意看上图在inject()的执行过程中,又执行到了==getBean()==方法,开始了套娃之旅,注意和左边的堆栈信息对比,那么当前Bean还会执行创建一次吗。
下图,跟着执行可以看到注入的这个Bean getSingleton()又开始执行了
但是从三级缓存里拿到的对象工厂并不为空
但是从三级缓存里拿到的对象工厂并不为空
但是从三级缓存里拿到的对象工厂并不为空
这个是和当前Bean的最大区别,当前Bean第一次创建过程中,这个地方为null。

再来看一下,这个ObjectFactory对象工厂偷偷摸摸的干了啥,一个函数式接口


执行进入getObject()方法

嚯,这不就是懒加载放进去了个早期Bean引用吗
那么 :
1.这个引用是个啥,
2.什么时候放进去的呢

先看看这个引用是什么
画黑板,敲重点,如下方法注释,为了解决循环依赖
这样的逻辑我们应该看到了很多次,遍历所有的BeanPostProcessor(),在Bean生命周期的不同阶段处理不同的回调逻辑,Spring通过这种方式在Bean生命周期的过程中,有着很强的拓展性。
这次需要处理的是SmartInstantiationAwareBeanPostProcessor ==getEarlyBeanReference()方法
老规矩 先看注释
核心大意是 :让Bean提前暴露出去,以便尽早访问指定的bean,通常用于解析循环引用

在SmartInstantiationAwareBeanPostProcessor的实现类AnnotationAwareAspectJAutoProxyCreator
中调用了AbstractAutoProxyCreator 的getEarlyBeanReference();
来跟我念一下
AbstractAutoProxyCreator,wrapIfNecessary()
AbstractAutoProxyCreator,wrapIfNecessary()
== AbstractAutoProxyCreator,wrapIfNecessary()

这不就是我们强调的Spring动态代理的核心逻辑吗
也就是在这里我们获得了当前Bean的Cglib代理类

东老师:哦吼,详细说说这块逻辑
我:滚,再v50
东老师:当我没说

wrapIfNecessary这里的逻辑本文不过多讨论,因为我写不完。

这个引用就是通过Spring的AbstractAutoProxyCreator给当前Bean创建一个动态代理
那么回到第二个问题
这个代理什么时候放进去的呢

东老师听到这,瞬间羞涩:你好坏,什么进去不进去的
我大怒:滚

我们回到当前Bean的创建过程中,注意我说的不是作为属性需要注入的Bean,
而是我们Bean第一次初始化的过程中 AbstractAutowireCapableBeanFactory 的doCreateBean()方法


如上图,在当前Bean的填充属性及初始化之前,我们将这个懒加载的函数放进了三级缓存中。
然后就是我们上面讨论的流程

  1. 填充属性
  2. 依赖注入
  3. 从三级缓存中获取要注入Bean的实例(实际是这个懒加载函数)
  4. 执行懒加载的函数:AbstractAutoProxyCreator创建代理类后
  5. 注入获取到的代理类

最终在当前Bean初始化阶段initializeBean()执行int方法时
可以拿到注入的代理类,从而可以顺利执行

((TestPostConstructServiceImpl)AopContext.currentProxy()).save();

结语

东老师心花怒放:浪啊你真棒
我:滚,送你张图吧 东老师 好好学习,小心脱下长衫,黄袍加身,美团小哥欢迎你

如果你看完了这篇文章,恭喜你又get了一些没什么diao用的知识点

从一个Spring动态代理Bug聊到循环依赖

文章目录

        • Bug复现
        • 结论
        • @PostConstruct的在Bean的生命周期的哪一步
        • 一般代理类的生成时机在生命周期的哪一步
        • 解决办法
          • 两个思路
          • 1.不生成代理类
          • 2.在生成代理类之后再进行数据的初始化
        • 解决方法的原理
        • 早期代理Bean是什么时候生成的
        • 循环依赖
        • 结语

喜欢省流太长不看的同学们
东老师vme50解决bug
bug是由于postconstuct注解使用时代理类未生效的问题
由于东老师的胡搅蛮缠,讲了讲bug的原因
没有深入讲源码,因为东老师给的钱不够
顺便讲了讲解决思路及原理
解决方案1.自己注入自己 2.使用编程式事务
动态代理及循环依赖的大体逻辑

上周四需要对一个老功能进行迭代,功能开发完毕后,有数个表增加了些字段,需要对相关表模型老数据进行数据清洗。
负责这个功能的好兄弟东老师在预发环境遇到了一个问题,抛给我看看是咋回事,demo代码如下
这个场景很常见

需求改了之前的逻辑,历史数据需要清洗
如果线上和预发环境是一个库(我们就是),为了方便大多数会在预发环境对线上的数据进行清洗

东老师:浪啊帮我看看这段代码有问题吗
东老师是我的hxd,所以对于这样的诚恳请求
我很有礼貌:滚 没时间
东东老师发出了一段神秘的代码:kfcVYou50
我:不好意思,东老师,刚才怪我我声音太大,咱们互帮互助,我义不容辞,哪个分支我看下,对了,v50到我微信
接着check out,pull
我心想凭借这么多年写bug的经验 ,还有什么风浪没见过
果然这bug只是个别致的小东西罢了
只是东老师像个刚被我抛弃的怨妇,非要我深入讲讲
为了这个神秘的代码kfcvme50,我也只好由着东老师的性子来谈谈这段代码的逻辑
我告诉东老师这次我只在旁边蹭蹭不进去,不深入聊源码
东老师还是大怒,我给了钱的
我说你想吃三碗的粉,只给一碗的钱,想讲源码,得加钱
当然了,我也不会告诉东老师,源码太多,我也不太会,只能说没时间

Bug复现

粗略看了下代码,没啥问题呀,d老师莫不是耍我。
先启动下看看,嚯,还真报错了

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'testPostConstructServiceImpl': Invocation of init method failed; nested exception is java.lang.IllegalStateException: Cannot find current proxy: Set 'exposeProxy' property on Advised to 'true' to make it available, and ensure that AopContext.currentProxy() is invoked in the same thread as the AOP invocation context.at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor.postProcessBeforeInitialization(InitDestroyAnnotationBeanPostProcessor.java:160) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:415) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1786) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:594) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:516) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:324) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:322) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:897) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:879) ~[spring-context-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:551) ~[spring-context-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:141) ~[spring-boot-2.2.13.RELEASE.jar:2.2.13.RELEASE]at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:747) ~[spring-boot-2.2.13.RELEASE.jar:2.2.13.RELEASE]at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:405) ~[spring-boot-2.2.13.RELEASE.jar:2.2.13.RELEASE]at org.springframework.boot.SpringApplication.run(SpringApplication.java:315) ~[spring-boot-2.2.13.RELEASE.jar:2.2.13.RELEASE]at com.zhanghl.first.FirstApplication.main(FirstApplication.java:26) [classes/:na]
Caused by: java.lang.IllegalStateException: Cannot find current proxy: Set 'exposeProxy' property on Advised to 'true' to make it available, and ensure that AopContext.currentProxy() is invoked in the same thread as the AOP invocation context.at org.springframework.aop.framework.AopContext.currentProxy(AopContext.java:69) ~[spring-aop-5.2.12.RELEASE.jar:5.2.12.RELEASE]at com.zhanghl.first.controller.TestPostConstructServiceImpl.addProduct(TestPostConstructServiceImpl.java:33) ~[classes/:na]at com.zhanghl.first.controller.TestPostConstructServiceImpl.init(TestPostConstructServiceImpl.java:59) ~[classes/:na]at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_201]at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_201]at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_201]at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_201]at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleElement.invoke(InitDestroyAnnotationBeanPostProcessor.java:389) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleMetadata.invokeInitMethods(InitDestroyAnnotationBeanPostProcessor.java:333) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor.postProcessBeforeInitialization(InitDestroyAnnotationBeanPostProcessor.java:157) ~[spring-beans-5.2.12.RELEASE.jar:5.2.12.RELEASE]... 16 common frames omittedDisconnected from the target VM, address: '127.0.0.1:60861', transport: 'socket'

报错找不到当前的代理对象

Cannot find current proxy: Set ‘exposeProxy’ property on Advised to ‘true’ to make it available, and ensure that AopContext.currentProxy() is invoked in the same thread as the AOP invocation context.

很容易定位到引起这个报错的代码

((TestPostConstructServiceImpl)AopContext.currentProxy()).save();

说明一下这个地方为什么要用AopContext.currentProxy(),大伙熟悉**@Transactional**注解的应该都很清楚,有如下几种情况导致事务注解会失效

1.非public修复的方法
2.同一个类普通方法调用事务方法
3.rollobackFor属性异常类不对
4.异常被catch
5.数据库本身不支持事务等

这个demo代码中符合上面的第二种情形,东老师使用的没毛病。
当然了,也可以使用编程式事务的方式可以代替注解的使用,从而不需要使用AopContext.currentProxy(),也就能避免这种情况的发生,但本文就这种情况进行讨论。


首先我们来注释掉@PostConstruct正常调用下接口看看,返回正常


再看下添加了@PostConstruct之后的报错提示

Cannot find current proxy

结论

回想一下之前看过的Spring源码,背过的八股文,Bean的生命周期,Spring动态代理,Bean的循环依赖。
得出结论:@PostConstruct起作用时,TestPostConstructServiceImpl的代理类并没有生成。

东老师:怎么得出来的这个结论
我:你这属于技术咨询,得加钱
东老师大怒:歪日 你这黑心商人,v你50 你忘了,我举报你
我一看东老师宁为玉碎,不为瓦全的铁骨铮铮模样,决定大发慈悲,拯救下无知的办公室老年人了


@PostConstruct的在Bean的生命周期的哪一步

根据异常信息,我们很容易就可以定位到报错的那行代码。
AbstractAutowireCapableBeanFactory 的initializeBean() Bean的初始化方法,在Bean populateBean() 填充属性之后
initializeBean 的主要作用有如下几点

  1. 如果实现了Aware接口,回调相关Aware接口的逻辑 例如 BeanNameAware、BeanClassLoaderAware、BeanFactoryAware等接口
  2. 执行BeaPostProcessor的前置回调方法
  3. 执行初始化方法
  4. 执行BeanPostProcessor的后置回调方法

其中@PostConstruct执行的地方在第二步applyBeanPostProcessorsBeforeInitialization()前置回调,在将断点打在这里,进去看看堆栈信息,和执行过程。

这里我们快速定位到CommonAnnotationBeanPostProcessor,通过名字我们就知道它的作用了,通用的注解后置处理器
在执行CommonAnnotationBeanPostProcessor的前置回调时,看到了我们遇到的报错信息,没有找到代理类。

一般代理类的生成时机在生命周期的哪一步

一般,注意我们这里说的一般代理类,Spring中代理类的生成时机不止一个地方,后面我们的解决方案也会再讲一下。
一般代理类生成时机是在我们上面说的第四步

执行BeanPostProcessor的后置回调方法

我们去掉@PostConstruct注解再次Debug看下
AnnotationAwareAspectJAutoProxyCreator Spring代理实现核心AbstractAutoProxyCreator的子类
AnnotationAwareAspectJAutoProxyCreator 在后置处理方法中对原有目标类进行代理,生成了代理类。

Spring的动态代理核心逻辑就在这里,很重要,建议自己debug瞅瞅
AbstractAutoProxyCreator 的wrapIfNecessary()方法
AbstractAutoProxyCreator 的wrapIfNecessary()方法
AbstractAutoProxyCreator 的wrapIfNecessary()方法
它实现了 BeanPostProcessor、SmartInstantiationAwareBeanPostProcessor 和 InstantiationAwareBeanPostProcessor 三个接口,那么这个类就是 Spring AOP 的入口,在这里将 Advice 织入我们的 Bean 中,创建代理对象。

这块后置逻辑处理完,可以看到我们收获了当前类的代理类

东老师:你小子不戳哦,那我该怎么解决呢


解决办法

两个思路
1.不生成代理类

这种很好理解,这种思路是不通过切面代理的方式对方法进行事务处理
比如说将事务方法单独抽出一个类
当然更好的方式是使用编程式事务,此处不再赘述
或者在应用程序启动完毕之后,通过调用接口的方式对数据进行初始化

2.在生成代理类之后再进行数据的初始化

东老师:既然上面的方法可以了,你可以告退了
我意犹未尽:东老师,难道你不想做我就是我不一样的花火吗,难道你就想和外面的妖艳贱货一样吗,难道你不想进去看看吗
东老师挣扎了下,想起来自己还v我50不能亏决定继续听我bb。

正如我上面所说一般代理类生成时机是在Bean的初始化之后,
也就是上面说的AbstractAutowireCapableBeanFactory 的initializeBean()第四步,这种场景下我们无法实现。
基于上述的业务场景,Spring作为当前Java生态里最流行的框架,当然也提供了解决方法。
自己注入自己

我们可以看下执行结果


解决方法的原理

带着疑问来看看为什么Bean自己注入自己的方式能生效
我们只需要专注以下两个个问题

1.是否生成了代理类
2.如果是,那么代理类是在什么时候生成的

和上文分析一样,我们还是使用之前的断点,看下@PostConstruct注解被执行的时候上下文,也就是initializeBean()方法中执行BeanPostProcessor接口前置回调方法时候,其中CommonAnnotationBeanPostProcessor的前置回调方法,会处理@PostConstruct注解。
看下CommonAnnotationBeanPostProcessor的类注释

执行初始化的方法

invokeInitMethods(Object target, String beanName)
Target就是我们的当前类,看下图的堆栈信息当前Target是一个普通对象,这个对象包含两个属性
1.productMapper不重要不谈
2.testPostConstructService 重点

这不是我们当前Bean注入自己的属性嘛
可以看到这个属性是个代理类,解答了我们的第一个问题 --‘是否生成了代理类’
这个属性可以看到它本身的另外两个属性是空的,说明这个代理类是个不成熟的Bean(早期Bean,说到这是不是想到了什么)
注意哈 此时Spring中对于TestPostConstructServiceImpl demo类存在两个Bean,一个 当前Bean,一个早期代理Bean


当前Target,也就是TestPostConstructServiceImpl要执行的init方法。


从上述分析可知,在Bean的初始化完成之前,Bean自己注入自己,会产生一个早期代理对象来当作属性。
接下来我们的问题是
早期代理Bean是什么时候生成的
以及
为什么要生成早期代理Bean


早期代理Bean是什么时候生成的

当前场景下,TestPostConstructServiceImpl自己注入自己,注入的这个Bean是个早期代理对象

那么我们只需要看Bean在属性填充的时候,是怎么生成这个代理对象的就可以了。

断点打在AbstractAutowireCapableBeanFactorypopulateBean() 填充属性的方法上。

populateBean()方法内部,逻辑很多,如下所示,InstantiationAwareBeanPostProcessor这个后置处理器就是我们寻找了好久的小宝贝,
这个接口InstantiationAwareBeanPostProcessor在SpringBean的生命周期中占据着核心位置。
在这里插入图片描述AutowiredAnnotationBeanPostProcessor实现了InstantiationAwareBeanPostProcessor,其中
postProcessProperties()中
inject()方法也是我们通常所说的依赖注入的由来
看下类注释
此处将@Autowired 修饰的属性注入到当前Bean

循环依赖

1.对于普通的Bean注入这块逻辑很简单,再去获取需要注入Bean的实例,走一遍创建的逻辑,将需要注入进来的Bean实例化给当前Bean即可
2.对于我们这个场景,你想到了什么,自己注入自己,自己依赖自己,这不就妥妥的循环依赖嘛
来看下第二点,这种循环依赖是怎么解决的
继续跟着inject,往里面探究,是怎么给当前Bean注入自己的。

注意看上图在inject()的执行过程中,又执行到了==getBean()==方法,开始了套娃之旅,注意和左边的堆栈信息对比,那么当前Bean还会执行创建一次吗。
下图,跟着执行可以看到注入的这个Bean getSingleton()又开始执行了
但是从三级缓存里拿到的对象工厂并不为空
但是从三级缓存里拿到的对象工厂并不为空
但是从三级缓存里拿到的对象工厂并不为空
这个是和当前Bean的最大区别,当前Bean第一次创建过程中,这个地方为null。

再来看一下,这个ObjectFactory对象工厂偷偷摸摸的干了啥,一个函数式接口


执行进入getObject()方法

嚯,这不就是懒加载放进去了个早期Bean引用吗
那么 :
1.这个引用是个啥,
2.什么时候放进去的呢

先看看这个引用是什么
画黑板,敲重点,如下方法注释,为了解决循环依赖
这样的逻辑我们应该看到了很多次,遍历所有的BeanPostProcessor(),在Bean生命周期的不同阶段处理不同的回调逻辑,Spring通过这种方式在Bean生命周期的过程中,有着很强的拓展性。
这次需要处理的是SmartInstantiationAwareBeanPostProcessor ==getEarlyBeanReference()方法
老规矩 先看注释
核心大意是 :让Bean提前暴露出去,以便尽早访问指定的bean,通常用于解析循环引用

在SmartInstantiationAwareBeanPostProcessor的实现类AnnotationAwareAspectJAutoProxyCreator
中调用了AbstractAutoProxyCreator 的getEarlyBeanReference();
来跟我念一下
AbstractAutoProxyCreator,wrapIfNecessary()
AbstractAutoProxyCreator,wrapIfNecessary()
== AbstractAutoProxyCreator,wrapIfNecessary()

这不就是我们强调的Spring动态代理的核心逻辑吗
也就是在这里我们获得了当前Bean的Cglib代理类

东老师:哦吼,详细说说这块逻辑
我:滚,再v50
东老师:当我没说

wrapIfNecessary这里的逻辑本文不过多讨论,因为我写不完。

这个引用就是通过Spring的AbstractAutoProxyCreator给当前Bean创建一个动态代理
那么回到第二个问题
这个代理什么时候放进去的呢

东老师听到这,瞬间羞涩:你好坏,什么进去不进去的
我大怒:滚

我们回到当前Bean的创建过程中,注意我说的不是作为属性需要注入的Bean,
而是我们Bean第一次初始化的过程中 AbstractAutowireCapableBeanFactory 的doCreateBean()方法


如上图,在当前Bean的填充属性及初始化之前,我们将这个懒加载的函数放进了三级缓存中。
然后就是我们上面讨论的流程

  1. 填充属性
  2. 依赖注入
  3. 从三级缓存中获取要注入Bean的实例(实际是这个懒加载函数)
  4. 执行懒加载的函数:AbstractAutoProxyCreator创建代理类后
  5. 注入获取到的代理类

最终在当前Bean初始化阶段initializeBean()执行int方法时
可以拿到注入的代理类,从而可以顺利执行

((TestPostConstructServiceImpl)AopContext.currentProxy()).save();

结语

东老师心花怒放:浪啊你真棒
我:滚,送你张图吧 东老师 好好学习,小心脱下长衫,黄袍加身,美团小哥欢迎你

如果你看完了这篇文章,恭喜你又get了一些没什么diao用的知识点

发布评论

评论列表 (0)

  1. 暂无评论