Spring之IOC

IoC（Inverse of Control:控制反转）是一种设计思想，就是 将原本在程序中手动创建对象的控制权，交由Spring框架来管理。 IoC 在其他语言中也有应用，并非 Spirng 特有。 IoC 容器是 Spring 用来实现 IoC 的载体， IoC 容器实际上就是个Map（key，value）,Map 中存放的是各种对象

使用 ApplicationContext，它是 BeanFactory 的子类，更好的补充并实现了 BeanFactory ，BeanFactory可以理解为一个HashMap，key：bean name value：bean object，它只有get put两个功能，所以被称为低级容器，ApplicationContext 继承了多个接口，所以称为高级容器，可以从classpath 和 fileSystem 加载配置文件

何为控制，控制的是什么？

• 是bean的创建、管理的权利，控制bean的整个生命周期

何为反转，反转了什么？

• 把这个权利交给了 Spring 容器，而不是自己去控制，就是反转

何为依赖，依赖的是什么？

• 程序运行需要依赖外部的资源，提供程序内对象的所需要的数据、资源

何为注入，注入了什么？

• 配置文件把资源从外部注入到内部，容器加载了外部的文件、对象、数据，然后把这些资源注入给程序内的对象，维护了程序内外对象之间的依赖关系
• 对象在容器中默认是单例的
• 容器中的对象是启动容器的时候，就已经创建好了所有的对象，使用反射clazz.getDeclaredConstructor().newInstance() 创建

依赖注入的方式

• 手动注入
  • xml、注解配置元信息
• 自动注入
  • Autowiring

依赖注入的类型

• setter注入：
• 构造器注入：
• 接口注入：实现ApplicationContextAware接口
• 方法注入：@Autowired @Bean @Resource

自动装配模式

• no：(默认)无自动装配。Bean 引用必须由ref元素定义。对于大型部署，建议不要更改默认设置，因为明确指定协作者可以提供更好的控制和清晰度。在某种程度上，它记录了系统的结构
• byName：按属性名称自动布线。Spring 寻找与需要自动装配的属性同名的 bean。例如，如果一个 bean 定义被设置为按名称自动装配，并且包含一个master属性(即，它具有setMaster(..)方法)，那么 Spring 将查找一个名为master的 bean 定义并使用它来设置属性
• byType：如果容器中恰好存在一个该属性类型的 bean，则使该属性自动装配。如果存在多个错误，则会引发致命异常，这表明您可能不对该 bean 使用byType自动装配。如果没有匹配的 bean，则什么也不会发生(未设置该属性)
• constructor：类似于byType，但适用于构造函数参数。如果容器中不存在构造函数参数类型的一个 bean，则将引发致命错误

Spring 中的 bean 的作用域有哪些?

• singleton : 唯一 bean 实例，Spring 中的 bean 默认都是单例的。
• prototype : 每次请求都会创建一个新的 bean 实例。
• request : 每一次 HTTP 请求都会产生一个新的 bean，该 bean 仅在当前 HTTP request 内有效。
• session : 每一次 HTTP 请求都会产生一个新的 bean，该 bean 仅在当前 HTTP session 内有效。
• global-session： 全局 session 作用域，仅仅在基于 Portlet 的 web 应用中才有意义，Spring5 已经没有了。Portlet 是能够生成语义代码（例如：HTML）片段的小型 Java Web 插件。它们基于 portlet 容器，可以像 servlet 一样处理 HTTP 请求。但是，与 servlet 不同，每个 portlet 都有不同的会话。

Spring bean 的生命周期

对于 Spring Bean 的生命周期简单来说来说就包含以下四个步骤：

• 实例化 Instantiation
• 属性赋值 Populate
• 初始化 Initialization
• 销毁 Destruction

Spring Bean 生命周期流程图

看到一个拟人化的流程讲解，感觉很形象，来自后面参考的一篇博文

构造器注入和 Setter 注入有啥区别?更推荐什么方式？

• 在Setter注入,可以将依赖项部分注入,构造方法注入不能部分注入
• 使用setter注入不能保证类的所有的属性都注入进来
• 在类对象相互依赖的时候可以通过Setter方式解决循环依赖问题

怎么解决多个类型相同的bean注册到Spring容器的使用问题？

• @Qualifier注解来指定哪一个bean或者实现bean的逻辑分组

Spring 容器工厂分为两种：ApplicationContext、BeanFactory。异同点：

• 1. BeanFactory 在启动的时候不会去实例化 Bean，ApplicationContext 在启动的时候会。
• 2. BeanFacotry 是 spring 中比较原始的 Factory，无法支持 spring 的许多插件，如 AOP 功能、Web 应用等。 ApplicationContext 支持

IOC的优缺点

• 优点：
  • 对于单例的对象，不浪费空间
  • 降低组件之间的耦合度
  • 统一配置，便于管理修改
• 缺点：
  • 对象生成使用反射，在效率上有些损耗

Bean的生命周期感兴趣，可以看看​​AbstractApplicationContext​​​类里的​​refresh​​​方法，这个方法是AplicationContext容器初始化的关键点。在这个方法里，调用了​​finishBeanFactoryInitialization​​​方法，这个方法里调用了​​getBean​​​方法，​​getBean​​​方法里调用了​​AbstractBeanFactory​​​的​​getBean​​方法，最终经过一阵七拐八绕，到达了我们的目标——Bean创建的方法：​​doCreateBean​​​方法，在这个方法里可以看到Bean的实例化，赋值、初始化的过程，至于最终的销毁，可以看看​​ConfigurableApplicationContext#close()​​

 看到两个讲的特别好的文档，共勉，里面也有调用实现case，这里不做重复赘述

 一文读懂 Spring Bean 的生命周期

Spring Bean生命周期，好像人的一生