赞
踩
包括创建和销毁,实现方式分别有三种:
A1:使用@PostConstruct和@PreDestory
在相应的类中写初始化和销毁方法,加@PostConstruct和@PreDestory注解:
写个测试类:
A2:实现InitializingBean和DisposableBean接口
A3:使用init-method和destroy-method方法
注意这时候不适用于@Component,而是@Bean和xml:
最后,关于这三种方式的执行顺序,同时保留三种初始化和销毁的代码,可以看到:
答案:
<bean/>
配置完各项Bean的信息循环依赖问题才会体现出纯净态的作用
)答案:
Bean的生命周期,指的就是Bean从创建到销毁的整个过程,主要有四大步:
STEP1
:实例化
STEP2
:属性赋值
STEP3
:初始化
STEP4
:销毁
如上图,实例化完BeanA,要属性注入了,此时发现需要依赖Bean B,在IoC容器中找Bean B,没找到,开始创建Bean B,实例化完做DI发现需要Bean A,结果在IoC中没找到Bean A,于是就开始重复上面的这个流程,形成死循环。
答案:
Spring是采用三级缓存来解决循环依赖的,三级缓存分别是三个Map
:
此时B里的A就已经赋值完成了,虽然是个半成品的A(就好比算命的说这个人未来是你对象,人就是这个人,哪怕ta现在还未成年)
到此,循环被打破,B被存储到一级缓存,addSingleton(B)
,并remove二级三级缓存
关于三级缓存:
ps:为什么不在实例化A后直接放进一级缓存的Map中去?
--------
- 因为此时A尚未创建完整,所有属性都是默认值,并不是一个完整的对象
- 如果直接扔进一级缓存,在执行业务时可能会抛出未知的异常
相关问题:
Q4.1、二级缓存能不能解决循环依赖?
Q4.2、Spring有没有解决多例Bean的循环依赖?
不会使用缓存进行存储,因为每次使用都会重新创建
不缓存早期形态的对象,就无法解决循环问题
(需要一个缓存保存早期形态的对象,来做为死循环的出口打破循环)Q4.3、Spring有没有解决构造函数参数Bean的循环依赖?
问题分析:
不完整的Bean,即只是完成了实例化,没有完成属性赋值(DI)和初始化(生命周期回调)。其次,并发下,假如有两个线程,都来getBean:
线程1以微小优势先来创建bean,实例化后放进三级缓存,此时,没有属性赋值和初始化,线程2进来getBean,getSinfleton去三个缓存中找,就拿到了不完整的Bean。
答案:
双重检查锁,2个同步锁,2次检查一级缓存
。
getBean(A) -> doGetBean(A) -> getSingleton(A,boolean)
连问:为什么不给一级缓存加锁,一次缓存要是加锁,则直接阻塞在一级缓存等待结果,也不用二次检查了。
答案:
因为性能,加入线程2除了获取Bean A还获取Bean C,而Bean C已经创建好了,存在于一级缓存,如此就会导致已经创建好的Bean阻塞等待。
BeanDefinition:用来存放(定义)Bean的生产信息,决定Bean如何进行生产(定义态的Bean)
答案:
回顾下之前的这张图:
重点就在BeanDefinition后置处理器这里:
创建Spring上下文对象(IoC容器时),源码中调用refresh方法,这个方法内部就调用了invokeBeanFactroyPostProcessors,去注册所有的BeanDefinition:
而接下来就会调用图中的BeanFactoryPostProcessor,就是修改BeanDefinition的时机,所以我们只需实现这个BeanFactoryPostProcessor接口即可,Spring就会去调用:
答案:
实现Bean工厂后置处理器接口BeanFactoryPostProcessor,即可在所有的BeanDefinition注册完成后做扩展
。
写个测试程序:
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。