接上一篇《邪恶的字段注入》,再谈谈构造器注入。

上一篇《邪恶的字段注入》主要是针对随处可见的字段注入现状提出了批评,并强烈推荐使用构造器注入。在历数各种字段注入的缺点,也就是相对来说使用构造器注入的优点后,只发现了 java 世界里构造器注入的一个缺点,那就是得多写点代码(当然也以 js 工程师的角度,对 java 工程师进行了劝退,因为 js 的构造器注入连这个仅有的缺点都没有)。

但是实际上,即便在 java 的世界里需要多写点代码,也根本不是问题,因为有 IDE 来帮忙。那还等什么,快来改造吧!

怎么做

将光标定位到字段注入代码处,按下 Alt + Enter:
image.png

在弹出的 popup 里选择第一个,回车,就自动完成了字段注入到构造器注入的改造:
image.png
可以看到,使用构造器注入,连 @Autowired 关键字都可以省略。

构造器注入还有什么缺点?

上面用 IDE 的强大功能抵消了《邪恶的字段注入》中提到的构造器注入的唯一缺点,不过仍然有人不喜欢构造器注入,说原因是构造器注入在极端情况下有循环依赖异常问题。但是对于循环依赖,就可以使用字段注入,并且是 Spring 官方文档推荐的方式。似乎 ——

构造器注入不如字段注入强大。

这其实也是误解了。首先,对于循环依赖,这是明显的代码坏味道,应该首先反思设计,是不是有明显的 BUG?这里涉及到一个价值观问题,对于缺陷或者异常,是尽早暴露出来 fail fast,还是尽量把问题隐藏得越久越好?我站在 fail fast 这一边,所以我认为,构造器注入即使不如字段注入强大也不要紧,因为这个时候首先应该反思代码设计。

但是,构造器注入并非不如字段注入强大,通过在构造器注入里使用 @Lazy 注解,也可以解决循环依赖异常问题。

总结:无论什么场景,构造器注入都优于字段注入。


以下详细说说循环依赖的异常问题:

什么是循环依赖?

当 bean A 依赖 bean B,并且 bean B 也依赖 bean A 时,就产生了循环依赖:

Bean A -> Bean B -> Bean A

当然,有时候这种循环依赖比较含蓄(隐藏得比较深):

Bean A -> Bean B -> Bean C -> Bean D -> Bean E -> Bean A

Spring 中发生了什么?

当 Spring 上下文加载所有 bean 时,会依照一定的顺序创建 bean 从而使得他们可以完全工作。对于没有循环依赖的情况,比如这样的依赖关系:

Bean A -> Bean B -> Bean C

Spring 会先创建 bean C,然后是 bean B(同时将 bean C 注入 B),最后创建 bean A(同时把 bean B 注入 A)。

但是当有循环依赖时,Spring 无法决定那个 bean 应该最先被创建出来,因为它们相互依赖。在这样的情况下,Spring 只好在加载上下文时抛出 _BeanCurrentlyInCreationException _异常。

当然,这种异常只会在你使用构造器注入时抛出;如果使用别的注入方式的话,由于依赖只会在它们实际被使用时而非在上下文加载时被注入,所以不会有异常抛出。

举个例子

定义两个互相依赖的 bean,并且使用构造器注入:

java @Component public class CircularDependencyA {

private CircularDependencyB circB;

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

}

java @Component public class CircularDependencyB {

private CircularDependencyA circA;

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

}

接着我们写一个配置类用来测试,就命名为 TestConfig 吧,它指定了扫描组件的基准包名。假设上面的 bean 定义在包“com.hardway.circular”里:

java @Configuration @ComponentScan(basePackages = { com.hardway.circular }) public class TestConfig { }

最后我们写一个 JUnit 测试来检查循环依赖。测试可以是空的,因为我们只要触发上下文加载即可检测到循环依赖。

java @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(classes = { TestConfig.class }) public class CircularDependencyTest {

@Test
public void givenCircularDependency_whenConstructorInjection_thenItFails() {
    // 测试可以是空的,因为我们只要触发上下文加载即可检测到循环依赖。
}

}

尝试运行测试,得到如下异常:

shell BeanCurrentlyInCreationException: Error creating bean with name circularDependencyA: Requested bean is currently in creation: Is there an unresolvable circular reference?

绕过的方法


前面说了,发生循环依赖,首先应该重新思考代码设计。不过这里还是完整地列出所有可以绕过异常的办法。

重新设计

如果发生循环依赖,很有可能出现了设计问题:职责划分不合理。这时候应该重新设计组件让它们的层次结构变得合理和良好,从而不需要循环依赖。

如果真的因为某些原因不能重新设计组件(比如遗留代码、不允许被修改的代码、没时间没资源做完整的重新设计等……),那么你可以尝试:

使用 @Lazy

打破环的简单办法是让 Spring 对 bean 进行懒惰的初始化,即:不要完全初始化 bean,而是创建一个代理来将它注入到其他 bean 中。被注入的 bean 仅仅在第一次被使用时才会完全初始化。

比如你可以把前面的组件 CircularDependencyA 改造成这样:

java @Component public class CircularDependencyA {

private CircularDependencyB circB;

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

}

如果你再次运行测试,就会看到错误不见了。

使用设置器/字段注入

Spring 官方文档提出的,也是最流行的(但是我不推荐)绕过方式是使用设置器注入。简单来说就是你将 bean 们的缠绕方式从构造器注入改成设置器注入(或者字段注入),就能搞定问题。通过这个方式 Spring 只创建 bean,但是在依赖被真正用到之前都不会事先注入。

我们可以把前面的例子中的类改成使用设置器注入,然后添加另一个 message 字段到 CircularDependencyB 中以便于写一个合适的单元测试:

java @Component public class CircularDependencyA {

private CircularDependencyB circB;

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

public CircularDependencyB getCircB() {
    return circB;
}

}


java @Component public class CircularDependencyB {

private CircularDependencyA circA;

private String message = Hi!;

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

public String getMessage() {
    return message;
}

}


单元测试改成这样:

java @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(classes = { TestConfig.class }) public class CircularDependencyTest {

@Autowired
ApplicationContext context;

@Bean
public CircularDependencyA getCircularDependencyA() {
    return new CircularDependencyA();
}

@Bean
public CircularDependencyB getCircularDependencyB() {
    return new CircularDependencyB();
}

@Test
public void givenCircularDependency_whenSetterInjection_thenItWorks() {
    CircularDependencyA circA = context.getBean(CircularDependencyA.class);

    Assert.assertEquals(Hi!, circA.getCircB().getMessage());
}

}


上面用到一些注解,解释如下:

@Bean: 告诉 Spring 框架必须使用这些方法来获取需要被注入的 bean 的实现。
@Test: 测试要从上下文中获取 CircularDependencyA 这个 bean,然后断言它的 CircularDependencyB 已经被稳妥地注入了,并检查它的 message 属性的值。

使用 @PostConstruct


另一个打破环的方式是通过在众多 bean 中的其中一个上面应用 @Autowired 来注入依赖,然后在一个方法上面应用 @PostConstruct 注解来设置其他的依赖。

比如有这样的 bean 相关的代码:

java @Component public class CircularDependencyA {

@Autowired
private CircularDependencyB circB;

@PostConstruct
public void init() {
    circB.setCircA(this);
}

public CircularDependencyB getCircB() {
    return circB;
}

}

java @Component public class CircularDependencyB {

private CircularDependencyA circA;

private String message = Hi!;

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

public String getMessage() {
    return message;
}

}


然后可以运行之前写好的同样的测试,你可以看到依赖能够被稳妥地注入并且不会抛出循环依赖异常。

实现 ApplicationContextAware 和 InitializingBean

如果有 bean 实现了 ApplicationContextAware,则这个 bean 就能够访问 Spring 上下文并能够从中抽取到其他的 bean。而通过实现 InitializingBean 可以指示这个 bean 在当其所有的属性都被设置好后必须执行一些动作;在这个场景下我们手动设置依赖。

bean 相关的代码像这样:

java @Component public class CircularDependencyA implements ApplicationContextAware, InitializingBean {

private CircularDependencyB circB;

private ApplicationContext context;

public CircularDependencyB getCircB() {
    return circB;
}

@Override
public void afterPropertiesSet() throws Exception {
    circB = context.getBean(CircularDependencyB.class);
}

@Override
public void setApplicationContext(final ApplicationContext ctx) throws BeansException {
    context = ctx;
}

}

java @Component public class CircularDependencyB {

private CircularDependencyA circA;

private String message = Hi!;

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

public String getMessage() {
    return message;
}

}

再一次运行之前的测试可以验证仍然能够通过并且没有异常。

总结

本文接续《邪恶的字段注入》,强烈推荐使用构造器注入,并且手把手地讲解了如何将字段注入改造成构造器注入,以及反驳了构造器注入不如字段注入的观点。同时对循环依赖这个极端场景进行了举例说明,列举了所有可能的绕过方法,并展示了通过 @Lazy 注解,构造器注入仍然优于字段注入,但是最优的方案是重新设计代码,因为出现循环依赖是一个设计缺陷的表征。

尽管 Spring 官方文档更喜欢用设置器注入和字段注入,但是我仍然更加推崇构造器注入。因为设置器/字段注入以及其他的几种绕过方法基本上都是阻拦了 Spring 对 bean 的初始化和注入的管理,然后手动来进行,这违背了使用 Spring 的初衷。