Spring为什么建议构造器注入，你知道么？

如果硬要说两个的区别，首先@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方式进行装配；如果没有匹配，按照byTypeh进行装配。

IDEA 提示 Field injection is not recommended

---

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

Field injection is not recommended

Inspection info: Spring Team Recommends: “Always use constructor based dependency injection in your beans. Always use assertions for mandatory dependencies”.

翻译过来就是这个意思：

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

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

比如如下代码：

@Service

public class HelpService {

@Autowired

@Qualifier(“svcB”)

private Svc svc;

public void sayHello() {

svc.sayHello();

}

}

public interface Svc {

void sayHello();

}

@Service

public class SvcB implements Svc {

@Override

public void sayHello() {

System.out.println(“hello, this is service B”);

}

}

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

@Service

public class HelpService {

private final Svc svc;

@Autowired

public HelpService(@Qualifier(“svcB”) Svc svc) {

// Assert.notNull(svc, “svc must not be null”);

this.svc = svc;

}

public void sayHello() {

svc.sayHello();

}

}

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

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

---

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

• 基于 field 注入（属性注入）

• 基于 setter 注入

• 基于 constructor 注入（构造器注入）

1. 基于 field 注入

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

@Autowired

private Svc svc;

2. 基于 setter 方法注入

通过对应变量的setXXX()方法以及在方法上面使用注解，来完成依赖注入。比如：

private Helper helper;

@Autowired

public void setHelper(Helper helper) {

this.helper = helper;

}

注：在 Spring 4.3 及以后的版本中，setter 上面的 @Autowired 注解是可以不写的。

3. 基于 constructor 注入

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

private final Svc svc;

@Autowired

public HelpService(@Qualifier(“svcB”) Svc svc) {

this.svc = svc;

}

在 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 这样推荐的理由，首先是基于构造方法注入，

The Spring team generally advocates constructor injection as it enables one to implement application components as immutable objects and to ensure that required dependencies are not null. Furthermore constructor-injected components are always returned to 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.

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

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

最后

由于篇幅限制，小编在此截出几张知识讲解的图解

《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门即可获取！
671a72faed303032d36.jpg" alt=“img” style=“zoom: 33%;” />

最后

由于篇幅限制，小编在此截出几张知识讲解的图解

[外链图片转存中…(img-bP0hi5Xb-1712219954234)]

[外链图片转存中…(img-eo8S5AqA-1712219954234)]

[外链图片转存中…(img-asMLj4rY-1712219954235)]

[外链图片转存中…(img-BtX4XVYb-1712219954235)]

[外链图片转存中…(img-1v7MoplE-1712219954235)]

《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门即可获取！