关于java:Spring-IOC-原理

Spring IOC 原理

概念

Spring 启动时读取应用程序提供的 Bean 配置信息，并在 Spring 容器中生成一份相应的 Bean 配置注册表，而后依据这张注册表实例化 Bean，拆卸好 Bean 之间的依赖关系，为下层利用提供准备就绪的运行环境。其中 Bean 缓存池为 HashMap 实现。

IOC容器的实现参考上篇

IOC和依赖注入

Spring IoC容器负责对象的生命周期和对象之间的（依赖）关系。

在创立新的Bean时，IoC容器会主动注入新Bean的所依赖的其余Bean，而无须本人手动创立。

IoC容器主动实现对象的初始化，防止在开发过程中写一大段初始化代码。
创立实例的时候不须要理解细节。

长处：不会对业务代码形成很强的侵入性，对象具备更好的可测试性，可重用性和可拓展性。

IoC 全称为 InversionofControl，翻译为 “管制反转”.

谁管制谁：在传统的开发模式下，咱们都是采纳间接 new 一个对象的形式来创建对象，也就是说你依赖的对象间接由你本人管制，然而有了 IOC 容器后，则间接由 IoC 容器来管制。所以“谁管制谁”，当然是 IoC 容器管制对象。
管制什么：管制对象。
为何是反转：没有 IoC 的时候咱们都是在本人对象中被动去创立被依赖的对象，这是正转。然而有了 IoC 后，所依赖的对象间接由 IoC 容器创立后注入到被注入的对象中，依赖的对象由原来的被动获取变成被动承受，所以是反转。
哪些方面反转了：所依赖对象的获取被反转了。

“依赖注入”明确形容了“被注入对象依赖IoC容器配置依赖对象”。
了解DI的要害是：“谁依赖谁，为什么须要依赖，谁注入谁，注入了什么”，那咱们来深入分析一下：

谁依赖谁：“被注入的对象”依赖“依赖对象”。举个例子，对象A依赖B，那么IoC容器在注入A对象之前，须要先注入B对象；对象A依赖IoC容器；对象B被注入到对象A中，所以A是被注入的对象，B是依赖对象，A依赖B。
为什么须要依赖：容器治理对象须要IoC容器来提供对象须要的内部资源；
谁注入谁：很显著是IoC容器注入某个对象，也就是注入“依赖对象”；
注入了什么：就是注入某个对象所须要的内部资源（包含对象、资源、常量数据）。

二者的关系
管制反转（Inversion of Control）就是依赖倒置准则的一种代码设计的思路。具体采纳的办法就是所谓的依赖注入（Dependency Injection）。

Bean 作用域

Spring 中为 Bean 定义了 5 中作用域，别离为 singleton（单例）、 prototype（原型）、request、 session 和 global session， 5 种作用域阐明如下：

singleton：单例模式（多线程下不平安）
Spring IOC 容器中只会存在一个共享的Bean实例，无论有多少个Bean援用它，始终指向同一对象。该模式在多线程下是不平安的。singleton作用域是Spring中的缺省作用域，也能够显示的将Bean定义为singleton模式，配置为：

<bean id="userDao" class="com.ioc.UserDaoImpl" scope="singleton"/>

prototype:原型模式，每次应用时创立
每次通过Spring容器获取prototype定义的Bean时，容器都将创立一个新的Bean实例，每个Bean实例都有本人的属性和状态。依据教训， 对有状态的bean应用prototype作用域，而对无状态的bean应用singleton作用域。
request：一次 request 一个实例

在一次Http申请中，容器会返回该Bean的同一实例。而对不同的Http申请则会产生新的Bean，而且该Bean仅在以后Http Request内无效,以后Http申请完结，该bean
实例也将会被销毁。
```
<bean id="loginAction" class="com.cnblogs.Login" scope="request"/>
```
session

在一次Http Session中，容器会返回该Bean的同一实例。而对不同的Session申请则会创立新的实例，该Bean实例仅在以后Session内无效。同Http申请雷同，每一次
session申请创立新的实例，而不同的实例之间不共享属性，且实例仅在本人的session申请内无效，申请完结，则实例将被销毁。
```
<bean id="userPreference" class="com.ioc.UserPreference" scope="session"/>
```
global Session
在一个全局的Http Session中，容器会返回该Bean的同一个实例，仅在
应用portlet context时无效。

Bean 生命周期

Bean 的生命周期概括起来就是 4 个阶段：

实例化（Instantiation）；
属性赋值（Populate）；
初始化（Initialization）；
销毁（Destruction）。

实例化：实例化一个 Bean，也就是咱们常说的 new。
IOC 依赖注入：依照 Spring 上下文对实例化的 Bean 进行配置，也就是 IOC 注入。
setBeanName实现：如果这个Bean曾经实现了BeanNameAware接口，会调用它实现的setBeanName(String)办法，此处传递的就是Spring配置文件中Bean的id值
BeanFactoryAware实现：如果这个Bean曾经实现了BeanFactoryAware接口，会调用它实现的setBeanFactory，setBeanFactory(BeanFactory)传递的是Spring工厂本身（能够用这个形式来获取其它Bean，只需在Spring配置文件中配置一个一般Bean就能够）。
ApplicationContextAware实现：如果这个Bean曾经实现ApplicationContextAware接口，会调用setApplicationContext(ApplicationContext)办法，传入Spring上下文（同样这个形式也能够实现步骤 4 的内容，但比 4 更好，因为 ApplicationContext是 BeanFactory 的子接口，有更多的实现办法）
postProcessBeforeInitialization 接口实现-初始化预处理：如果这个Bean关联了BeanPostProcessor 接口，将会调用postProcessBeforeInitialization(Object obj, String s)办法， BeanPostProcessor常常被用作是Bean内容的更改，并且因为这个是在Bean初始化完结时调用那个的办法，也能够被利用于内存或缓存技术。
init-method：如果Bean在 Spring 配置文件中配置了init-method属性会主动调用其配置的初始化办法。
postProcessAfterInitialization：如果这个Bean关联了 BeanPostProcessor 接口，将会调用postProcessAfterInitialization(Object obj, String s)办法。
注：以上工作实现当前就能够利用这个Bean了，那这个Bean是一个Singleton的
Destroy 过期主动清理阶段：当Bean不再须要时，会通过清理阶段，如果Bean实现了DisposableBean这个接口，会调用其实现的destroy()办法；
destroy-method 自配置清理：最初，如果这个Bean的Spring配置中配置了destroy-method属性，会主动调用其配置的销毁办法。

bean标签有两个重要的属性（init-method 和 destroy-method）。用它们能够本人定制初始化和登记办法。也有相应的注解（@PostConstruct 和@PreDestroy）
<bean id="" class="" init-method="初始化办法" destroy-method="销毁办法">

依赖注入形式

对于spring配置一个bean时，如果须要给该bean提供一些初始化参数，则须要通过依赖注入形式，所谓的依赖注入就是通过spring将bean所须要的一些参数传递到bean实例对象的过程（将依赖关系注入到对象中）

在创立新的Bean时，IoC容器会主动注入新Bean的所依赖的其余Bean，而无须本人手动创立。

结构器注入

private DependencyA dependencyA;
private DependencyB dependencyB;
private DependencyC dependencyC;

public DI(DependencyA dependencyA, DependencyB dependencyB, DependencyC dependencyC) {

   this.dependencyA = dependencyA;
   this.dependencyB = dependencyB;
   this.dependencyC = dependencyC;

}


2. setter 办法注入

private DependencyA dependencyA;
private DependencyB dependencyB;
private DependencyC dependencyC;

@Autowired
public void setDependencyA(DependencyA dependencyA) {

   this.dependencyA = dependencyA;

}

@Autowired
public void setDependencyB(DependencyB dependencyB) {

   this.dependencyB = dependencyB;

}

@Autowired
public void setDependencyC(DependencyC dependencyC) {

   this.dependencyC = dependencyC;

}


3. 字段注入

@Autowired
private DependencyA dependencyA;

@Autowired
private DependencyB dependencyB;

@Autowired
private DependencyC dependencyC;


| 注入形式        | **长处**                                             | **毛病**                                                     |
| --------------- | ---------------------------------------------------- | ------------------------------------------------------------ |
| 字段注入        | 简略，便于增加新的dependency                         | 可能会呈现注入失败而呈现NullPointedException；在Test和其余Module不可用；不可用于final字段，从而无奈保障字段的不变性。 |
| setter注入      | 灵活性高，便于批改依赖对象                           | 对于仅应用setter注入的依赖对象须要进行非空查看；对象无奈在结构实现后马上进入就绪状态 |
| constructor注入 | 对象在结构实现之后，即已进入就绪状态，能够马上应用。 | 当依赖对象比拟多的时候，构造方法的参数列表会比拟长，保护和应用也比拟麻烦，依据繁多职责准则，此时应该思考重构了。应用不慎还有可能呈现循环依赖。 |

***Spring4.x之后，注入形式应该按需抉择setter或constructor注入形式。***

#### 主动拆卸形式

**主动拆卸是为了将依赖注入“自动化”的一个简化配置的操作。**
当一个对象的属性是另一个对象时，实例化时，须要为这个对象属性进行实例化。这就是拆卸。

Spring 拆卸包含手动拆卸和主动拆卸，手动拆卸是有基于 xml 拆卸、 构造方法、 setter 办法等；主动拆卸有五种主动拆卸的形式，能够用来领导Spring容器用主动拆卸形式来进行依赖注入。
1. no：默认的形式是不进行主动拆卸，通过显式设置 ref 属性来进行拆卸。
2. byName：通过参数名 主动拆卸， Spring 容器在配置文件中发现 bean 的 autowire 属性被设置成 byname，之后容器试图匹配、拆卸和该 bean 的属性具备雷同名字的 bean。
3. byType：通过参数类型主动拆卸， Spring 容器在配置文件中发现 bean 的 autowire 属性被设置成 byType，之后容器试图匹配、拆卸和该 bean 的属性具备雷同类型的 bean。如果有多个 bean 符合条件，则抛出谬误。
4. constructor：这个形式相似于 byType， 然而要提供给结构器参数，如果没有确定的带参数的结构器参数类型，将会抛出异样。
5. autodetect：首先尝试应用 constructor 来主动拆卸，如果无奈工作，则应用 byType 形式。

罕用的主动拆卸注解有以下几种：@Autowired，@Qualifier(@Resource, @Inject, @Named为JavaEE的规范，不倡议应用)。

**@Autowired**注解是byType类型的，这个注解能够用在属性下面，setter方面下面以及结构器下面。应用这个注解时，就不须要在类中为属性增加setter办法了。然而这个属性是强制性的，也就是说必须得拆卸上，如果没有找到适合的bean可能拆卸上，就会抛出异样：｀NoSuchBeanDefinitionException，如果required=false时，则不会抛出异样。另一种状况是同时有多个bean是一个类型的，也会抛出这个异样。此时须要进一步明确要拆卸哪一个Bean，这时能够组合应用@Qualifier注解，值为Bean的名字即可。

**@Qualifier**注解应用byName进行拆卸，这样能够在多个类型一样的bean中，明确应用哪一个名字的bean来进行拆卸。@Qualifier注解起到了放大主动拆卸候选bean的范畴的作用。

自动检测配置，也是springmvc中最牛的一项性能。只有一个配置`<context:component-scan base-package="">`或者注解`@ComponentScan("")`

该配置会主动扫描指定的包及其子包上面被构造型注解标注的类，并将这些类注册为spring bean，这样就不必在配置文件一个一个地配置成bean标签。构造型注解包含：@Controller，@Components，@Service，@Repository和应用@Component标注的自定义注解。

#### 循环依赖

依赖注入稍不留神就会呈现循环依赖：
Bean之间的依赖程序： BeanA -> BeanB -> BeanA

举个例子：

@Component
public class CircularDependencyA {

private CircularDependencyB circB;

@Autowired
public CircularDependencyA(CircularDependencyB circB) {
    this.circB = circB;
}

}

@Component
public class CircularDependencyB {

private CircularDependencyA circA;

@Autowired
public CircularDependencyB(CircularDependencyA circA) {
    this.circA = circA;
}

}


**解决办法**

呈现循环依赖是因为设计问题，**最佳解决办法是从新设计**。

在理论开发中，推倒重来往往是不容许的，所以会有以下几种补救办法。

1. 改用setter注入形式(举荐)
   与constructor注入不同，setter是按需注入的，并且容许依赖对象为null；

@Component
public class CircularDependencyA {


   private CircularDependencyB circB;

   @Autowired
   public void setCircB(CircularDependencyB circB) {
       this.circB = circB;
   }

   public CircularDependencyB getCircB() {
       return circB;
   }

}

@Component
public class CircularDependencyB {


   private CircularDependencyA circA;

   @Autowired
   public void setCircA(CircularDependencyA circA) {
       this.circA = circA;
   }

}


2. @Lazy注解（提早初始化）

  // 先构建 CircularDependencyA实现后， 再构建CircularDependencyB，突破dependency circle。
  @Component
  public class CircularDependencyA {
   
      private CircularDependencyB circB;
   
      @Autowired
      public CircularDependencyA(@Lazy CircularDependencyB circB) {
          this.circB = circB;
      }
  }
  ```

应用ApplicationContextAware, InitializingBean

// ApplicationContextAware获取SpringContext，用于加载bean；InitializingBean定义了设置Bean的property之后的动作。
@Component
public class CircularDependencyA implements InitializingBean, ApplicationContextAware {
    private CircularDependencyB circB;
    private ApplicationContext context;
    
    @Override
    public void afterPropertiesSet() throws Exception {
        this.circB = context.getBean(CircularDependencyB.class);
    }

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        this.context = applicationContext;
    }

    public CircularDependencyB getCircularDependencyB() {
        return circB;
    }
}

Spring循环以来解决原理

https://cloud.tencent.com/dev…

关于java:Spring-IOC-原理

Spring IOC 原理

概念

IOC和依赖注入

Bean 作用域

Bean 生命周期

依赖注入形式

评论

发表回复取消回复

更多文章

DDN HPC 存储硬件架构设计深度分析

探秘IO500：从Lustre并行文件系统出发，开启HPC存储性能新征程

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

关于java:Spring-IOC-原理

Spring IOC 原理

概念

IOC和依赖注入

Bean 作用域

Bean 生命周期

依赖注入形式

评论

发表回复 取消回复

更多文章

DDN HPC 存储硬件架构设计深度分析

探秘IO500：从Lustre并行文件系统出发，开启HPC存储性能新征程

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

发表回复取消回复