说说你对Spring的IOC机制的理解可以吗？

如果没有springIOC的情况下，写一套系统：Tomcat+Servlet

其中调用impl的时候，通过new来创建对象(程序主动创建依赖)

每次都需要new一个，导致耦合度太高，如果后期变动、更换impl的时候，需要改动大量代码并且重新测试

IOC控制反转、依赖注入：

通过xml配置、自动注入的方式进行依赖注入（marven引入一些spring框架的依赖）

这时，当Tomcat启动时，会启动一个Spring容器，添加注解的类会交由Spring进行创建实例对象，包括对象与对象之间的引用。

将bean交给Spring容器进行管理--》控制反转

Spring容器

（1）实例化Bean

（2）注入Bean和Bean之间的依赖关系

底层是反射技术

好处：代码解耦，避免大量重复性修改、避免大量的测试，易于代码的维护

图1-1 传统应用程序示意图

当有了IoC/DI的容器后，在客户端类中不再主动去创建这些对象了，如图1-2所示:

图1-2有IoC/DI容器后程序结构示意图

谈谈对Spring IOC的理解（2015年的文章，通俗易懂）

【评论区】

1、IOC机制的由来和演化

（1）Tomcat最初的流程是接受http请求，然后封装后转发给我们自己写的Servlet，最后由我们手动创建实现类的对象去执行业务逻辑。弊端：耦合性太高。

（2）紧接着整个体系进行演化，Tomcat启动后会去启动一个Spring容器，由Spring将对应的bean进行创建于初始化，并且管理对应的依赖关系，这里的就是控制反转了，将类的调用关系由主动变成了被动，交给了Spring去管理。

（3）有了这个机制以后，就可以轻松的完成解耦，然后引入spring mvc其实就是由它实现了之前servlet的一些功能，处理包装请求，然后一些filter，最终转发到我们的controller，最终调用实现类完成业务逻辑。

（4）整个IOC容器就像是一个map，key是对应的名称，value是通过反射创建的bean。比较明显的作用就是解耦

2、注入的时候为什么不直接注入实现类而是注入接口?

（1）功能可扩展性：如果依赖注入实现类，将来代码就是死得了，注入接口更加灵活

（2）如果注入（DI）的是实现类的话，spring的AOP就会使用CGLIB动态代理，如果后续我们想对该实现类进行扩展和替换就会有问题；当注入的是接口的话，spring的aop默认使用JDK动态代理实现的，提高了实现类的扩展性和可替换

3、我们通过自动装配的注解@autowired 就可以找到这个接口对应的实现类，这个是怎么做到的，如果是多个实现类的呢？

多个可以在注入的时候加qualifier注解或者在你想注入的那个实现类加@primary ，注入的时候优先会找qualifier, 当然与@autowired注解有相同作用的是@resource 和@inject 这两个是Java提供的，@inject还需要导入包，一般还是建议使用@autowired注解

4、反射是什么？

JAVA反射机制是在运行状态中，对于任意一个类，都能够知道这个类的所有属性和方法；对于任意一个对象，都能够调用它的任意方法和属性；这种动态获取信息以及动态调用对象方法的功能称为java语言的反射机制。

用途

在日常的第三方应用开发过程中，经常会遇到某个类的某个成员变量、方法或是属性是私有的或是只对系统应用开放，这时候就可以利用Java的反射机制通过反射来获取所需的私有成员或是方法。当然，也不是所有的都适合反射，之前就遇到一个案例，通过反射得到的结果与预期不符。阅读源码发现，经过层层调用后在最终返回结果的地方对应用的权限进行了校验，对于没有权限的应用返回值是没有意义的缺省值，否则返回实际值起到保护用户的隐私目的。

详细见

https://www.jianshu.com/p/9be58ee20dee