扯一把 Spring 的三种注入方式,到底哪种注入方式最佳?
共 3031字，需浏览 7分钟
·
2021-10-31 21:12
循环依赖这个问题，按理说我们在日常的程序设计中应该避免，其实这个本来也是能够避免的。不过由于总总原因，我们可能还是会遇到一些循环依赖的问题，特别是在面试的过程中，面试考察循环依赖，主要是想考察候选人对 Spring 源码的熟悉程度，因为要把循环依赖这个问题解释清楚，涉及到不少 Spring 源码。
今天松哥抽空和大家简单聊聊这个话题，问题比较庞大，我可能花几篇文章来和大家分享下，今天先来聊聊实例的注入方式。
1. 实例的注入方式
首先来看看 Spring 中的实例该如何注入，总结起来，无非三种：
- 属性注入
- set 方法注入
- 构造方法注入
我们分别来看下。
1.1 属性注入
属性注入是大家最为常见也是使用最多的一种注入方式了，代码如下：
@Service
public class BService {
@Autowired
AService aService;
//...
}
这里是使用 @Autowired 注解注入。另外也有 @Resource 以及 @Inject 等注解，都可以实现注入。
不过不知道小伙伴们有没有留意过，在 IDEA 里边，使用属性注入，会有一个警告⚠️：
不推荐属性注入！
原因我们后面讨论。
1.2 set 方法注入
set 方法注入太过于臃肿，实际上很少使用：
@Service
public class BService {
AService aService;
@Autowired
public void setaService(AService aService) {
this.aService = aService;
}
}
这代码看一眼都觉得难受，坚决不用。
1.3 构造方法注入
构造方法注入方式如下：
@Service
public class AService {
BService bService;
@Autowired
public AService(BService bService) {
this.bService = bService;
}
}
如果类只有一个构造方法，那么 @Autowired 注解可以省略；如果类中有多个构造方法，那么需要添加上 @Autowired 来明确指定到底使用哪个构造方法。
2. 实例注入方式大 PK
上面给大家列出来了三种注入方式，那么三种注入方式各自有何区别呢？
结合 Spring 官方文档，我们来分析下。
松哥翻出了 12 年前的 Spring3.0 的文档（https://docs.spring.io/spring-framework/docs/3.0.x/reference/beans.html），里边有如下一段话：
我来简单翻译下（意译）：
❝使用构造方法注入还是使用 set 方法注入？由于构造方法注入和 set 方法注入可以混合使用，因此，如果需要强制注入，我们可以使用构造方法注入的方式；如果是可选注入，则我们可以使用 set 方法注入的方式。当然，我们在 setter 上使用 @Required 注解可以让 set 方法注入也变为强制性注入。Spring 团队通常提倡 setter 注入，因为当属性特别多的时候，构造方法看起来会特别臃肿，特别是当属性是可选的时（属性可选意味着没必要通过构造方法注入）。Setter 方法注入还有一个好处就是可以使该类的属性可以在以后重新配置或重新注入。一些纯粹主义者喜欢基于构造函数的注入，这样意味着所有的属性都被初始化了，缺点则是对象变得不太适合重新配置和重新注入。另外在一些特殊的场景下，如一个第三方类要注入到 Spring 容器，但是该类没有提供 set 方法，那么此时你就只能使用构造方法注入了。
英文水平有限，大概翻译了下。小伙伴们重点看加粗部分，也就是说在 Spring3.0 时代，官方还是提倡 set 方法注入的。
不过从 Spring4.x 开始，官方就不推荐这种注入方式了，转而推荐构造器注入。
我们来看看 Spring4.x 的文档怎么说（https://docs.spring.io/spring-framework/docs/4.0.x/spring-framework-reference/htmlsingle/#beans-setter-injection）：
这段内容我就不一一翻译了，大家重点看第二段第一句：
The Spring team generally advocates constructor injection
这句话就是说 Spring 团队倡导通过构造方法完成注入。才一个大版本更新，Spring 咋就变了呢？别急，人家也给出用构造方法注入的理由，第二段翻译一下大概是这个意思：
通过构造方法注入的方式，能够保证注入的组件不可变，并且能够确保需要的依赖不为空。此外，构造方法注入的依赖总是能够在返回客户端（组件）代码的时候保证完全初始化的状态。
上面这段话主要说了三件事：
- 依赖不可变：这个好理解，通过构造方法注入依赖，在对象创建的时候就要注入依赖，一旦对象创建成功，以后就只能使用注入的依赖而无法修改了，这就是依赖不可变（通过 set 方法注入将来还能通过 set 方法修改）。
- 依赖不为空：通过构造方法注入的时候，会自动检查注入的对象是否为空，如果为空，则注入失败；如果不为空，才会注入成功。
- 完全初始化：由于获取到了依赖对象（这个依赖对象是初始化之后的），并且调用了要初始化组件的构造方法，因此最终拿到的就是完全初始化的对象了。
在 Spring3.0 文档中，官方说如果构造方法注入的话，属性太多可能会让代码变得非常臃肿，那么在 4.0 文档中，官方对这个说法也做了一些订正：如果用构造方法注入的时候，参数过多以至于代码过于臃肿，那么此时你需要考虑这个类的设计是否合理，这个类是否参杂了太多的其他无关功能，这个类是否做到了单一职责。
❝好吧，你说的总是有理！
这是构造方法注入和 set 方法注入的问题，那么上面我们还提到不推荐属性注入，这又是咋回事呢？
属性注入其实有一个显而易见的缺点，那就是对于 IOC 容器以外的环境，除了使用反射来提供它需要的依赖之外，无法复用该实现类。因为该类没有提供该属性的 set 方法或者相应的构造方法来完成该属性的初始化。换言之，要是使用属性注入，那么你这个类就只能在 IOC 容器中使用，要是想自己 new 一下这个类的对象，那么相关的依赖无法完成注入。
以上分析都是根据 Spring 官方文档得来，日常开发应该还是属性注入较多，这个咱们不必纠结，代码该咋写还咋写，Spring 官方的态度了解一下即可，当然，如果项目允许，也不妨试试 Spring 推荐的代码规范。
3. 小结
好啦，今天就和小伙伴们随便扯扯 Spring 中的注入方式，因为我最近又要重新捡起 Spring 源码分析了，所以先来个简单的预热一下哈哈～
推荐阅读：
缓存和数据库一致性问题，看这篇就够了搞懂异地多活，看这篇就够了聊聊分布式锁——Redis和Redisson的方式看一遍就理解：MVCC原理详解
欢迎关注微信公众号：互联网全栈架构，收取更多有价值的信息。