Spring DI resolution process

DI解析过程
container执行bean的依赖注入步骤如下:
1.ApplicationContext被创建,根据描述bean的配置信息初始化。这些配置信息可能是xml,java代码,或者annotations;
2.对于每一个bean,它的依赖是通过property,constructor参数,或者static-factory方法的参数(如果你不想用普通的 constructor),这些依赖是在bean真正创建的时候提供给它的;
3.每一个property或者constructor参数都是常量值或者对其他bean的引用;
4.如果property或者constructor参数是个常量值,它会被根据描述的格式转换为真实的类型;Spring默认将一个String格式的值转换为内置的类型,比如int,long,String,boolean等等。

在容器创建的时候,容器会验证每个bean的配置信息。然而,这些bean的属性不会被设置,直到真正被创建。如果bean是singleton-scoped,或者被设置为预实例化(默认)会在容器创建的时候同时创建。否则bean只会在需要的时候被创建。bean的创建会引起一系列bean的创建,这是由于bean的依赖关系所决定的。注意依赖关系的解析错误不会立即显示。

你可以相信Spring总是正确的。它在加载container的时候检测配置错误,比如对不存在bean的引用或者循环引用。Spring尽可能晚地对bean设值和解析注入,直到bean真正被创建。这意味着即使在container被正确加载后,如果你请求的对象或者它的依赖存在问题, 你依然会得到一个异常。比如,这个bean抛出一个缺失或者非法property的异常。这种做法潜在的推迟了配置问题的可见性,这也就是为什么ApplicationContext的实现会默认预实例化singleton bean。以启动时间和内存的代价,在bean需要创建他们之前创建他们,你会在ApplicationContext创建的时候发现配置问题,而不是更晚。当然你可以重写默认的行为,使singleton延迟初始化,而不是预实例化;

当一个或者多个协作的bean一起注入同一个bean,协作的bean相互之间没有循环引用,所有协作的bean会比依赖的bean优先配置。这就是说,如果bean A对bean B 有依赖,Spring container就会先配置bean B, 然后再调用 bean A的设值方法。换句话说,一个bean(非预实例化singleton)的实例化需要所有的引用被设入,以及相关的生命周期方法(configured init method 或者 InitializingBean callback method)被调用。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值