最近在开发一个Spring Boot项目时，遇到了一个令人困扰的启动问题：
text
*************************** APPLICATION FAILED TO START *************************** Description: The dependencies of some of the beans in the application context form a cycle: ┌──->──┐ | userController defined in file [UserController.class] └──<-──┘
这种循环依赖错误看似简单，但在实际排查过程中，我却发现了一个与@Lazy注解相关的深坑。本文将详细记录整个排查过程和解决方案。
循环依赖的基本原理
在深入问题之前，我们先简单了解Spring中的循环依赖处理机制。
Spring通过三级缓存解决setter注入和字段注入的循环依赖：
一级缓存：存放完整的Bean实例
二级缓存：存放早期的Bean引用（半成品）
三级缓存：存放Bean工厂，用于生成早期引用
当出现A依赖B，B依赖A的情况时，Spring的处理流程如下：
java
// 简化的循环依赖处理流程 1. 开始创建A -> 实例化A -> 将A的工厂放入三级缓存 2. 填充A的属性 -> 发现需要B -> 开始创建B 3. 实例化B -> 将B的工厂放入三级缓存 4. 填充B的属性 -> 发现需要A -> 从三级缓存获取A的早期引用 5. 完成B的创建 -> 将B放入一级缓存 6. 继续填充A的属性 -> 完成A的创建
问题场景还原
在我的项目中，有一个相对复杂的依赖关系：
java
@Service
public class UserService {
private final RoleService roleService;
public UserService(RoleService roleService) {
this.roleService = roleService;
}
}
@Service
public class RoleService {
private final PermissionService permissionService;
public RoleService(PermissionService permissionService) {
this.permissionService = permissionService;
}
}
@Service
public class PermissionService {
private final UserService userService;
public PermissionService(UserService userService) {
this.userService = userService;
}
}
这形成了一个循环依赖链：UserService → RoleService → PermissionService → UserService
第一尝试：使用@Lazy注解
面对循环依赖，我的第一反应是使用@Lazy注解来打破循环：
java
@Service
public class PermissionService {
private final UserService userService;
public PermissionService(@Lazy UserService userService) {
this.userService = userService;
}
}
理论上，@Lazy应该延迟UserService的实际代理创建，从而打破循环。但出乎意料的是，应用仍然启动失败，只是错误信息发生了变化。
深入排查：@Lazy的实际行为
经过深入调试和查阅Spring源码，我发现@Lazy注解在某些情况下的行为与预期不符。
@Lazy的工作原理
当使用@Lazy时，Spring会创建一个代理对象而不是实际的目标对象。这个代理对象只有在第一次实际使用时才会初始化真正的Bean。
java
// Spring创建Lazy代理的简化逻辑
public Object getEarlyBeanReference(String beanName, Object bean) {
// 如果Bean标记为@Lazy，创建代理
if (isLazy(beanName)) {
return createLazyProxy(beanName);
}
return bean;
}
问题根源：多层循环依赖中的@Lazy
在我的场景中，问题在于循环依赖链有多层，而我只在一处添加了@Lazy注解。实际上，在多层循环依赖中，需要在所有循环点正确配置@Lazy才能有效解决问题。
正确的解决方案
方案一：全面配置@Lazy
在所有形成循环的点都添加@Lazy注解：
java
@Service
public class UserService {
private final RoleService roleService;
public UserService(@Lazy RoleService roleService) {
this.roleService = roleService;
}
}
@Service
public class RoleService {
private final PermissionService permissionService;
public RoleService(@Lazy PermissionService permissionService) {
this.permissionService = permissionService;
}
}
@Service
public class PermissionService {
private final UserService userService;
public PermissionService(@Lazy UserService userService) {
this.userService = userService;
}
}
方案二：重构代码消除循环依赖
更根本的解决方案是重构代码，消除循环依赖。这通常可以通过以下几种方式：
提取公共逻辑到新服务
使用事件驱动架构
应用接口分离原则
例如，将UserService中需要被PermissionService使用的功能提取到一个新的服务中：
java
// 提取公共功能到新服务
@Service
public class UserPermissionService {
// 原UserService中与权限相关的方法
}
// 修改PermissionService，依赖UserPermissionService而不是UserService
@Service
public class PermissionService {
private final UserPermissionService userPermissionService;
public PermissionService(UserPermissionService userPermissionService) {
this.userPermissionService = userPermissionService;
}
}
方案三：使用setter注入替代构造器注入
在某些情况下，使用setter注入可以缓解循环依赖问题：
java
@Service
public class PermissionService {
private UserService userService;
@Autowired
public void setUserService(UserService userService) {
this.userService = userService;
}
}
但需要注意的是，这并不能从根本上解决循环依赖，只是利用了Spring的不同注入时机。
深入理解：为什么@Lazy有时会失效
通过阅读Spring源码和调试，我发现@Lazy在以下情况下可能无法正常工作：
多个循环依赖点只有部分使用@Lazy：在多层循环中，所有循环点都需要正确配置
与@Transactional等其他代理注解组合使用：多个代理注解可能导致意外的代理行为
在配置类中使用@Bean定义的Bean：@Lazy的行为可能与预期不同
最佳实践建议
尽量避免循环依赖：循环依赖通常是设计问题的标志
如果必须使用循环依赖，全面配置@Lazy：确保所有循环点都正确标注
优先使用构造器注入：这能更早暴露设计问题
定期使用ArchUnit等工具检查架构：预防循环依赖的产生
java
// ArchUnit测试示例，禁止循环依赖
@ArchTest
static final ArchRule no_cycles =
slices().matching("com.example.(*)").should().beFreeOfCycles();
总结
Spring Boot中的循环依赖问题看似简单，但在复杂依赖链和@Lazy注解的交互下，可能变得相当棘手。通过本次排查，我深刻认识到：
不要过度依赖@Lazy：它应该是最后的手段，而不是首选方案
理解底层原理很重要：明白Spring如何处理循环依赖和
@Lazy的工作机制代码设计优于框架技巧：良好的设计可以避免大多数循环依赖问题
希望通过本文的分享，能帮助大家更好地理解和解决Spring Boot中的循环依赖问题，避免踩进类似的坑。