【一文看懂Spring循环依赖】Spring循环依赖：从陷阱破局到架构涅槃

🌪️ Spring Boot循环依赖：从陷阱破局到架构涅槃

循环依赖如同莫比乌斯环上的蚂蚁，看似前进却永远困在闭环中。本文将带你拆解Spring中这一经典难题，从临时救火到根治重构，构建无懈可击的依赖体系。

🔥 一、致命闭环：当依赖链开始打结

📍 1. 循环依赖的三种形态

构造器死锁（无解型）

java 复制代码

@Service
public class OrderService {
    private final UserService userService;
    public OrderService(UserService userService) { // 启动即崩溃
        this.userService = userService; 
    }
}

@Service
public class UserService {
    private final OrderService orderService;
    public UserService(OrderService orderService) { // 相互等待初始化
        this.orderService = orderService; 
    }
}

致命点 ：Spring无法通过三级缓存提前暴露Bean，直接抛出BeanCurrentlyInCreationException

字段/Setter依赖 （可救型）

通过三级缓存机制可解：

实例化OrderService 暴露早期引用到三级缓存注入UserService时实例化UserService UserService从缓存拿到OrderService早期引用 UserService初始化完成 OrderService注入完整UserService
异步方法闭环 （隐蔽型）
@Async或@Transactional生成的代理对象会干扰依赖注入流程，导致看似无循环的代码在运行时崩溃

🛠️ 二、破局五式：从应急到根治

🧪 1. 急救方案：@Lazy的妙用与陷阱

java 复制代码

@Service
public class OrderService {
    @Lazy  // 延迟注入关键注解
    @Autowired  
    private PaymentService paymentService; 
}

原理：生成代理对象占位，首次调用时初始化真实Bean，打破初始化死锁
风险警示：

过度使用导致代理对象泛滥，调用链复杂度指数级增长
与构造器注入结合可能引发NPE（代理对象未被触发初始化）

⚙️ 2. 依赖注入改造：Setter vs 构造器

Setter注入救场：

java 复制代码

@Service
public class OrderService {
    private PaymentService paymentService;
    @Autowired  // 避免构造器死锁
    public void setPaymentService(PaymentService ps) {
        this.paymentService = ps;
    }
}

本质差异：构造器注入要求依赖项在实例化时完备，Setter注入允许先创建空壳再填充

🧱 3. 架构重构：三大根治术

① 抽离公共层（依赖倒置）

java 复制代码

public interface PaymentProcessor { // 抽象接口
    void processPayment();
}

@Service 
public class AlipayProcessor implements PaymentProcessor {...} // 实现1

@Service 
public class WechatProcessor implements PaymentProcessor {...} // 实现2

@Service
public class OrderService {
    private final PaymentProcessor processor; // 依赖抽象
    public OrderService(PaymentProcessor processor) {...} 
}

优势：符合SOLID原则，彻底切断双向依赖

② 事件驱动（终极解耦）

java 复制代码

@Service
public class OrderService {
    @Autowired
    private ApplicationEventPublisher eventPublisher;
    
    public void createOrder() {
        eventPublisher.publishEvent(new OrderCreatedEvent(this)); // 发布事件
    }
}

@Service
public class InventoryService {
    @EventListener // 监听解耦
    public void reduceStock(OrderCreatedEvent event) {...} 
}

效果：订单服务与库存服务零直接依赖，通过事件总线通信

③ 门面模式（统一入口）

java 复制代码

@Service
public class OrderFacade { // 门面服务
    @Autowired private OrderService orderService;
    @Autowired private PaymentService paymentService;
    
    public void executeOrder() {
        orderService.create();
        paymentService.charge();
    }
}

适用场景：多服务强关联但需避免循环调用

⚠️ 三、避坑指南：那些雪上加霜的操作

配置允许循环依赖（饮鸩止渴）
properties 复制代码
```
spring.main.allow-circular-references=true # Spring Boot 2.6+前有效
```
后果：高版本默认禁用此配置，且掩盖设计缺陷
原型Bean(Prototype)的循环依赖

每次请求创建新实例，三级缓存失效，必须用@Lazy或重构

@PostConstruct中的隐式循环

java 复制代码

@Service
public class ServiceA {
    @Autowired ServiceB serviceB;
    @PostConstruct
    public void init() { 
        serviceB.register(this); // 触发ServiceB反向调用
    }
}

解决方案 ：改用ApplicationListener或事件驱动

🏆 四、最佳实践：让循环依赖无处遁形

防御性编码

强制构造器注入：启动时暴露问题 > 运行时崩溃

分层架构守护 ：

java 复制代码

// ArchUnit检测循环依赖
@ArchTest
static final ArchRule no_cycles = slices()
    .matching("com.yourapp.(*)..")
    .should().beFreeOfCycles();

依赖可视化监控

bash 复制代码

# 生成Bean依赖图
curl http://localhost:8080/actuator/beans | jq '.contexts.context.beans'

结合Spring Boot Actuator实时分析依赖链路

💎 结语：依赖的本质是契约

循环依赖的终极解决方案不在技术层面，而在架构认知。当我们用"服务能力"替代"服务调用"的视角设计系统时，模块间将自然形成单向流动的依赖河床。正如领域驱动设计中限界上下文（Bounded Context）的隔离艺术------每个上下文都是自治的王国，通过防腐层进行优雅的外交对话。

思考题：在微服务架构中，循环依赖会以怎样的形式存在？欢迎分享你的实战案例。