java-12:spring MVC - 控制反转IOC，依赖注入DI

学习spring框架之前，先理解几个概念：

1.第一部分：依赖倒置原则

2.第二部分：控制反转，控制反转容器（实例）

3.第三部分：控制反转，控制反转容器（全面理解，面试题）

综合性理解：控制反转（IOC）个人理解就是：真正的控制方不是上层类或者下层类，而是框架，也就是控制反转容器（即中央处理器），由框架根据配置文件提供各下层类实例，通过依赖注入的方式提供给上层类的注入点的接口或者抽象类。

说明：以下三篇文章都是来自知乎，同一个问题的三个回答。地址：https://www.zhihu.com/question/23277575

-----------------------------------------------------------------------------------------------------------------------------------------------------------

第一部分：依赖倒置原则。个人认为：仅用此文来理解依赖倒置原则，不要用来理解IOC和DI，否则容易混淆IOC和DI的理解。

文章来自知乎，作者和地址如下。此文系统性说明了依赖倒置原则。个人觉得没有将IOC和DI说得很透彻。另外，依赖倒置原则一定是依赖接口和抽象，而不是具体的类。所以上层中定义的下层类一定是接口或者抽象父类。

说明1：依赖倒置原则
a.高层模块不应该依赖于底层模块，二者都应该依赖于抽象。
b.抽象不应该依赖于细节，细节应该依赖于抽象。

说明2：IoC主要的实现方式有两种：依赖查找，依赖注入。(128页)
依赖注入是一种更可取的方式。

--以下是博文：

作者：Mingqi
链接：https://www.zhihu.com/question/23277575/answer/169698662
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

要了解控制反转( Inversion of Control ), 我觉得有必要先了解软件设计的一个重要思想：依赖倒置原则（Dependency Inversion Principle ）。

什么是依赖倒置原则？假设我们设计一辆汽车：先设计轮子，然后根据轮子大小设计底盘，接着根据底盘设计车身，最后根据车身设计好整个汽车。这里就出现了一个“依赖”关系：汽车依赖车身，车身依赖底盘，底盘依赖轮子。

这样的设计看起来没问题，但是可维护性却很低。假设设计完工之后，上司却突然说根据市场需求的变动，要我们把车子的轮子设计都改大一码。这下我们就蛋疼了：因为我们是根据轮子的尺寸设计的底盘，轮子的尺寸一改，底盘的设计就得修改；同样因为我们是根据底盘设计的车身，那么车身也得改，同理汽车设计也得改——整个设计几乎都得改！

我们现在换一种思路。我们先设计汽车的大概样子，然后根据汽车的样子来设计车身，根据车身来设计底盘，最后根据底盘来设计轮子。这时候，依赖关系就倒置过来了：轮子依赖底盘，底盘依赖车身，车身依赖汽车。

这时候，上司再说要改动轮子的设计，我们就只需要改动轮子的设计，而不需要动底盘，车身，汽车的设计了。

这就是依赖倒置原则——把原本的高层建筑依赖底层建筑“倒置”过来，变成底层建筑依赖高层建筑。高层建筑决定需要什么，底层去实现这样的需求，但是高层并不用管底层是怎么实现的。这样就不会出现前面的“牵一发动全身”的情况。

控制反转（Inversion of Control） 就是依赖倒置原则的一种代码设计的思路。具体采用的方法就是所谓的依赖注入（Dependency Injection）。其实这些概念初次接触都会感到云里雾里的。说穿了，这几种概念的关系大概如下：

为了理解这几个概念，我们还是用上面汽车的例子。只不过这次换成代码。我们先定义四个Class，车，车身，底盘，轮胎。然后初始化这辆车，最后跑这辆车。代码结构如下：

这样，就相当于上面第一个例子，上层建筑依赖下层建筑——每一个类的构造函数都直接调用了底层代码的构造函数。假设我们需要改动一下轮胎（Tire）类，把它的尺寸变成动态的，而不是一直都是30。我们需要这样改：

由于我们修改了轮胎的定义，为了让整个程序正常运行，我们需要做以下改动：

由此我们可以看到，仅仅是为了修改轮胎的构造函数，这种设计却需要修改整个上层所有类的构造函数！在软件工程中，这样的设计几乎是不可维护的——在实际工程项目中，有的类可能会是几千个类的底层，如果每次修改这个类，我们都要修改所有以它作为依赖的类，那软件的维护成本就太高了。

所以我们需要进行控制反转（IoC），及上层控制下层，而不是下层控制着上层。我们用依赖注入（Dependency Injection）这种方式来实现控制反转。所谓依赖注入，就是把底层类作为参数传入上层类，实现上层类对下层类的“控制”。（转载者：依赖注入是依赖控制反转容器来对上层对象进行注入。）这里我们用构造方法传递的依赖注入方式重新写车类的定义：

这里我们再把轮胎尺寸变成动态的，同样为了让整个系统顺利运行，我们需要做如下修改：

看到没？这里我只需要修改轮胎类就行了，不用修改其他任何上层类。这显然是更容易维护的代码。不仅如此，在实际的工程中，这种设计模式还有利于不同组的协同合作和单元测试：比如开发这四个类的分别是四个不同的组，那么只要定义好了接口，四个不同的组可以同时进行开发而不相互受限制；而对于单元测试，如果我们要写Car类的单元测试，就只需要Mock一下Framework类传入Car就行了，而不用把Framework, Bottom, Tire全部new一遍再来构造Car。

这里我们是采用的构造函数传入的方式进行的依赖注入。其实还有另外两种方法：Setter传递和接口传递。这里就不多讲了，核心思路都是一样的，都是为了实现控制反转。

看到这里你应该能理解什么控制反转和依赖注入了。那什么是控制反转容器(IoC Container)呢？其实上面的例子中，对车类进行初始化的那段代码发生的地方，就是控制反转容器。

显然你也应该观察到了，因为采用了依赖注入，在初始化的过程中就不可避免的会写大量的new。这里IoC容器就解决了这个问题。这个容器可以自动对你的代码进行初始化，你只需要维护一个Configuration（可以是xml可以是一段代码），而不用每次初始化一辆车都要亲手去写那一大段初始化的代码。这是引入IoC Container的第一个好处。

IoC Container的第二个好处是：我们在创建实例的时候不需要了解其中的细节。在上面的例子中，我们自己手动创建一个车instance时候，是从底层往上层new的：

这个过程中，我们需要了解整个Car/Framework/Bottom/Tire类构造函数是怎么定义的，才能一步一步new/注入。

而IoC Container在进行这个工作的时候是反过来的，它先从最上层开始往下找依赖关系，到达最底层之后再往上一步一步new（有点像深度优先遍历）：

这里IoC Container可以直接隐藏具体的创建实例的细节，在我们来看它就像一个工厂：

我们就像是工厂的客户。我们只需要向工厂请求一个Car实例，然后它就给我们按照Config创建了一个Car实例。我们完全不用管这个Car实例是怎么一步一步被创建出来。

实际项目中，有的Service Class可能是十年前写的，有几百个类作为它的底层。假设我们新写的一个API需要实例化这个Service，我们总不可能回头去搞清楚这几百个类的构造函数吧？IoC Container的这个特性就很完美的解决了这类问题——因为这个架构要求你在写class的时候需要写相应的Config文件，所以你要初始化很久以前的Service类的时候，前人都已经写好了Config文件，你直接在需要用的地方注入这个Service就可以了。这大大增加了项目的可维护性且降低了开发难度。

这里只是很粗略的讲了一下我自己对IoC和DI的理解。主要的目的是在于最大限度避免晦涩难懂的专业词汇，用尽量简洁，通俗，直观的例子来解释这些概念。如果让大家能有一个类似“哦！原来就是这么个玩意嘛！”的印象，我觉得就OK了。想要深入了解的话，可以上网查阅一些更权威的资料。这里推荐一下 Dependency injection 和 Inversion of Control Containers and the Dependency Injection pattern 这两篇文章，讲的很好很详细。

------------------------------------------------------------------------------

第二部分：控制反转，控制反转容器

控制反转（IOC）个人理解就是：真正的控制方不是上层类或者下层类，而是框架，也就是控制反转容器（即中央处理器），由框架根据配置文件提供各下层类实例，通过依赖注入的方式提供给上层类的注入点的接口或者抽象类。

--以下是博文：

作者：知乎用户
链接：https://www.zhihu.com/question/23277575/answer/24259844
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

私以为以上各位都没有对spring ioc的精髓讲解到位。大多都在很模糊的说是什么，抽象化的表述或者含糊其辞的说概念。

ioc的思想最核心的地方在于，资源不由使用资源的双方管理，而由不使用资源的第三方管理（转载者：比如框架），这可以带来很多好处。第一，资源集中管理，实现资源的可配置和易管理。第二，降低了使用资源双方的依赖程度，也就是我们说的耦合度。

也就是说，甲方要达成某种目的不需要直接依赖乙方，它只需要达到的目的告诉第三方机构就可以了，比如甲方需要一双袜子，而乙方它卖一双袜子，它要把袜子卖出去，并不需要自己去直接找到一个卖家来完成袜子的卖出。它也只需要找第三方，告诉别人我要卖一双袜子。这下好了，甲乙双方进行交易活动，都不需要自己直接去找卖家，相当于程序内部开放接口，卖家由第三方作为参数传入。甲乙互相不依赖，而且只有在进行交易活动的时候，甲才和乙产生联系。反之亦然。这样做什么好处么呢，甲乙可以在对方不真实存在的情况下独立存在，而且保证不交易时候无联系，想交易的时候可以很容易的产生联系。甲乙交易活动不需要双方见面，避免了双方的互不信任造成交易失败的问题。因为交易由第三方来负责联系，而且甲乙都认为第三方可靠。那么交易就能很可靠很灵活的产生和进行了。

这就是ioc的核心思想。生活中这种例子比比皆是，支付宝在整个淘宝体系里就是庞大的ioc容器，交易双方之外的第三方，提供可靠性可依赖可灵活变更交易方的资源管理中心。另外人事代理也是，雇佣机构和个人之外的第三方。嗯，就这样，希望对题主有帮助。

==update===
在以上的描述中，诞生了两个专业词汇，依赖注入和控制反转
所谓的依赖注入，则是，甲方开放接口，在它需要的时候，能够讲乙方传递进来(注入)
所谓的控制反转，甲乙双方不相互依赖，交易活动的进行不依赖于甲乙任何一方，整个活动的进行由第三方负责管理。

这就是spring IOC的思想所在，不要只谈DI IOC这些概念。

人之所恶在好为人师,不实知，谨慎言。

----------------------------------------------------------------------------------------

3.第三部分：控制反转，控制反转容器。一个全面的理解，一针见血。还有亮点是包含面试题。

作者：Java3y
链接：https://www.zhihu.com/question/23277575/answer/680699595
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

在刷Spring书籍的时候花了点时间去学习了单例模式和工厂模式，总的来说还是非常值得的！

本来想的是刷完《Spring 实战 (第4版)》和《精通Spring4.x 企业应用开发实战》的IOC章节后来重新编写一篇IOC的文章的，看了一下之前已经写过的入门系列Spring入门这一篇就够了和Spring【依赖注入】就是这么简单。最主要的知识点都已经讲过了，所以感觉就没必要重新来编写这些知识点了...

我个人又不喜欢将写过的东西复制到新的文章中，所以建议大家可以先去阅读上面两篇文章再来看这篇(工厂模式那篇如果没有看过的同学也有必要去看看)~~

为了这篇文章知识点的完整性，重要的知识点(IOC概念理解，创建Bean、注入的三种方式等)还是会出现，但是不会将上面两篇博文的代码摘抄过来了。

这篇文章主要是补充和强化一些比较重要的知识点，并会把上面的两本书关于IOC的知识点整理出来并画成一个思维导图来全面了解Spring IOC的知识点！

那么接下来就开始吧，如果有错的地方希望能多多包涵，并不吝在评论区指正！

一、Spring IOC全面认知

结合《Spring 实战 (第4版)》和《精通Spring4.x 企业应用开发实战》两本书的IOC章节将其知识点整理起来~

1.1IOC和DI概述

在《精通Spring4.x 企业应用开发实战》中对IOC的定义是这样的：

IoC(Inversion of Control)控制反转，包含了两个方面：一、控制。二、反转

我们可以简单认为：

控制指的是：当前对象对内部成员的控制权。
反转指的是：这种控制权不由当前对象管理了，由其他(类,第三方容器)来管理。

IOC不够开门见山，于是Martin Fowler提出了DI(dependency injection)来替代IoC，即让调用类对某一接口实现类的依赖关系由第三方(容器或协作类)注入，以移除调用类对某一接口实现类的依赖。

在《Spring 实战 (第4版)》中并没有提及到IOC，而是直接来说DI的：

通过DI，对象的依赖关系将由系统中负责协调各对象的第三方组件在创建对象的时候进行设定，对象无需自行创建或管理它们的依赖关系，依赖关系将被自动注入到需要它们的对象当中去

从书上我们也可以发现：IoC和DI的定义(区别)并不是如此容易就可以说得清楚的了。这里我就简单摘抄一下：

IoC(思想，设计模式)主要的实现方式有两种：依赖查找，依赖注入。
依赖注入是一种更可取的方式(实现的方式)

对我们而言，其实也没必要分得那么清，混合一谈也不影响我们的理解...

再通过昨天写过的工厂模式理解了没有？，我们现在就可以很清楚的发现，其实所谓的IOC容器就是一个大工厂【第三方容器】(Spring实现的功能很强大！比我们自己手写的工厂要好很多)。

使用IOC的好处(知乎@Intopass的回答)：

不用自己组装，拿来就用。
享受单例的好处，效率高，不浪费空间。
便于单元测试，方便切换mock组件。
便于进行AOP操作，对于使用者是透明的。
统一配置，便于修改。

参考资料：

www.zhihu.com/question/23…--Spring IoC有什么好处呢？

1.2IOC容器的原理

从上面就已经说了：IOC容器其实就是一个大工厂，它用来管理我们所有的对象以及依赖关系。

原理就是通过Java的反射技术来实现的！通过反射我们可以获取类的所有信息(成员变量、类名等等等)！
再通过配置文件(xml)或者注解来描述类与类之间的关系
我们就可以通过这些配置信息和反射技术来构建出对应的对象和依赖关系了！

上面描述的技术只要学过点Java的都能说出来，这一下子可能就会被面试官问倒了，我们简单来看看实际Spring IOC容器是怎么实现对象的创建和依赖的：

根据Bean配置信息在容器内部创建Bean定义注册表
根据注册表加载、实例化bean、建立Bean与Bean之间的依赖关系
将这些准备就绪的Bean放到Map缓存池中，等待应用程序调用

Spring容器(Bean工厂)可简单分成两种：

BeanFactory
- 这是最基础、面向Spring的
ApplicationContext
- 这是在BeanFactory基础之上，面向使用Spring框架的开发者。提供了一系列的功能！

几乎所有的应用场合都是使用ApplicationContext！

BeanFactory的继承体系：

ApplicationContext的继承体系：

其中在ApplicationContext子类中又有一个比较重要的：WebApplicationContext

专门为Web应用准备的

Web应用与Spring融合：

我们看看BeanFactory的生命周期：

接下来我们再看看ApplicationContext的生命周期：

初始化的过程都是比较长，我们可以分类来对其进行解析：

Bean自身的方法：如调用 Bean 构造函数实例化 Bean，调用 Setter 设置 Bean 的属性值以及通过的 init-method 和 destroy-method 所指定的方法；
Bean级生命周期接口方法：如 BeanNameAware、 BeanFactoryAware、 InitializingBean 和 DisposableBean，这些接口方法由 Bean 类直接实现；
容器级生命周期接口方法：在上图中带“★” 的步骤是由 InstantiationAwareBean PostProcessor 和 BeanPostProcessor 这两个接口实现，一般称它们的实现类为“ 后处理器” 。后处理器接口一般不由 Bean 本身实现，它们独立于 Bean，实现类以容器附加装置的形式注册到Spring容器中并通过接口反射为Spring容器预先识别。当Spring 容器创建任何 Bean 的时候，这些后处理器都会发生作用，所以这些后处理器的影响是全局性的。当然，用户可以通过合理地编写后处理器，让其仅对感兴趣Bean 进行加工处理

ApplicationContext和BeanFactory不同之处在于：

ApplicationContext会利用Java反射机制自动识别出配置文件中定义的BeanPostProcessor、 InstantiationAwareBeanPostProcesso 和BeanFactoryPostProcessor后置器，并自动将它们注册到应用上下文中。而BeanFactory需要在代码中通过手工调用addBeanPostProcessor()方法进行注册
ApplicationContext在初始化应用上下文的时候就实例化所有单实例的Bean。而BeanFactory在初始化容器的时候并未实例化Bean，直到第一次访问某个Bean时才实例化目标Bean。

有了上面的知识点了，我们再来详细地看看Bean的初始化过程：

简要总结：

BeanDefinitionReader读取Resource所指向的配置文件资源，然后解析配置文件。配置文件中每一个<bean>解析成一个BeanDefinition对象，并保存到BeanDefinitionRegistry中；
容器扫描BeanDefinitionRegistry中的BeanDefinition；调用InstantiationStrategy进行Bean实例化的工作；使用BeanWrapper完成Bean属性的设置工作；
单例Bean缓存池：Spring 在DefaultSingletonBeanRegistry类中提供了一个用于缓存单实例 Bean 的缓存器，它是一个用HashMap实现的缓存器，单实例的Bean以beanName为键保存在这个HashMap中。

1.3IOC容器装配Bean

1.3.1装配Bean方式

Spring4.x开始IOC容器装配Bean有4种方式：

XML配置
注解
JavaConfig
基于Groovy DSL配置(这种很少见)

总的来说：我们以XML配置+注解来装配Bean得多，其中注解这种方式占大部分！

1.3.2依赖注入方式

依赖注入的方式有3种方式：

属性注入-->通过setter()方法注入
构造函数注入
工厂方法注入

总的来说使用属性注入是比较灵活和方便的，这是大多数人的选择！

1.3.3对象之间关系

<bean>对象之间有三种关系：

依赖-->挺少用的(使用depends-on就是依赖关系了-->前置依赖【依赖的Bean需要初始化之后，当前Bean才会初始化】)
继承-->可能会用到(指定abstract和parent来实现继承关系)
引用-->最常见(使用ref就是引用关系了)

1.3.4Bean的作用域

Bean的作用域：

单例Singleton
多例prototype
与Web应用环境相关的Bean作用域
- reqeust
- session

使用到了Web应用环境相关的Bean作用域的话，是需要我们手动配置代理的~

原因也很简单：因为我们默认的Bean是单例的，为了适配Web应用环境相关的Bean作用域--->每个request都需要一个对象，此时我们返回一个代理对象出去就可以完成我们的需求了！

将Bean配置单例的时候还有一个问题：

如果我们的Bean配置的是单例，而Bean对象里边的成员对象我们希望是多例的话。那怎么办呢？？
默认的情况下我们的Bean单例，返回的成员对象也默认是单例的(因为对象就只有那么一个)！

此时我们需要用到了lookup方法注入，使用也很简单，看看例子就明白了：

1.3.6处理自动装配的歧义性

昨天在刷书的时候刚好看到了有人在知乎邀请我回答这个问题：

结合两本书的知识点，可以归纳成两种解决方案：

使用@Primary注解设置为首选的注入Bean
使用@Qualifier注解设置特定名称的Bean来限定注入！
- 也可以使用自定义的注解来标识

1.3.7引用属性文件以及Bean属性

之前在写配置文件的时候都是直接将我们的数据库配置信息在里面写死的了：

其实我们有更优雅的做法：将这些配置信息写到配置文件上(因为这些配置信息很可能是会变的，而且有可能被多个配置文件引用).

如此一来，我们改的时候就十分方便了。

引用配置文件的数据使用的是${}

除了引用配置文件上的数据，我们还可以引用Bean的属性：

引用Bean的属性使用的是#{}

在这种技术在《Spring 实战第四版》称之为Spring EL，跟我们之前学过的EL表达式是类似的。主要的功能就是上面的那种，想要更深入了解可参考下面的链接：

www.cnblogs.com/leiOOlei/p/…

1.3.8组合配置文件

xml文件之间组合：

xml和javaconfig互相组合的方式：

public static void main(String[] args) {//1.通过构造函数加载配置类ApplicationContext ctx = new AnnotationConfigApplicationContext(AppConf.class);//2.通过编码方式注册配置类AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();ctx.register(DaoConfig.class);ctx.register(ServiceConfig.class);ctx.refresh();//3.通过XML组装@Configuration配置类所提供的配置信息ApplicationContext ctx = new ClassPathXmlApplicationContext("com/smart/conf/beans2.xml");//4.通过@Configuration组装XML配置所提供的配置信息ApplicationContext ctx = new AnnotationConfigApplicationContext(LogonAppConfig.class);//5.@Configuration的配置类相互引用ApplicationContext ctx = new AnnotationConfigApplicationContext(DaoConfig.class,ServiceConfig.class);LogonService logonService = ctx.getBean(LogonService.class);System.out.println((logonService.getLogDao() !=null));logonService.printHelllo();   }

第一种的例子：

第二种的例子：

第三种的例子：

第四种的例子：

第五种的例子：

代码由上可见

1.3.9装配Bean总结

总的来说，Spring IOC容器就是在创建Bean的时候有很多的方式给了我们实现，其中也包括了很多关于Bean的配置~

对于Bean相关的注入教程代码和简化配置(p和c名称空间)我就不一一说明啦，你们去看Spring入门这一篇就够了和Spring【依赖注入】就是这么简单就行了。

总的对比图：

分别的应用场景：

至于一些小的知识点：

方法替换
- 使用某个Bean的方法替换成另一个Bean的方法
属性编辑器
- Spring可以对基本类型做转换就归结于属性编辑器的功劳！
国际化
- 使用不同语言(英语、中文)的操作系统去显式不同的语言
profile与条件化的Bean
- 满足了某个条件才初始化Bean，这可以方便切换生产环境和开发环境~
容器事件
- 类似于我们的Servlet的监听器，只不过它是在Spring中实现了~

上面这些小知识点比较少情况会用到，这也不去讲解啦。知道有这么一回事，到时候查查就会用啦~~~

二、Spring IOC相关面试题

将SpringIOC相关知识点整理了一遍，要想知道哪些知识点是比较重要的。很简单，我们去找找相关的面试题就知道了，如果该面试题是常见的，那么说明这个知识点还是相对比较重要的啦！

以下的面试题从各种博客上摘抄下来，摘抄量较大的会注明出处的~

2.1什么是spring?

什么是spring?

Spring 是个java企业级应用的开源开发框架。Spring主要用来开发Java应用，但是有些扩展是针对构建J2EE平台的web应用。Spring框架目标是简化Java企业级应用开发，并通过POJO为基础的编程模型促进良好的编程习惯。

2.2使用Spring框架的好处是什么？

使用Spring框架的好处是什么？

轻量：Spring 是轻量的，基本的版本大约2MB。
控制反转：Spring通过控制反转实现了松散耦合，对象们给出它们的依赖，而不是创建或查找依赖的对象们。
面向切面的编程(AOP)：Spring支持面向切面的编程，并且把应用业务逻辑和系统服务分开。
容器：Spring 包含并管理应用中对象的生命周期和配置。
MVC框架：Spring的WEB框架是个精心设计的框架，是Web框架的一个很好的替代品。
事务管理：Spring 提供一个持续的事务管理接口，可以扩展到上至本地事务下至全局事务（JTA）。
异常处理：Spring 提供方便的API把具体技术相关的异常（比如由JDBC，Hibernate or JDO抛出的）转化为一致的unchecked 异常。

2.3Spring由哪些模块组成?

Spring由哪些模块组成?

简单可以分成6大模块：

Core
AOP
ORM
DAO
Web
Spring EE

2.4BeanFactory 实现举例

BeanFactory 实现举例

Bean工厂是工厂模式的一个实现，提供了控制反转功能，用来把应用的配置和依赖从正真的应用代码中分离。

在spring3.2之前最常用的是XmlBeanFactory的，但现在被废弃了，取而代之的是：XmlBeanDefinitionReader和DefaultListableBeanFactory

2.5什么是Spring的依赖注入？

什么是Spring的依赖注入？

依赖注入，是IOC的一个方面，是个通常的概念，它有多种解释。这概念是说你不用创建对象，而只需要描述它如何被创建。你不在代码里直接组装你的组件和服务，但是要在配置文件里描述哪些组件需要哪些服务，之后一个容器（IOC容器）负责把他们组装起来。

2.6有哪些不同类型的IOC（依赖注入）方式？

有哪些不同类型的IOC（依赖注入）方式？

构造器依赖注入：构造器依赖注入通过容器触发一个类的构造器来实现的，该类有一系列参数，每个参数代表一个对其他类的依赖。
Setter方法注入：Setter方法注入是容器通过调用无参构造器或无参static工厂方法实例化bean之后，调用该bean的setter方法，即实现了基于setter的依赖注入。
工厂注入：这个是遗留下来的，很少用的了！

2.7哪种依赖注入方式你建议使用，构造器注入，还是 Setter方法注入？

哪种依赖注入方式你建议使用，构造器注入，还是 Setter方法注入？

你两种依赖方式都可以使用，构造器注入和Setter方法注入。最好的解决方案是用构造器参数实现强制依赖，setter方法实现可选依赖。

2.8什么是Spring beans?

什么是Spring beans?

Spring beans 是那些形成Spring应用的主干的java对象。它们被Spring IOC容器初始化，装配，和管理。这些beans通过容器中配置的元数据创建。比如，以XML文件中<bean/>的形式定义。

这里有四种重要的方法给Spring容器提供配置元数据。

XML配置文件。
基于注解的配置。
基于java的配置。
Groovy DSL配置

2.9解释Spring框架中bean的生命周期

解释Spring框架中bean的生命周期

Spring容器从XML 文件中读取bean的定义，并实例化bean。
Spring根据bean的定义填充所有的属性。
如果bean实现了BeanNameAware 接口，Spring 传递bean 的ID 到 setBeanName方法。
如果Bean 实现了 BeanFactoryAware 接口， Spring传递beanfactory 给setBeanFactory 方法。
如果有任何与bean相关联的BeanPostProcessors，Spring会在postProcesserBeforeInitialization()方法内调用它们。
如果bean实现IntializingBean了，调用它的afterPropertySet方法，如果bean声明了初始化方法，调用此初始化方法。
如果有BeanPostProcessors 和bean 关联，这些bean的postProcessAfterInitialization() 方法将被调用。
如果bean实现了 DisposableBean，它将调用destroy()方法。

2.10解释不同方式的自动装配

解释不同方式的自动装配

no：默认的方式是不进行自动装配，通过显式设置ref 属性来进行装配。
byName：通过参数名自动装配，Spring容器在配置文件中发现bean的autowire属性被设置成byname，之后容器试图匹配、装配和该bean的属性具有相同名字的bean。
byType:：通过参数类型自动装配，Spring容器在配置文件中发现bean的autowire属性被设置成byType，之后容器试图匹配、装配和该bean的属性具有相同类型的bean。如果有多个bean符合条件，则抛出错误。
constructor：这个方式类似于byType，但是要提供给构造器参数，如果没有确定的带参数的构造器参数类型，将会抛出异常。
autodetect：首先尝试使用constructor来自动装配，如果无法工作，则使用byType方式。

只用注解的方式时，注解默认是使用byType的！

2.11IOC的优点是什么？

IOC的优点是什么？

IOC 或依赖注入把应用的代码量降到最低。它使应用容易测试，单元测试不再需要单例和JNDI查找机制。最小的代价和最小的侵入性使松散耦合得以实现。IOC容器支持加载服务时的饿汉式初始化和懒加载。

2.12哪些是重要的bean生命周期方法？你能重载它们吗？

哪些是重要的bean生命周期方法？你能重载它们吗？

有两个重要的bean 生命周期方法，第一个是setup，它是在容器加载bean的时候被调用。第二个方法是 teardown它是在容器卸载类的时候被调用。

The bean 标签有两个重要的属性（init-method和destroy-method）。用它们你可以自己定制初始化和注销方法。它们也有相应的注解（@PostConstruct和@PreDestroy）。

2.13怎么回答面试官：你对Spring的理解？

怎么回答面试官：你对Spring的理解？

来源：

www.zhihu.com/question/48…

下面我就截几个答案：

一、

二、

2.14Spring框架中的单例Beans是线程安全的么？

Spring框架中的单例Beans是线程安全的么？

Spring框架并没有对单例bean进行任何多线程的封装处理。关于单例bean的线程安全和并发问题需要开发者自行去搞定。但实际上，大部分的Spring bean并没有可变的状态(比如Serview类和DAO类)，所以在某种程度上说Spring的单例bean是线程安全的。如果你的bean有多种状态的话（比如 View Model 对象），就需要自行保证线程安全。

最浅显的解决办法就是将多态bean的作用域由“singleton”变更为“prototype”

2.15FileSystemResource和ClassPathResource有何区别？

FileSystemResource和ClassPathResource有何区别？

在FileSystemResource 中需要给出spring-config.xml文件在你项目中的相对路径或者绝对路径。在ClassPathResource中spring会在ClassPath中自动搜寻配置文件，所以要把ClassPathResource文件放在ClassPath下。

如果将spring-config.xml保存在了src文件夹下的话，只需给出配置文件的名称即可，因为src文件夹是默认。

简而言之，ClassPathResource在环境变量中读取配置文件，FileSystemResource在配置文件中读取配置文件。

三、总结

这篇文章的主要知识点我画了一张思维导图来总结啦，当学习到AOP的时候，这张思维导图会继续补充的哦~~~

http://weixin.qq.com/r/uDgqMjPEOW5GrXdR922q123 (二维码自动识别)

参考资料：

《Spring 实战》
《精通Spring4.x 企业应用开发实战》
zhuanlan.zhihu.com/p/29344811--Spring IOC原理总结
blog.csdn.net/u014079773/…---Java面试题集（七）--Spring常见面试问题
zhuanlan.zhihu.com/p/31527327--69 个经典 Spring 面试题和答案

文章首发公众号：Java3y 号内有海量的视频资源和原创的思维导图，关注即可获取！