前言

本章的内容主要是想探讨我们在进行Spring 开发过程当中，关于依赖注入的几个知识点。感兴趣的读者可以先看一下以下问题：

• @Autowired, @Resource, @Inject 三个注解的区别
• 当你在使用@Autowired时，是否有出现过Field injection is not recommended的警告？你知道这是为什么吗？
• Spring 依赖注入有哪几种方式？官方是怎么建议使用的呢？

如果你对上述问题都了解，那我个人觉得你的开发经验应该是不错的

下面我们就依次对上述问题进行解答，并且总结知识点。

@Autowired, @Resource, @Inject 三个注解的区别

Spring 支持使用@Autowired, @Resource, @Inject 三个注解进行依赖注入。下面来介绍一下这三个注解有什么区别。

@Autowired

@Autowired为Spring 框架提供的注解，需要导入包org.springframework.beans.factory.annotation.Autowired。

这里先给出一个示例代码，方便讲解说明：

测试类：

@Inject

在Spring 的环境下，@Inject和@Autowired 是相同的，因为它们的依赖注入都是使用AutowiredAnnotationBeanPostProcessor来处理的。

@Inject是 JSR-330 定义的规范，如果使用这种方式，切换到Guice也是可以的。

Guice 是 google 开源的轻量级 DI 框架

如果硬要说两个的区别，首先@Inject是Java EE包里的，在SE环境需要单独引入。另一个区别在于@Autowired可以设置required=false而@Inject并没有这个属性。

@Resource

@Resource是JSR-250定义的注解。Spring 在 CommonAnnotationBeanPostProcessor实现了对JSR-250的注解的处理，其中就包括@Resource。

@Resource有两个重要的属性：name和type，而Spring 将@Resource注解的name属性解析为bean的名字，而type属性则解析为bean的类型。

装配顺序：

1. 如果同时指定了name和type，则从Spring上下文中找到唯一匹配的bean进行装配，找不到则抛出异常。
2. 如果指定了name，则从上下文中查找名称（id）匹配的bean进行装配，找不到则抛出异常。
3. 如果指定了type，则从上下文中找到类型匹配的唯一bean进行装配，找不到或是找到多个，都会抛出异常。
4. 如果既没有指定name，又没有指定type，则默认按照byName方式进行装配；如果没有匹配，按照byType进行装配。

IDEA 提示 Field injection is not recommended

在使用IDEA 进行Spring 开发的时候，当你在字段上面使用@Autowired注解的时候，你会发现IDEA 会有警告提示：

翻译过来就是这个意思：

不建议使用基于 field 的注入方式。

Spring 开发团队建议：在你的Spring Bean 永远使用基于constructor 的方式进行依赖注入。对于必须的依赖，永远使用断言来确认。

比如如下代码：

将光标放到@Autowired处，使用Alt + Enter 快捷进行修改之后，代码就会变成基于Constructor的注入方式，修改之后：

如果按照Spring 团队的建议，如果svc是必须的依赖，应该使用Assert.notNull(svc, "svc must not be null")来确认。

修正这个警告提示固然简单，但是我觉得更重要是去理解为什么Spring 团队会提出这样的建议？直接使用这种基于 field 的注入方式有什么问题？

首先我们需要知道，Spring 中有这么3种依赖注入的方式：

• 基于 field 注入（属性注入）
• 基于 setter 注入
• 基于 constructor 注入（构造器注入）

1. 基于 field 注入

所谓基于 field 注入，就是在bean的变量上使用注解进行依赖注入。本质上是通过反射的方式直接注入到field。这是我平常开发中看得最多也是最熟悉的一种方式，同时，也正是 Spring 团队所不推荐的方式。比如：

3. 基于 constructor 注入

将各个必需的依赖全部放在带有注解构造方法的参数中，并在构造方法中完成对应变量的初始化，这种方式，就是基于构造方法的注入。比如：

在 Spring 4.3 及以后的版本中，如果这个类只有一个构造方法，那么这个构造方法上面也可以不写 @Autowired 注解。

基于 field 注入的好处

正如你所见，这种方式非常的简洁，代码看起来很简单，通俗易懂。你的类可以专注于业务而不被依赖注入所污染。你只需要把@Autowired扔到变量之上就好了，不需要特殊的构造器或者set方法，依赖注入容器会提供你所需的依赖。

基于 field 注入的坏处

成也萧何败也萧何

基于 field 注入虽然简单，但是却会引发很多的问题。

• 容易违背了单一职责原则 使用这种基于 field 注入的方式，添加依赖是很简单的，就算你的类中有十几个依赖你可能都觉得没有什么问题，普通的开发者很可能会无意识地给一个类添加很多的依赖。但是当使用构造器方式注入，到了某个特定的点，构造器中的参数变得太多以至于很明显地发现something is wrong。拥有太多的依赖通常意味着你的类要承担更多的责任，明显违背了单一职责原则（SRP：Single responsibility principle）。这个问题在我司的项目代码真的很常见。
• 依赖注入与容器本身耦合依赖注入框架的核心思想之一就是受容器管理的类不应该去依赖容器所使用的依赖。换句话说，这个类应该是一个简单的POJO(Plain Ordinary Java Object)能够被单独实例化并且你也能为它提供它所需的依赖。这个问题具体可以表现在：
• 你的类和依赖容器相耦合，不能在容器外使用
• 你的类不能绕过反射（例如单元测试的时候）进行实例化，必须通过依赖容器才能实例化，这更像是集成测试
• 不能使用属性注入的方式构建不可变对象(final 修饰的变量)

Spring 开发团队的建议

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.

简单来说，就是

• 强制依赖就用构造器方式
• 可选、可变的依赖就用setter 注入当然你可以在同一个类中使用这两种方法。构造器注入更适合强制性的注入旨在不变性，Setter注入更适合可变性的注入。

让我们看看Spring 这样推荐的理由，首先是基于构造方法注入，

Spring 团队提倡使用基于构造方法的注入，因为这样一方面可以将依赖注入到一个不可变的变量中 (注：final 修饰的变量)，另一方面也可以保证这些变量的值不会是 null。此外，经过构造方法完成依赖注入的组件 (注：比如各个 service)，在被调用时可以保证它们都完全准备好了。与此同时，从代码质量的角度来看，一个巨大的构造方法通常代表着出现了代码异味，这个类可能承担了过多的责任。

而对于基于 setter 的注入，他们是这么说的：

基于 setter 的注入，则只应该被用于注入非必需的依赖，同时在类中应该对这个依赖提供一个合理的默认值。如果使用 setter 注入必需的依赖，那么将会有过多的 null 检查充斥在代码中。使用 setter 注入的一个优点是，这个依赖可以很方便地被改变或者重新注入。

总结：以上就是本文的所有内容，希望阅读本文之后能让你对Spring 的依赖注入有更深的理解。

如何获取？

转发分享此文，后台私信小编：“ 666 ”即可获取。（注：转发分享，感谢大家）