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)被调用。