Spring Boot抽象服务类循环引用问题深度解析与解决方案

本文深入探讨了spring boot应用中，抽象服务类因尝试通过applicationcontext自注入获取代理实例，与外部服务依赖形成循环引用，导致启动失败的问题。文章详细分析了其根源，并提供了通过引入服务管理器（servicemanager）解耦复杂依赖，以及利用aop代理机制优化抽象服务类内部自注入策略的两种有效解决方案，旨在帮助开发者构建更健壮的spring应用。

引言：Spring Boot循环依赖的挑战与抽象服务类特殊场景

在Spring Boot应用开发中，循环依赖是一个常见但棘手的问题。当两个或多个Bean之间相互依赖，形成一个闭环时，Spring容器在初始化这些Bean时会遇到困难，从而抛出循环依赖错误。虽然Spring在某些情况下（如构造器注入的循环依赖）可以自动解决，但在涉及Bean生命周期回调（如@PostConstruct）或特定注入模式时，问题依然突出。

本文将聚焦于一种特殊场景：一个抽象服务类为了确保其内部方法调用能够经过Spring AOP代理（例如事务管理），尝试通过ApplicationContext自注入获取自身的代理实例。当这样的抽象服务类被其他服务依赖时，这种自注入行为可能与外部依赖链条共同形成循环引用，导致应用启动失败。

问题剖析：抽象服务类的自注入陷阱

让我们来看一个典型的抽象服务类结构，它尝试在初始化阶段获取自身的代理实例：

public abstract class AbstractTransactionalService {

    @Autowired
    private ApplicationContext applicationContext;

    private AbstractTransactionalService me;

    @SuppressWarnings("unchecked")
    @PostConstruct
    public void init() {
        // 尝试从ApplicationContext中获取自身的Bean实例
        me = applicationContext.getBean(this.getClass());
    }

    public Response performService(final Request request, final Class exceptionClass)
            throws Exception {
        try {
            // 通过获取到的代理实例调用perform方法，以确保事务等AOP功能生效
            final Response response = this.me.perform(request);
            return response;
        } catch (final Exception e) {
            // 异常处理
            // ...
        }
    }

    public abstract Response perform(Request request) throws Exception;
}

假设现在有一个具体服务 Service2 继承了 AbstractTransactionalService，并且另一个服务 Service1 通过 @Autowired 注入了 Service2。

@Service
public class Service1 {
    @Autowired
    private Service2 service2; // Service1 依赖 Service2

    // ... 其他业务逻辑
}

@Service
public class Service2 extends AbstractTransactionalService {
    // ... Service2 实现了 perform 方法
    @Override
    public MyResponse perform(MyRequest request) throws MyException {
        // ... 具体的业务逻辑
        return new MyResponse();
    }
}

根本原因分析：

当Spring容器启动并尝试初始化 Service1 时，它会发现 Service1 依赖于 Service2，于是开始创建 Service2。在 Service2 的创建过程中，其父类 AbstractTransactionalService 中的 @PostConstruct 注解的 init() 方法会被调用。此时，init() 方法内部尝试通过 applicationContext.getBean(this.getClass()) 获取 Service2 的实例。

问题在于，Service2 此时正处于创建过程中，尚未完全初始化并注册到Spring容器中作为一个完整的、可用的Bean（特别是其AOP代理可能尚未生成）。在这种情况下，尝试通过 getBean() 获取自身，可能会导致以下几种情况：

社研通

文科研究生的学术加速器

下载

1. Bean未完全初始化错误： 如果Spring容器检测到正在尝试获取一个尚在创建中的Bean，它会抛出异常，提示循环依赖。
2. 获取到原始Bean而非代理： 即使没有直接的循环依赖错误，getBean() 在某些情况下也可能返回原始的 Service2 实例，而不是其期望的AOP代理实例。这将导致 this.me.perform(request) 调用时，事务等AOP功能失效。

这种自注入模式的初衷是为了确保 perform() 方法能够通过Spring AOP代理执行，从而应用事务、安全等横切关注点。然而，其实现方式在Bean生命周期中存在潜在的循环依赖风险。

解决方案一：引入服务管理器（ServiceManager）解耦复杂依赖

当多个服务之间存在相互依赖，或间接依赖导致循环时，引入一个中央协调器——服务管理器（ServiceManager）是一种通用且有效的解决方案。它通过将所有相互依赖的服务注入到一个独立的Manager Bean中，然后其他服务通过Manager获取所需实例，从而打破直接的循环引用。

核心思想：

将参与循环依赖的服务从直接相互注入，转变为都注入到一个中间的 ServiceManager 中。这样，原本的直接循环依赖被转换为单向依赖：所有服务都依赖 ServiceManager，而 ServiceManager 内部持有所有服务的实例。

实现步骤：

1. **创建 ServiceManager