Spring依赖注入，带来的数据初始化问题

applicationContext.xml配置文件

1.举个例子：

初始化顺序:

1.先初始化AService

2.再初始化com.front.restful包下的service类

3.最后才初始化BService

xml里面配置的bean，和注解扫描的包中的bean，初始化的顺序，

是交叉依次执行的

拓展应用：

假如存在一个系统数据字典变量 jdbcUrl，默认是null值，它的初始化动作，交由com.front.restful包下的Rservice类进行初始化，而后续BService引用该数据字典变量 jdbcUrl 时,则能获取到非空值，从而进行业务操作。（静态变量，之所以用bean初始化，是因为有的就是需要读数据库，然后进行值初始化，而不是一个简单的常量，直接在代码里面写死，这个地方需要注意一下，在这也不进行这种初始化方式的评判，更多的是说明问题。。）

2.引入的bug：

有些service初始化时，不一定是按xml配置的bean依次执行，

举个例子:

初始化顺序

1.先初始化AService

2.依赖注入原因，直接初始化BService

3.再初始化com.front.restful包下的service类

比较：

xml里面配置的bean，和注解扫描的包中的bean，初始化的顺序，

已经不是按照xml配置的顺序执行了，这个时候就有可能引入bug。

拓展应用中的bug：

存在一个系统数据字典变量 jdbcUrl，默认是null值，它的初始化动作，没有先交由com.front.restful包下的Rservice类进行初始化，而是直接被后续BService，引用了该数据字典变量 jdbcUrl ,从而获取到了空值，最终影响了业务的正常逻辑操作。

结论：

1.这是一个比较难以发现的bug问题，如果现实开发中，如果一开始AService,没有依赖BService，则不会有jdbcUrl,初始化为空值的现象。

2.但是随着业务的增长，有可能AService需要对BService进行引用，这个时候就会突然出现jdbcUrl初始化为空值的问题，这个时候，在这个问题解决的进程中，开发人员花销的时间也因人而异，但无疑是痛苦的。

3.这是一种比较浅的引用关系，设想一下，如果xml配置如下：

那么由于业务的增长，AService需要对CService进行引用，从而造成了BService的提前初始化，进而影响了jdbcUrl的值初始化，这种问题的解决难度，无疑又往上增加。

而且随着xml的各种依赖注入层级增加，到最后，可能会发现不了问题代码，或者找到了问题代码，因为没有洞悉引用逻辑，也成为了一道无法解决的题，最终只能进行代码回退来解决。

解决：

这种问题，在现实开发中，是有可能能遇到的，如果把静态变量的初始化工作bean，直接放在xml定义的最前面，基本便能解决了。但是因为很多时候，我们没有注意到这个问题，便会带来不必要的麻烦。

如：

最后， 有则改之，无则加勉。