JAVA Bean 循环依赖？@Lazy 与构造注入冲突分析

大家好，今天我们来深入探讨一个在 Spring 框架中经常遇到的问题：Java Bean 的循环依赖，以及当 @Lazy 注解与构造器注入结合使用时可能产生的冲突。希望通过这次讲座，大家能够对循环依赖的本质、解决方案以及 @Lazy 在其中的作用有更清晰的理解。

什么是循环依赖？

循环依赖指的是两个或多个 Bean 之间互相依赖，形成一个闭环。例如，Bean A 依赖 Bean B，Bean B 又依赖 Bean A。这种情况下，Spring 在创建 Bean 的过程中会遇到问题，因为它无法先完整地创建 A，因为 A 依赖 B；也无法先完整地创建 B，因为 B 依赖 A。

以下是一个简单的循环依赖示例：

@Component
public class BeanA {

    private final BeanB beanB;

    @Autowired
    public BeanA(BeanB beanB) {
        this.beanB = beanB;
    }

    public void doSomething() {
        System.out.println("BeanA is doing something, using BeanB: " + beanB.getMessage());
    }
}

@Component
public class BeanB {

    private final BeanA beanA;

    @Autowired
    public BeanB(BeanA beanA) {
        this.beanA = beanA;
    }

    public String getMessage() {
        return "Hello from BeanB";
    }
}

在这个例子中，BeanA 通过构造器注入依赖 BeanB，而 BeanB 又通过构造器注入依赖 BeanA，形成了一个循环依赖。

循环依赖的类型

循环依赖主要可以分为以下几种类型：

构造器注入的循环依赖： 如上面的例子所示，两个或多个 Bean 通过构造器互相依赖。这是最难解决的一种循环依赖。
Setter 注入的循环依赖： 两个或多个 Bean 通过 Setter 方法互相依赖。
字段注入的循环依赖： 两个或多个 Bean 通过字段直接互相依赖。

Spring 如何解决循环依赖（部分情况）

Spring 解决循环依赖的手段主要依赖于三级缓存：

singletonFactories： 用于存放 Bean 的 ObjectFactory，它能够延迟 Bean 的创建，并允许在其他 Bean 需要该 Bean 时再进行创建。
earlySingletonObjects： 用于存放提前暴露的 Bean 对象，这些对象可能还未完成所有属性的注入，但已经可以被其他 Bean 引用。
singletonObjects： 用于存放完全初始化好的 Bean 对象。

当 Spring 容器创建 Bean A 时，首先会创建一个 Bean A 的实例（半成品），然后将 Bean A 的 ObjectFactory 放入 singletonFactories 中。如果 Bean A 需要依赖 Bean B，Spring 容器会尝试创建 Bean B。同样，如果 Bean B 需要依赖 Bean A，Spring 容器会先从 earlySingletonObjects 查找 Bean A，如果找不到，则从 singletonFactories 查找 Bean A 的 ObjectFactory 并创建 Bean A（半成品）放入 earlySingletonObjects。这样，Bean B 就可以使用 Bean A 了。当 Bean B 完成创建后，Bean A 就可以使用 Bean B 完成创建。最后，将Bean A和BeanB都放入singletonObjects。

注意： 这种方式仅适用于 Setter 注入和字段注入的循环依赖，无法解决构造器注入的循环依赖。

构造器注入与循环依赖的冲突

使用构造器注入时，Spring 无法通过三级缓存来解决循环依赖。这是因为构造器是 Bean 创建过程中必须执行的步骤，如果 Bean A 的构造器依赖 Bean B，而 Bean B 的构造器又依赖 Bean A，Spring 无法先创建 Bean A 的半成品，因为创建 Bean A 的半成品也需要 Bean B。

在这种情况下，Spring 会抛出 BeanCurrentlyInCreationException 异常，表明存在循环依赖。

@Lazy 的作用

@Lazy 注解可以延迟 Bean 的初始化。也就是说，当 Spring 容器启动时，不会立即创建被 @Lazy 注解的 Bean，而是等到第一次使用该 Bean 时才进行创建。

@Lazy 在解决循环依赖方面有一定的作用，但并不是万能的。特别是与构造器注入结合使用时，情况会变得复杂。

@Lazy 与构造器注入的冲突分析

当 @Lazy 与构造器注入结合使用时，可能会出现以下情况：

可以解决循环依赖： 如果循环依赖的两个 Bean 都被 @Lazy 注解，Spring 容器在启动时不会立即创建这两个 Bean，而是等到第一次使用它们时才进行创建。这样，就可以避免在创建过程中出现循环依赖的问题。
```
@Component
public class LazyBeanA {

    private final LazyBeanB lazyBeanB;

    @Autowired
    public LazyBeanA(@Lazy LazyBeanB lazyBeanB) {
        this.lazyBeanB = lazyBeanB;
    }

    public void doSomething() {
        System.out.println("LazyBeanA is doing something, using LazyBeanB: " + lazyBeanB.getMessage());
    }
}

@Component
public class LazyBeanB {

    private final LazyBeanA lazyBeanA;

    @Autowired
    public LazyBeanB(@Lazy LazyBeanA lazyBeanA) {
        this.lazyBeanA = lazyBeanA;
    }

    public String getMessage() {
        return "Hello from LazyBeanB";
    }
}
```
在这个例子中，LazyBeanA 和 LazyBeanB 都被 @Lazy 注解，并且通过构造器注入互相依赖。 Spring 容器在启动时不会立即创建这两个 Bean，而是等到第一次调用 doSomething() 或 getMessage() 方法时才进行创建。这样就可以避免循环依赖的问题。需要注意的是，这里需要在构造器的参数上使用 @Lazy 注解，否则 Spring 仍然会尝试立即创建 Bean。
仍然可能出现循环依赖： 即使使用了 @Lazy 注解，如果其中一个 Bean 在其他非懒加载的 Bean 中被直接引用，仍然可能导致循环依赖。
```
@Component
public class EagerBean {

    private final LazyBeanA lazyBeanA;

    @Autowired
    public EagerBean(LazyBeanA lazyBeanA) {
        this.lazyBeanA = lazyBeanA;
    }

    public void doSomething() {
        System.out.println("EagerBean is doing something, using LazyBeanA: " + lazyBeanA.getMessage());
    }
}
```
在这个例子中，EagerBean 不是懒加载的，它在创建时会立即尝试注入 LazyBeanA。由于 LazyBeanA 又依赖 LazyBeanB，而 LazyBeanB 又依赖 LazyBeanA，因此仍然会触发循环依赖。
引发意外的代理行为: @Lazy实际上创建了一个代理对象。虽然在注入的时候不会立刻初始化Bean，但是当使用该Bean时，Spring会通过代理去访问真实的Bean。如果对代理对象的使用方式不当，可能会导致一些意想不到的行为，例如多次初始化Bean。

替代方案：使用接口

解决构造器注入导致的循环依赖，一个更可靠的方法是使用接口。通过接口，我们可以将 Bean 之间的直接依赖关系解耦，从而避免循环依赖。

public interface BeanAInterface {
    void doSomething();
}

@Component
public class BeanA implements BeanAInterface {

    private final BeanBInterface beanB;

    @Autowired
    public BeanA(BeanBInterface beanB) {
        this.beanB = beanB;
    }

    @Override
    public void doSomething() {
        System.out.println("BeanA is doing something, using BeanB: " + beanB.getMessage());
    }
}

public interface BeanBInterface {
    String getMessage();
}

@Component
public class BeanB implements BeanBInterface {

    private final BeanAInterface beanA;

    @Autowired
    public BeanB(BeanAInterface beanA) {
        this.beanA = beanA;
    }

    @Override
    public String getMessage() {
        return "Hello from BeanB";
    }
}

在这个例子中，BeanA 和 BeanB 分别实现了 BeanAInterface 和 BeanBInterface 接口。它们之间通过接口进行依赖，而不是直接依赖具体的 Bean 类。这样，Spring 容器就可以先创建 BeanA 和 BeanB 的实例，然后将它们注入到对方的接口中，从而避免循环依赖。

总结各种解决循环依赖的方法

以下表格总结了解决循环依赖的各种方法以及它们的适用场景：

方法	适用场景	优点	缺点
Setter 注入/字段注入	存在 Setter 方法或可以直接访问字段	Spring 默认支持，无需额外配置	代码可读性较差，难以保证 Bean 的完整性
`@Lazy` 注解	循环依赖的 Bean 不需要立即初始化	可以延迟 Bean 的创建，避免循环依赖	可能导致意外的代理行为，如果一个 Bean 在非懒加载的 Bean 中被直接引用，仍然可能导致循环依赖
使用接口	所有循环依赖的 Bean 都实现了接口	可以解耦 Bean 之间的直接依赖关系，避免循环依赖	需要定义接口，增加代码量
重新设计代码	以上方法均无法解决，或者使用起来过于复杂	从根本上消除循环依赖，提高代码的可维护性	可能需要对现有代码进行较大的改动

最佳实践

尽量避免循环依赖： 循环依赖往往是设计不良的标志。应该尽量避免循环依赖，通过重新设计代码来消除它们。
优先使用构造器注入： 构造器注入可以保证 Bean 的完整性，应该优先使用。
谨慎使用 @Lazy： @Lazy 注解可以解决一些循环依赖问题，但可能会导致意外的代理行为。应该谨慎使用，并确保理解其工作原理。
使用接口： 如果无法避免循环依赖，可以考虑使用接口来解耦 Bean 之间的依赖关系。

循环依赖不是银弹，解耦才是王道

总而言之，循环依赖是一个复杂的问题，需要根据具体情况选择合适的解决方案。 @Lazy 注解可以解决一些循环依赖问题，但并不是万能的。最佳实践是尽量避免循环依赖，通过重新设计代码来消除它们。使用接口也是一个不错的选择，可以解耦 Bean 之间的依赖关系。只有彻底理解循环依赖的本质，才能有效地解决它们。

避免循环依赖：设计上的考量

循环依赖通常是代码设计问题的体现。在设计 Bean 之间的关系时，应该尽量遵循以下原则：

单一职责原则： 每个 Bean 应该只负责一个明确的职责。如果一个 Bean 承担了过多的职责，就可能导致它需要依赖其他 Bean，从而产生循环依赖。
依赖倒置原则： 高层模块不应该依赖底层模块，二者都应该依赖抽象。抽象不应该依赖细节，细节应该依赖抽象。通过依赖抽象（接口），可以解耦 Bean 之间的依赖关系，避免循环依赖。
组合优于继承： 尽量使用组合来构建复杂的对象，而不是使用继承。继承关系可能会导致循环依赖。

总结：理解循环依赖，选择最佳方案

我们讨论了 Java Bean 循环依赖的本质、类型、Spring 的解决方案以及 @Lazy 注解的作用。重点强调了构造器注入与 @Lazy 的冲突，并提供了使用接口作为替代方案。

记住：好的设计是避免循环依赖的根本

最终，解决循环依赖问题的关键在于良好的代码设计。避免循环依赖的最佳方法是遵循设计原则，解耦 Bean 之间的依赖关系。只有这样，才能编写出高质量、可维护的代码。