Spring Boot工厂方法循环依赖问题解决方案

1. 循环依赖问题背景与Spring Boot工厂方法特性

在Spring Boot应用开发中，Bean的创建与管理是框架最核心的功能之一。工厂方法模式作为一种经典的创建型设计模式，在Spring中被广泛用于复杂对象的实例化场景。不同于常规的@Component或@Bean声明方式，工厂方法通过静态或实例方法返回Bean实例，这种方式在应对复杂初始化逻辑时显得尤为灵活。

但正是这种灵活性带来了新的挑战——当两个或多个通过工厂方法创建的Bean相互依赖时，传统的三级缓存解决机制可能失效。我曾在一个电商库存系统中遇到过这样的案例：库存服务通过工厂方法创建时需要依赖促销服务，而促销服务的工厂方法又调用了库存服务的接口。系统启动时直接抛出BeanCurrentlyInCreationException，导致整个应用无法启动。

关键提示：Spring默认支持的循环依赖仅限于通过构造器注入和setter注入的简单场景，工厂方法模式下的循环依赖需要特殊处理。

工厂方法创建Bean的典型特征包括：

1. 延迟初始化特性：工厂方法往往包含业务判断逻辑，运行时才能确定是否创建实例
2. 非直接依赖关系：通过方法调用间接建立依赖链，Spring难以在启动时完整构建依赖图
3. 实例控制权转移：对象的创建过程从Spring转移到了工厂类中

2. 工厂方法循环依赖的产生机制

2.1 Spring正常Bean创建流程

常规Spring Bean的创建遵循明确的生命周期：

1. 实例化（Instantiation）：调用构造函数创建原始对象
2. 属性填充（Population）：注入依赖的其他Bean
3. 初始化（Initialization）：执行@PostConstruct等回调方法

在这个过程中，Spring通过三级缓存解决循环依赖：

• 一级缓存：存放完整初始化后的单例Bean
• 二级缓存：存放早期暴露的原始Bean（仅实例化未初始化）
• 三级缓存：存放Bean工厂对象，用于处理代理等情况

2.2 工厂方法模式下的异常流程

当使用工厂方法时，情况变得复杂。考虑以下典型代码：

java复制@Service
class ServiceA {
    @Autowired
    private ServiceB serviceB;
    
    public static ServiceA create() {
        return new ServiceA();
    }
}

@Service 
class ServiceB {
    @Autowired
    private ServiceA serviceA;
    
    public static ServiceB create() {
        return new ServiceB();
    }
}

这种情况下Spring的处理流程会经历：

1. 开始创建ServiceA，调用工厂方法create()
2. 发现需要注入ServiceB，暂停ServiceA的创建
3. 开始创建ServiceB，调用其工厂方法create()
4. 发现需要注入ServiceA，但此时ServiceA还处于创建中
5. 抛出BeanCurrentlyInCreationException

问题的核心在于：工厂方法打断了Spring对Bean创建过程的控制权，使得框架无法通过常规的三级缓存机制解决依赖问题。

3. 解决方案与实战策略

3.1 架构层面解耦

最彻底的解决方案是重新设计组件关系：

1. 提取公共逻辑到第三方服务
2. 使用事件驱动架构（Spring Events）
3. 引入门面模式统一服务访问

例如将上例改造为：

java复制@Service
class FacadeService {
    @Autowired
    private ServiceA serviceA;
    
    @Autowired 
    private ServiceB serviceB;
    
    // 对外提供统一接口
}

3.2 Spring技术解决方案

当架构调整不可行时，可采用以下技术方案：

3.2.1 @Lazy注解延迟加载

java复制@Service
class ServiceA {
    @Lazy
    @Autowired
    private ServiceB serviceB;
}

这种方式实质上是创建了代理对象，直到第一次实际使用时才会触发真实对象的初始化。

3.2.2 Setter注入替代字段注入

java复制@Service
class ServiceA {
    private ServiceB serviceB;
    
    @Autowired
    public void setServiceB(ServiceB serviceB) {
        this.serviceB = serviceB;
    }
}

Setter注入允许Bean先完成实例化，再解决依赖关系。

3.2.3 ApplicationContextAware接口

java复制@Service
class ServiceA implements ApplicationContextAware {
    private ServiceB serviceB;
    
    @Override
    public void setApplicationContext(ApplicationContext ctx) {
        this.serviceB = ctx.getBean(ServiceB.class);
    }
}

3.3 工厂方法特殊处理

对于必须使用工厂方法的场景，可以采用以下模式：

java复制@Component
class ServiceAFactory {
    @Lazy
    @Autowired
    private ServiceB serviceB;
    
    @Bean
    public ServiceA createServiceA() {
        ServiceA instance = new ServiceA();
        instance.setServiceB(serviceB);
        return instance;
    }
}

这种做法的关键点：

1. 将工厂类本身作为Spring组件管理
2. 在工厂内部处理依赖关系
3. 工厂方法返回完全初始化的实例

4. 深度原理分析与性能考量

4.1 Spring源码层面的处理机制

在DefaultSingletonBeanRegistry类中，关键的解决逻辑体现在：

java复制protected Object getSingleton(String beanName, boolean allowEarlyReference) {
    Object singletonObject = this.singletonObjects.get(beanName);
    if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
        synchronized (this.singletonObjects) {
            singletonObject = this.earlySingletonObjects.get(beanName);
            if (singletonObject == null && allowEarlyReference) {
                ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
                if (singletonFactory != null) {
                    singletonObject = singletonFactory.getObject();
                    this.earlySingletonObjects.put(beanName, singletonObject);
                    this.singletonFactories.remove(beanName);
                }
            }
        }
    }
    return singletonObject;
}

工厂方法模式的问题在于singletonFactories中可能不存在对应的ObjectFactory，导致无法完成早期引用。

4.2 性能影响评估

不同解决方案的性能表现对比：

5. 复杂场景下的最佳实践

5.1 多层级工厂方法依赖

对于多层工厂方法调用链，建议：

1. 使用@DependsOn明确依赖顺序
2. 结合@PostConstruct进行二次初始化
3. 采用接口隔离原则拆分大对象

示例代码：

java复制public interface Initializable {
    void initialize();
}

@Service
class ComplexService implements Initializable {
    private boolean initialized = false;
    
    @Override
    public void initialize() {
        // 延迟初始化逻辑
        initialized = true;
    }
}

@Component
class ComplexServiceFactory {
    @Bean
    @DependsOn("otherBean")
    public ComplexService createService() {
        return new ComplexService();
    }
}

5.2 原型作用域下的处理

当工厂方法返回原型Bean时，需要特别注意：

1. 每次调用工厂方法都会创建新实例
2. 解决方案是结合ObjectProvider：

java复制@Service
@Scope("prototype")
class PrototypeService {
    @Autowired
    private ObjectProvider<DependentService> dependentServiceProvider;
    
    public void execute() {
        DependentService service = dependentServiceProvider.getIfAvailable();
        // 使用service
    }
}

5.3 测试策略建议

针对工厂方法循环依赖的测试方案：

1. 使用@DirtiesContext确保测试隔离
2. 结合Mockito进行部分模拟
3. 重点测试初始化阶段

测试示例：

java复制@SpringBootTest
class FactoryBeanTests {
    @MockBean
    private ServiceB serviceBMock;
    
    @Autowired
    private ServiceA serviceA;
    
    @Test
    void testInitialization() {
        assertNotNull(serviceA);
        verify(serviceBMock, times(1)).someMethod();
    }
}

6. 常见问题排查指南

6.1 典型异常分析

6.2 日志分析技巧

在application.properties中增加：

properties复制logging.level.org.springframework.beans=DEBUG
logging.level.org.springframework.context=DEBUG

关键日志线索：

1. "Creating shared instance of singleton bean" - 正常创建流程
2. "Bean factory for type [...] is in creation" - 循环依赖标志
3. "Returning cached instance of singleton bean" - 正常解决依赖

6.3 工具辅助分析

1. 使用Spring Boot Actuator的/beans端点
2. 借助IDEA的Diagrams功能可视化依赖
3. 编写自定义BeanPostProcessor进行跟踪

跟踪处理器示例：

java复制@Component
public class DependencyTracker implements BeanPostProcessor {
    private static final Logger log = LoggerFactory.getLogger(DependencyTracker.class);
    
    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) {
        log.debug("Before init: {}", beanName);
        return bean;
    }
}

在实际项目中，工厂方法模式与Spring IoC容器的结合需要特别注意依赖管理。经过多个项目的实践验证，我总结出一个黄金法则：对于业务核心服务，尽量避免使用静态工厂方法创建Bean；对于工具类等无状态对象，可以安全使用工厂模式。当确实需要处理复杂依赖时，采用@Lazy+接口隔离的组合方案通常能取得最佳平衡。