循环依赖报错为什么给构造器参数加个 Lazy 就好了朋友的代码炸在启动阶段日志第一行是这个The dependencies of some of the beans in the application context form a cycle: ┌─────┐ | orderService defined in file [.../OrderService.class] ↑ ↓ | payService defined in file [.../PayService.class] └─────┘我让他给构造器参数加了个Lazy启动就过了。他更懵了加个注解循环依赖就没了一、构造器循环为什么必死两个 Service 互相依赖都用构造器注入ServicepublicclassOrderService{privatefinalPayServicepayService;publicOrderService(PayServicepayService){this.payServicepayService;}}ServicepublicclassPayService{privatefinalOrderServiceorderService;publicPayService(OrderServiceorderService){this.orderServiceorderService;}}Spring 的套路是先实例化再填充属性而构造器注入把这个顺序卡死了参数没凑齐new都执行不了。Spring: 创建 orderService │ new OrderService( ? ) ← payService 还没有 ▼ Spring: 创建 payService │ new PayService( ? ) ← orderService 也没有 ▼ Spring: 回头再要 orderService ✗ 还在创建中连个半成品实例都没留下 → BeanCurrentlyInCreationException关键就是最后一行Spring 手里连个半成品都没有。字段注入之所以没事是因为它先new出一个半成品丢进缓存回头有人来要就把这个半成品递过去构造器注入参数没齐就不能new缓存里空空的只能报错。顺便说一句Spring Boot 2.6 之后循环依赖默认就被禁止了但打开spring.main.allow-circular-references也救不了构造器循环——这不是允不允许的问题而是物理上没有半成品可给。二、Lazy 给的是一个空壳代理改动只有一行publicOrderService(LazyPayServicepayService){this.payServicepayService;}因为它注入的根本不是PayService而是一个代理空壳——没有业务逻辑只记着一句话“真身叫 payService用的时候去容器里取。”Spring: 创建 orderService │ new OrderService( 空壳代理 ) ← 有东西塞得进去构造器能执行 ▼ orderService 出生 ✅ payService 还没被创建也无所谓 ……很久以后业务代码调用 orderService.getPayService().pay()…… 代理被第一次戳醒 → getBean(payService) → 这时候才真正 new PayService │ ▼ payService 的构造器要找 orderService → 容器里早就有了 ✅一句话Lazy把创建 B从 A 的构造期推迟到了 A 使用 B 的那一刻。循环并没有被打断只是被拉平在时间轴上前后错开了。原理也就是一层窗户纸Spring 看到注入点上有Lazy就用ProxyFactory现场捏一个代理代理里挂着TargetSource它的getTarget()本质上就是一句getBean(targetBeanName)。接口走 JDK 动态代理类走 CGLIB 子类代理所以getClass()打出来多半是PayService$$EnhancerBySpringCGLIB$$...这种名字看到别慌。三、两个坑别在构造器里调用代理的方法。这一戳等于立刻要真身而对方回头又要你BeanCurrentlyInCreationException原地复活。代理是用的时候才生效不是随时都能用。写在类上的Lazy不管用。那是延迟初始化换的是什么时候创建不是注入什么。只有写在注入点构造器参数、字段、setter上才真的把注入物换成了空壳。另外它是止血带不是接骨药两个 Service 互相依赖往往说明职责切歪了——先让服务跑起来再腾出手把设计改干净。总结成一句话构造器注入要求依赖现成Lazy偏偏递给你一个不现成的空壳于是循环被推到了以后。
循环依赖报错为什么给构造器参数加个 Lazy 就好了朋友的代码炸在启动阶段日志第一行是这个The dependencies of some of the beans in the application context form a cycle: ┌─────┐ | orderService defined in file [.../OrderService.class] ↑ ↓ | payService defined in file [.../PayService.class] └─────┘我让他给构造器参数加了个Lazy启动就过了。他更懵了加个注解循环依赖就没了一、构造器循环为什么必死两个 Service 互相依赖都用构造器注入ServicepublicclassOrderService{privatefinalPayServicepayService;publicOrderService(PayServicepayService){this.payServicepayService;}}ServicepublicclassPayService{privatefinalOrderServiceorderService;publicPayService(OrderServiceorderService){this.orderServiceorderService;}}Spring 的套路是先实例化再填充属性而构造器注入把这个顺序卡死了参数没凑齐new都执行不了。Spring: 创建 orderService │ new OrderService( ? ) ← payService 还没有 ▼ Spring: 创建 payService │ new PayService( ? ) ← orderService 也没有 ▼ Spring: 回头再要 orderService ✗ 还在创建中连个半成品实例都没留下 → BeanCurrentlyInCreationException关键就是最后一行Spring 手里连个半成品都没有。字段注入之所以没事是因为它先new出一个半成品丢进缓存回头有人来要就把这个半成品递过去构造器注入参数没齐就不能new缓存里空空的只能报错。顺便说一句Spring Boot 2.6 之后循环依赖默认就被禁止了但打开spring.main.allow-circular-references也救不了构造器循环——这不是允不允许的问题而是物理上没有半成品可给。二、Lazy 给的是一个空壳代理改动只有一行publicOrderService(LazyPayServicepayService){this.payServicepayService;}因为它注入的根本不是PayService而是一个代理空壳——没有业务逻辑只记着一句话“真身叫 payService用的时候去容器里取。”Spring: 创建 orderService │ new OrderService( 空壳代理 ) ← 有东西塞得进去构造器能执行 ▼ orderService 出生 ✅ payService 还没被创建也无所谓 ……很久以后业务代码调用 orderService.getPayService().pay()…… 代理被第一次戳醒 → getBean(payService) → 这时候才真正 new PayService │ ▼ payService 的构造器要找 orderService → 容器里早就有了 ✅一句话Lazy把创建 B从 A 的构造期推迟到了 A 使用 B 的那一刻。循环并没有被打断只是被拉平在时间轴上前后错开了。原理也就是一层窗户纸Spring 看到注入点上有Lazy就用ProxyFactory现场捏一个代理代理里挂着TargetSource它的getTarget()本质上就是一句getBean(targetBeanName)。接口走 JDK 动态代理类走 CGLIB 子类代理所以getClass()打出来多半是PayService$$EnhancerBySpringCGLIB$$...这种名字看到别慌。三、两个坑别在构造器里调用代理的方法。这一戳等于立刻要真身而对方回头又要你BeanCurrentlyInCreationException原地复活。代理是用的时候才生效不是随时都能用。写在类上的Lazy不管用。那是延迟初始化换的是什么时候创建不是注入什么。只有写在注入点构造器参数、字段、setter上才真的把注入物换成了空壳。另外它是止血带不是接骨药两个 Service 互相依赖往往说明职责切歪了——先让服务跑起来再腾出手把设计改干净。总结成一句话构造器注入要求依赖现成Lazy偏偏递给你一个不现成的空壳于是循环被推到了以后。
