前言
欢迎来到本篇文章，书接上回，本篇说说 Spring 中的依赖注入，包括注入的方式，写法，该选择哪个注入方式以及可能出现的循环依赖问题等内容。
如果正在阅读的朋友还不清楚什么是「依赖」，建议先看看我第一篇文章，通过 Employee 和 Department 简单说了什么是所谓的依赖。
什么是依赖注入？
依赖注入是一个过程，举个例子：
public class A {
private B b;
// 省略 getter 和 setter
// 省略构造方法
}
现在 A 类 是依赖 B 类的，没有 B，A 什么都不是。Spring IoC 容器创建好 B 的实例对象后并赋值给 A 对象中的 b 属性（成员变量）的过程，就是所谓的「依赖注入」。
当然，这也是所谓的控制反转了，对象 b 的创建不是我们手动 new 创建的，而是 Spring IoC 容器创建的。
使用 DI 原则，可以让代码更加简洁，当对象提供其依赖项时，解耦也更加有效。依赖项 B 注入给 A 的实例对象，A 的实例对象是不会查找它的依赖项 B 的，也不知道依赖项 B 的位置。
依赖注入主要有两种实现方式：基于构造方法的依赖注入和基于 Setter 的依赖注入。
基于构造方法的依赖注入
基于构造方法的 DI 是通过 Spring IoC 容器调用带有许多参数的构造方法来完成的，每个参数表示一个依赖项。这与上一篇中调用具有特定参数的静态工厂方法来构造 Bean 是几乎等价的。
public class Vehicle {
// Vehicle 依赖于 Producer 对象，或者说 Vehicle 持有一个 Producer 依赖项
private final Producer producer;
// 构造方法，让 Spring IoC 容器能够注入 Producer 对象给 Vehicle 对象
public Vehicle(Producer producer) {
this.producer = producer;
}
}
注意，这个 Vehicle 类就只是一个普通的 Java Bean，或者说 POJO，没什么特别之处，最普通不过的类了，没有继承或者实现 Spring 指定的任意类。
构造方法中参数的解析
Spring IoC 是通过构造方法参数的解析来匹配需要注入的依赖项。换句话说，解析实际上就是通过匹配参数的类型，来确定注入什么依赖项。
如果构造方法的参数中没有存在潜在的歧义，那么在 Bean 被实例化的时候，构造方法中参数的顺序和实例化时进行赋值是一样的。
package cn.god23bin.demo.model;
public class A {
private B b;
private C c;
public A(B b, C c) {
this.b = b;
this.c = c;
}
}
单独写这些类，是完成不了依赖注入的，这时候需要配置元数据了，让它与 Java 类相结合，才能发挥 Spring IoC 的作用。
现在假设 B 和 C 是没有任何继承上的关联，也没有任何潜在的歧义，那么我们在配置元数据中的配置是正常的，需要使用到 标签，该标签只需有一个 ref 属性，即引用（reference），指明 A 的构造方法的参数为 B 和 C，如下：
我们知道，B 和 C 是属于引用类型，类型是确切的，所以直接使用 ref 属性。
如果是基本数据类型，那么赋值时，就可能会有歧义，Spring 不能确定这个值的类型，比如一个基本数据类型的值是 true，这时候歧义就出现了，它是布尔类型还是字符串类型呢？这就需要由我们来告诉 Spring 了，就需要使用 type 和 value 属性来指定。
比如：
package cn.god23bin.demo.model;
public class D {
private final int money;
private final String power;
public D(int money, String power) {
this.money = money;
this.power = power;
}
}
当然，除了使用 type 指定基本数据类型，还有两个属性可以解决歧义，分别是 index 和 name 属性。
index 属性：
使用 index 属性指定构造方法参数的下标，下标是从 0 开始的，来解决参数类型出现歧义的情况。
name 属性：
使用 name 属性指定构造方法参数的名称来解决歧义。
基于 Setter 的依赖注入
基于 Setter 的 DI，是在 Spring IoC 容器调用了 Bean 的无参构造方法或者无参的静态工厂方法实例化了 Bean 之后，再来调用 Bean 的 Setter 方法来实现的。
下面这个依旧是普通的 Java Bean，当然你加上相关业务逻辑，就不是纯粹的 Java Bean 了，不过 Spring 依旧能够管理这种对象。
Vehicle：
public class Vehicle {
// Vehicle 持有的 Producer 依赖项
private Producer pro;
// 同理
private Author aut;
// 同理
private int money;
// setter 方法，可以让 Spring IoC 容器调用注入 Producer 对象
public void setProducer(Producer pro) {
this.pro = pro;
}
// 同理
public void setAut(Author aut) {
this.aut = aut;
}
// 同理
public void setMoney(int money) {
this.money = money
}
// 业务逻辑，有关 Producer 的...
}
对应的配置元数据：
Spring IoC 容器（ApplicationContext）支持基于构造方法的 DI 和基于 Setter 的 DI，也支持使用构造方法注入了一部分依赖项后，再使用 Setter 的方式注入其他的依赖项。
我们可以通过配置一个 BeanDefinition 和 PropertyEditor 来实现这些属性的注入。但是，我们基本不会这样用，而是使用 XML 的 Bean 定义，使用注解的 Bean 定义（比如 @Component，@Controller 等），又或者使用 @Bean 这种基于 Java 配置类的方式（@Configuration）来定义。
实际上，这些最终都会转成 BeanDefinition 对象的并被 Spring IoC 使用。
选择哪个 DI 方式？
在代码的编写中，选择使用构造方法注入还是使用 Setter 注入呢？
官网上是这么说的：
Since you can mix constructor-based and setter-based DI, it is a good rule of thumb to use constructors for mandatory dependencies and setter methods or configuration methods for optional dependencies. Note that use of the @Autowired annotation on a setter method can be used to make the property be a required dependency; however, constructor injection with programmatic validation of arguments is preferable.
The Spring team generally advocates constructor injection, as it lets you implement application components as immutable objects and ensures that required dependencies are not
null. Furthermore, constructor-injected components are always returned to the client (calling) code in a fully initialized state. As a side note, a large number of constructor arguments is a bad code smell, implying that the class likely has too many responsibilities and should be refactored to better address proper separation of concerns.Setter injection should primarily only be used for optional dependencies that can be assigned reasonable default values within the class. Otherwise, not-null checks must be performed everywhere the code uses the dependency. One benefit of setter injection is that setter methods make objects of that class amenable to reconfiguration or re-injection later. Management through JMX MBeans is therefore a compelling use case for setter injection.
Use the DI style that makes the most sense for a particular class. Sometimes, when dealing with third-party classes for which you do not have the source, the choice is made for you. For example, if a third-party class does not expose any setter methods, then constructor injection may be the only available form of DI.
简而言之，Spring 团队是推荐用构造方法来完成 DI 的。
-
对于强依赖项，直接用基于构造方法的 DI，这种注入方式能够保证注入的 Bean 对象不可变，并且确保需要的依赖不为空。此外，构造方法注入的依赖总是能够在返回客户端（调用方）的时候保证完全初始化的状态。
-
对于可选的弱依赖项，使用基于 Setter 的 DI。当使用
@Autowired注解，并将注解用到 Setter 方法上的话，那么这个 Setter 设置的属性就变成强依赖了。
对于构造方法进行 DI ，其中：
- 依赖不可变：其实说的就是 final 关键字。
- 依赖不为空：省去了我们对注入的 Bean 的检查，当要实例化 Bean 的时候，由于自己实现了有参数的构造方法，所以不会调用默认构造方法，那么就需要 Spring IoC 容器传入所需要的参数给有参构造方法，所以就两种情况，有该类型的参数传入，那么 OK ；无该类型的参数，那么报错。
- 完全初始化的状态：这个可以跟上面的依赖不为空结合起来，向构造方法传参之前，要确保注入的内容不为空，那么肯定要调用依赖对象的构造方法完成实例化。而在 Java 类加载实例化的过程中，构造方法是最后一步才执行的，所以返回来的实例化对象都是完全初始化之后的状态。
依赖的处理过程
Spring IoC 容器按如下方式执行 Bean 的依赖处理（Dependency Resolution Process，个人认为把 Resolution 理解成处理，解决等意思比较好）。
- 根据配置元数据的内容，
ApplicationContext被创建和初始化。这个配置元数据是用来描述所有 Bean 的，它可以是 XML、Java 代码或注解。 - 对于每个 Bean 来说，它的依赖是以属性、构造方法参数或静态工厂方法的参数（如果你用它代替构造方法）的形式表达的。在 Spring IoC 创建 Bean 的时候，这些依赖会被提供给需要的 Bean。
- 每个属性或构造方法参数都是要设置的值的实际定义，或对容器中另一个 Bean 的引用。
- 每个作为值的属性或构造方法参数都会从其指定格式转换为该属性或构造方法参数的实际类型。默认情况下，Spring 可以将以字符串格式提供的值转换为所有内置类型，如
int、long、String、boolean等等。
当 Spring IoC 容器被创建时，Spring IoC 容器一开始就会校验每个 Bean 的配置。在创建 Bean 之前，Bean 的属性本身不会被设置。
而且当容器被创建时，那些具有单例作用域的 Bean 也默认会被创建。对于其他情况的 Bean，只有在被请求时才会创建。
一个 Bean 的创建是有可能导致一堆 Bean 被创建，这一堆的 Bean 被称为 Bean 图（a graph of beans），因为 Bean 与 Bean 之间可能存在相互依赖，如同社会中的人一样，都有相关的联系，所以形成 Bean 图。
Bean 作用域在进行 Bean 定义的时候可以进行定义，使用
scope属性即可定义 Bean 的作用域。
循环依赖
当你使用构造函数注入的时候，某种情况下可能产生一个无法解决的循环依赖问题。那什么是循环依赖？
举个例子：
public class A {
private B b;
public A(B b) {
this.b = b;
}
}
public class B {
private A a;
public B(A a){
this.a = a;
}
}
如上所示，A 类通过构造方法注入需要 B 类的对象，而 B 类也通过构造方法注入 A 类的一个对象，这种情况就是所谓的循环依赖，A 和 B 之间相互依赖。
A 和 B 之间的循环依赖关系会迫使其中一个 Bean 在未完全初始化之前，被注入到另一个 Bean 中。
这时候，Spring IoC 容器会在运行时检测到这种循环的引用，并抛出一个 BeanCurrentlyInCreationException。
有一种解决方案就是：修改 A 类或者 B 类的源代码，使其通过 Setter 方式注入依赖项。
当然，一般情况下，我们可以完全相信 Spring，Spring 会在容器加载时检测配置问题，如检查引用不存在的 Bean 或循环依赖等。它会尽量晚地设置 Bean 的属性以及处理依赖的关系。
假设当你请求一个对象时，如果在创建该对象或其依赖关系时出现问题，已经正确加载的 Spring 容器就会产生异常。所以，这意味着我们需要提前发现这些问题。
默认情况下，ApplicationContext 会预先实例化单例 Bean，所以在创建 Spring IoC 容器时会花费一些时间和内存。但好处是可以在容器创建时发现配置问题，而不是在后续出现。
如果不存在循环依赖关系，一个 Bean 在被注入到另一个 Bean 之前会被完全配置。这意味着当 A 依赖于 B 时，Spring IoC 容器会先完全配置好 B（包括实例化 Bean、设置依赖关系和调用相关的生命周期方法），再调用 A 的 Setter 方法。
依赖注入示例
下面写下示例，快速回顾下上面的两种注入方式，帮助大家更好理解在以 XML 作为配置元数据的情况下，使用基于构造方法的 DI 和基于 Setter 的 DI。
- 基于构造方法的 DI：
package cn.god23bin.demo.service;
import cn.god23bin.demo.repository.UserRepository;
public class UserService {
// UserService 的依赖项 UserRepository
private UserRepository userRepository;
// 使用构造方法进行 DI，将 UserRepository 注入到 UserService
public UserService(UserRepository userRepository) {
this.userRepository = userRepository;
}
}
- 基于 Setter 的 DI：
package cn.god23bin.demo.service;
import cn.god23bin.demo.repository.UserRepository;
public class UserService {
private UserRepository userRepository;
public void setUserRepository(UserRepository userRepository) {
this.userRepository = userRepository;
}
}
总结
本文开头举了个例子讲了什么是依赖注入，实际上就是一个过程，把一个 Bean 注入到另一个 Bean 中的过程。
这个过程，在 Spring 中有两种方式来实现，一种是基于构造方法的 DI，另一种是基于 Setter 的DI。当然，网上讲到的依赖注入，还有好几种方式，目前对于我们来说，知道这两种就 OK。
对于这两种 DI，我们也说了如何选择，具体看官网的说法，推荐的是基于构造方法的 DI，当然，具体问题具体分析，有时候是需要用到基于 Setter 的 DI 的，比如解决循环依赖的时候。
接着也说了依赖的处理过程，简单点就是 Spring 会先根据配置元数据去创建 ApplicationContext 这个作为 Spring IoC 容器，在容器创建时，会验证 Bean 是否正确配置了，默认单例的 Bean 会先被创建等等等的处理。同时可能遇到循环依赖的问题，一种解决方案就是将某一个 Bean 使用 Setter 的方式注入依赖项。
以上，便是本篇文章的内容了。下期咱们讲讲依赖注入的一些细节写法，比如有的依赖项是集合，那么配置元数据中该如何写这个集合，进而实现集合的依赖注入等等。
希望本篇有帮助到大家，有兴趣的话可以关注我，关注这个系列！
最后的最后
希望各位屏幕前的靓仔靓女们给个三连！你轻轻地点了个赞，那将在我的心里世界增添一颗明亮而耀眼的星！
咱们下期再见！
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.fwqtg.net
