【常见面试问题总结文件夹>>>】
61、Spring IoC容器的依赖有两层含义：
Bean依赖容器：也就是说Bean要依赖于容器，这里的依赖是指容器负责创建Bean并管理Bean的生命周期，正是因为由容器来控制创建Bean并注入依赖，也就是控制权被反转了，这也正是IoC名字的由来，此处的有依赖是指Bean和容器之间的依赖关系。
容器注入Bean的依赖资源：容器负责注入Bean的依赖资源，依赖资源能够是Bean、外部文件、常量数据等，在Java中都反映为对象。而且由容器负责组装Bean之间的依赖关系，此处的依赖是指Bean之间的依赖关系。能够觉得是传统类与类之间的“关联”、“聚合”、“组合”关系。
62、为什么要应用依赖注入。应用依赖注入能给我们带来哪些优点呢？
动态替换Bean依赖对象，程序更灵活：替换Bean依赖对象，无需改动源文件：应用依赖注入后。因为能够採用配置文件方式实现，从而能随时动态的替换Bean的依赖对象，无需改动java源文件；
更好实践面向接口编程。代码更清晰：在Bean中仅仅需指定依赖对象的接口，接口定义依赖对象完毕的功能，通过容器注入依赖实现；
更好实践优先使用对象组合，而不是类继承：由于IoC容器採用注入依赖，也就是组合对象，从而更好的实践对象组合。
採用对象组合，Bean的功能可能由几个依赖Bean的功能组合而成，其Bean本身可能仅仅提供少许功能或根本无不论什么功能，所有托付给依赖Bean，对象组合具有动态性，能更方便的替换掉依赖Bean，从而改变Bean功能；
而假设採用类继承，Bean没有依赖Bean，而是採用继承方式加入新功能，，并且功能是在编译时就确定了，不具有动态性。并且採用类继承导致Bean与子Bean之间高度耦合，难以复用。
添加Bean可复用性：依赖于对象组合，Bean更可复用且复用更简单。
减少Bean之间耦合：因为我们全然採用面向接口编程，在代码中没有直接引用Bean依赖实现，所有引用接口，并且不会出现显示的创建依赖对象代码。并且这些依赖是由容器来注入，非常easy替换依赖实现类。从而减少Bean与依赖之间耦合；
代码结构更清晰：要应用依赖注入。代码结构要依照规约方式进行书写。从而更好的应用一些最佳实践，因此代码结构更清晰。
63、什么是循环依赖？
循环依赖就是循环引用，就是两个或多个Bean 相互之间的持有对方。比方CircleA 引用CircleB。CircleB 引用CircleC，CircleC 引用CircleA，则它们终于反映为一个环。
64、Spring怎样解决循环依赖
构造器循环依赖：表示通过构造器注入构成的循环依赖，此依赖是无法解决的，仅仅能抛出BeanCurrentlyInCreationException异常表示循环依赖。
setter循环依赖：表示通过setter注入方式构成的循环依赖。对于setter注入造成的依赖是通过Spring容器提前暴露刚完毕构造器注入但未完毕其它步骤（如setter注入）的Bean来完毕的，并且仅仅能解决单例作用域的Bean循环依赖。对于“prototype”作用域Bean，Spring容器无法完毕依赖注入。由于“prototype”作用域的Bean。Spring容器不进行缓存，因此无法提前暴露一个创建中的Bean。对于“singleton”作用域Bean。能够通过“setAllowCircularReferences(false);”来禁用循环引用。
65、延迟初始化Bean
延迟初始化也叫做惰性初始化，指不提前初始化Bean，而是仅仅有在真正使用时才创建及初始化Bean。
配置方式非常easy仅仅需在<bean>标签上指定 “lazy-init” 属性值为“true”就可以延迟初始化Bean。
Spring容器会在创建容器时提前初始化“singleton”作用域的Bean，“singleton”就是单例的意思即整个容器每一个Bean仅仅有一个实例，后边会具体介绍。Spring容器预先初始化Bean通常能帮助我们提前发现配置错误。所以假设没有什么情况建议开启，除非有某个Bean可能须要载入非常大资源，并且非常可能在整个应用程序生命周期中非常可能使用不到。能够设置为延迟初始化。
延迟初始化的Bean一般会在第一次使用时被初始化；或者在被非延迟初始化Bean作为依赖对象注入时在会随着初始化该Bean时被初始化，由于在这时使用了延迟初始化Bean。
容器管理初始化Bean消除了编程实现延迟初始化。全然由容器控制。仅仅需在须要延迟初始化的Bean定义上配置就可以，比编程方式更简单，并且是无侵入代码的。
66、使用depends-on
depends-on是指指定Bean初始化及销毁时的顺序，使用depends-on属性指定的Bean要先初始化完成后才初始化当前Bean，因为仅仅有“singleton”Bean能被Spring管理销毁。所以当指定的Bean都是“singleton”时，使用depends-on属性指定的Bean要在指定的Bean之后销毁。
“depends-on”有什么优点呢？主要是给出明白的初始化及销毁顺序。降低发生错误。
67、不是全部类型都能自己主动装配：
不能自己主动装配的数据类型：Object、基本数据类型（Date、CharSequence、Number、URI、URL、Class、int）等。
通过“<beans>”标签default-autowire-candidates属性指定的匹配模式，不匹配的将不能作为自己主动装配的候选者，比如指定“*Service，*Dao”。将仅仅把匹配这些模式的Bean作为候选者，而不匹配的不会作为候选者；
通过将“<bean>”标签的autowire-candidate属性可被设为false。从而该Bean将不会作为依赖注入的候选者。
68、数组、集合、字典类型的依据类型自己主动装配和普通类型的自己主动装配是有差别的
数组类型、集合（Set、Collection、List）接口类型：将依据泛型获取匹配的全部候选者并注入到数组或集合中，如“List<HelloApi> list”将选择全部的HelloApi类型Bean并注入到list中。而对于集合的详细类型将仅仅选择一个候选者，“如 ArrayList<HelloApi> list”将选择一个类型为ArrayList的Bean注入，而不是选择全部的HelloApi类型Bean进行注入；
字典（Map）接口类型：相同依据泛型信息注入，键必须为String类型的Bean名字，值依据泛型信息获取，如“Map<String, HelloApi>map” 将选择全部的HelloApi类型Bean并注入到map中，而对于详细字典类型如“HashMap<String,HelloApi> map”将仅仅选择类型为HashMap的Bean注入。而不是选择全部的HelloApi类型Bean进行注入。
69、自己主动装配的优点和坏处？
首先，自己主动装配确实降低了配置文件的量。其次，“byType”自己主动装配能在对应的Bean更改了字段类型时自己主动更新。即改动Bean类不须要改动配置。确实简单了。
自己主动装配也是有缺点的，最重要的缺点就是没有了配置，在查找注入错误时很麻烦，还有比方基本类型没法完毕自己主动装配。所以可能常常发生一些莫名其妙的错误，在此我推荐大家不要使用该方式，最好是指定明白的注入方式，或者採用最新的Java5+注解注入方式。所以大家在使用自己主动装配时应该考虑自己负责项目的复杂度来进行衡量是否选择自己主动装配方式。
70、自己主动装配注入方式能和配置注入方式一同工作吗？
当然能够。配置注入的数据会覆盖自己主动装配注入的数据。