主题 09Spring IOC 与循环依赖

9.1面试官问 Spring 时，真正在问什么

Spring 是唯一一门「用得最多、说得最浅」的技术。日常开发里你只需要会写 @Service / @Autowired，但面试要的是容器内部的因果链： 为什么这么设计、不这么设计会怎样、出问题时报什么错。

9.2容器替你做的三件事：读图纸、造对象、塞依赖

先看不用容器时，一个典型的三层调用要写多少废话：

// 手工装配：每一层都得自己 new，还得自己保证"只 new 一次"
UserDao dao = new UserDaoImpl(new DataSource(...));
UserService service = new UserServiceImpl(dao, new MailSender(...));
OrderService order = new OrderServiceImpl(service, dao);
// 明天 DataSource 要换连接池？—— 上面每一行都得改

容器做的事可以一句话概括：把「对象图」从代码里搬到注解/配置里，由容器按图施工。 关键在「按图」两个字——容器不是随手 new，它先把所有声明解析成 BeanDefinition（图纸），再照着图纸造。

9.3refresh() 十四步里，真正干活的是这四步

AbstractApplicationContext.refresh() 有十四步，面试让你全背下来是耍流氓。真正和「Bean 从哪来」相关的只有四步：

这四步的耗时分布很反直觉。实验 1 的日志里，A 的构造器直到第 599 毫秒才打印：

=== case1 setter 循环依赖 ===
[   1.2ms] refresh() 开始
[ 599.1ms] A  -> 构造器执行完毕（此时 b 仍为 null）
[ 648.5ms] B  -> 构造器执行完毕（此时 a 仍为 null）
[ 658.1ms] B  -> setA 注入 A@2096194236
[ 663.1ms] A  -> setB 注入 B@655713354
[ 679.2ms] refresh() 结束

前 599 毫秒一个业务 Bean 都没造——全花在加载 Spring 自己的类、解析注解、注册后置处理器上。 而同一份代码里的第四个容器（实验 6）只要 4.1 毫秒：

=== case6 单例 vs 原型 ===
[   0.0ms] refresh() 开始
[   4.1ms] refresh() 结束

9.4一条 Bean 的流水线：doCreateBean 五步

getBean() 最终落到 AbstractAutowireCapableBeanFactory.doCreateBean()。五个动作，顺序固定：

protected Object doCreateBean(String beanName, RootBeanDefinition mbd, Object[] args) {
    // 1. 实例化：只调构造器，此时所有字段都是默认值
    Object bean = createBeanInstance(mbd, beanName, args);

    // 2. 提前暴露：把"造好但没填完"的对象包装成 ObjectFactory 放进第三级缓存
    //    —— 循环依赖能不能解，全看这一步在不在、在什么时候
    if (earlySingletonExposure) {
        addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
    }

    // 3. 填充属性：解析 @Autowired，把依赖塞进去（这里可能递归触发别的 Bean 创建）
    populateBean(beanName, mbd, bean);

    // 4. 初始化（顺序固定）：
    //    Aware -> BPP.before -> @PostConstruct -> afterPropertiesSet -> initMethod -> BPP.after
    Object exposedObject = initializeBean(beanName, bean, mbd);

    // 5. 注册销毁回调，等容器 close() 时按逆序执行
    registerDisposableBeanIfNecessary(beanName, bean, mbd);
    return exposedObject;
}

第 1 步和第 3 步的分离，是 Spring 能解决循环依赖的唯一前提： 对象可以「先出生、后吃饭」。构造器注入没有这个缝隙，所以无解（9.8 节实测）。

第 3 步会递归。实验 7 用构造器写了一条 A → B → C 的链，看创建顺序：

=== case7 依赖链 A->B->C 的创建顺序 ===
[   0.0ms] refresh() 开始
[   2.3ms] ChainC 构造（最底层先创建）
[   3.0ms] ChainB 构造
[   3.5ms] ChainA 构造
[   4.0ms] refresh() 结束

9.5十个回调，一个都不能背错

这是八股里最容易被抓细节的一题。下面这份输出是一次完整生命周期的原文，从构造到销毁：

=== case8 生命周期回调顺序 ===
[   0.0ms] Dep 构造
[  12.0ms] 1 构造器
[  70.9ms] 2 属性注入
[  71.9ms] 3 Aware 回调 setBeanName(life)
[  72.2ms] 3 Aware 回调 setBeanFactory
[  72.4ms] 4 BPP.postProcessBeforeInitialization
[  72.6ms] 5 @PostConstruct
[  72.8ms] 6 afterPropertiesSet
[  76.5ms] 7 initMethod
[  76.8ms] 7' BPP.postProcessAfterInitialization（在初始化方法之后）
[  92.8ms] --- 容器就绪，开始 close() ---
[  94.4ms] 8 @PreDestroy
[  94.6ms] 9 DisposableBean.destroy
[  94.8ms] 10 destroyMethod
[  97.3ms] --- close() 结束 ---

9.6单例与原型：90ns 和 1092ns

「单例」这个词被用滥了：Spring 的「单例」不是设计模式里的单例，它只是「容器内每名字一份」。 两者的代价差别可以直接测出来：

=== case6 单例 vs 原型 ===
单例 getBean x200000 : 18.1 ms（90 ns/次）
原型 getBean x200000 : 218.5 ms（1092 ns/次）
单例对象是否同一个: true
原型对象是否同一个: false
原型实例是否被容器持有: 容器内 proto 单例数=0

最后一行容易被忽略，但它是高频考点。把 @PreDestroy、DisposableBean、 destroyMethod 三种销毁回调全挂到一个原型 Bean 上，然后 getBean 两次再 close()：

=== case11 原型 bean 的销毁回调 ===
[   1.4ms] refresh() 开始
[ 246.3ms] refresh() 结束
[ 246.5ms] getBean(pl) 两次
[ 258.8ms] ProtoLife 构造
[ 261.0ms] ProtoLife 构造
[ 261.3ms] close() 开始
[ 266.6ms] close() 结束 —— 上面有几行销毁回调？

9.7三级缓存：把三个 Map 打印出来看

先给结论再上证据。三个缓存都在 DefaultSingletonBeanRegistry 里：

光看表格没有体感。实验 1 在 A、B 互相注入的过程中，每走一步就用反射把三个 Map 打一次：

=== case1 setter 循环依赖 ===
[   1.2ms] refresh() 开始
[ 599.1ms] A  -> 构造器执行完毕（此时 b 仍为 null）
[ 648.5ms] B  -> 构造器执行完毕（此时 a 仍为 null）
[ 658.1ms] B  -> setA 注入 A@2096194236
      [cache B.setA 之后] singletonObjects=ConcurrentHashMap/14(业务:[])
                           earlySingletonObjects=ConcurrentHashMap/1(业务:[a])
                           singletonFactories=ConcurrentHashMap/1(业务:[b])
[ 663.1ms] A  -> setB 注入 B@655713354
      [cache A.setB 之后] singletonObjects=ConcurrentHashMap/15(业务:[b])
                           earlySingletonObjects=ConcurrentHashMap/1(业务:[a])
                           singletonFactories=ConcurrentHashMap/0(业务:[])
[ 679.2ms] refresh() 结束
A@ctx=IocDemo$A@7cf162bc  B@ctx=IocDemo$B@2715644a
b.a == a ? true
a.b == b ? true
      [cache refresh 完成后] singletonObjects=ConcurrentHashMap/17(业务:[a, b])
                              earlySingletonObjects=ConcurrentHashMap/0(业务:[])
                              singletonFactories=ConcurrentHashMap/0(业务:[])

（singletonObjects 的总数里还有十几个是 environment、messageSource、 internalAutowiredAnnotationProcessor 这类容器自建 Bean，为了看清楚只保留了业务 key。）

把上面这段翻译成时序，就是这道题的标准答案骨架：

第 ④ 步是整道题的题眼：「从三级缓存取 ObjectFactory，调 getObject() 拿到早期引用， 然后把结果放进二级缓存，并删掉三级缓存里的工厂」——这正是实测输出里 earlySingletonObjects=[a] 且 singletonFactories=[b] 同时成立的原因。

为什么两级不行

如果只有「二级」——singletonFactories 里直接存对象，会怎样？ 关键在于什么时候决定要不要生成代理。

9.8循环依赖：两种活法，四种死法

「Spring 解决了循环依赖」这句话只对一个子集成立： 单例 + setter/字段注入。其余场景全部启动即失败。逐条实测如下。

死法一：构造器注入（最常见）

异常类型: org.springframework.beans.factory.UnsatisfiedDependencyException
异常消息: Error creating bean with name 'c1': Unsatisfied dependency expressed through
         constructor parameter 0: Error creating bean with name 'c2': Unsatisfied
         dependency expressed through constructor parameter 0: Error creating bean with
         name 'c1': Requested bean is currently in creation: Is there an unresolvable
         circular reference or an asynchronous initialization dependency?
--- 根因 ---
org.springframework.beans.factory.BeanCurrentlyInCreationException: ...

为什么构造器不行？回到 9.4 的 doCreateBean：addSingletonFactory() 排在 createBeanInstance() 之后。而构造器注入要求「参数先就位才能造对象」， 于是 A 的构造器还没返回，第三级缓存里就没有 A 的工厂，B 来要 A 只能得到「正在创建中」。 暴露早期引用的前提是对象已经存在，构造器阶段对象还不存在。

死法二：关掉 allowCircularReferences

ctx.setAllowCircularReferences(false);
// 同一对 A/B，只是不再允许循环
异常消息: Error creating bean with name 'a': Unsatisfied dependency expressed through
         method 'setB' parameter 0: ... Requested bean is currently in creation ...
--- 根因 ---
org.springframework.beans.factory.BeanCurrentlyInCreationException

死法三：原型

=== case10 prototype 循环依赖 ===
[ 164.1ms] P1 构造
[ 213.9ms] P2 构造
异常消息: Error creating bean with name 'p1': Unsatisfied dependency expressed through
         method 'setP2' parameter 0: ... Requested bean is currently in creation ...
--- 根因 ---
org.springframework.beans.factory.BeanCurrentlyInCreationException

原型根本没有「单例池」可放。三级缓存是 DefaultSingletonBeanRegistry 的字段， 名字里就写着 Singleton——原型 Bean 不会进这三个 Map，自然谈不上提前暴露。

活法：@Lazy 把环断开

=== case5 @Lazy 断环 ===
[   3.1ms] LA -> 构造
[  77.1ms] LA -> setLb 注入 IocDemo$LB$$SpringCGLIB$$0
[  77.4ms] LA -> 注入对象是 CGLIB 代理? true
[  77.8ms] LB -> 构造（此刻还没有任何人需要真正的 LB）
[  79.2ms] refresh() 结束

@Lazy 的思路不是「解决环」，而是把环拆成一条延迟的边： 注入的不是 LB 本身，而是一个 CGLIB 代理（实测类名带 $$SpringCGLIB$$）， 代理内部持有 BeanFactory，第一次真正调用方法时才去 getBean。 环在启动期消失了，代价是：把启动期错误推迟成运行期错误。

9.9代理 + 循环依赖：两个版本的两种表现

这一节是给「我已经知道三级缓存了」的人准备的。真实项目里循环依赖 + AOP 代理（ @Transactional、@Async、@Cacheable）会撞上一个更凶的错误。 用自定义 BeanPostProcessor 模拟 AOP 包装（返回 Proxy），同一份代码在两个版本上跑：

// 7.0.9 实测
=== case4 循环依赖 + BeanPostProcessor 包装 ===
[   3.9ms] PA -> 构造
[   4.7ms] PB -> 构造
[   5.6ms] PB -> setIa 注入 IocDemo$PA          <-- 拿到的是【裸对象】
[   6.4ms] BPP -> 把 pa 包装成代理（此刻 PB 手里已经是原始对象）
信息: Bean 'pa' marked for pre-instantiation (not lazy-init) but currently
      initialized by other thread - skipping it in mainline thread
[   8.3ms] PB -> 构造                          <-- pb 被【重新创建了一次】
[   8.6ms] PA -> 构造
[   8.7ms] BPP -> 把 pa 包装成代理
[   8.9ms] PB -> setIa 注入 $Proxy16             <-- 这次拿到了代理
[   9.9ms] refresh() 结束

// 6.1.13 实测（同代码）
异常类型: org.springframework.beans.factory.BeanCurrentlyInCreationException
异常消息: Error creating bean with name 'pa': Bean with name 'pa' has been injected
         into other beans [pb] in its raw version as part of a circular reference,
         but has eventually been wrapped. This means that said other beans do not
         use the final version of the bean. ...

9.10三类 getBean 异常、速记卡与自查

接口定义了、实现也写了，启动却报 NoSuchBeanDefinitionException—— 这类问题不值得花时间，但要知道报错长什么样，才能一眼定位：

=== case9 三类 getBean 异常 ===
[未 refresh] IllegalStateException: ...AnnotationConfigApplicationContext@6659c656
             has not been refreshed yet
[找不到] org.springframework.beans.factory.NoSuchBeanDefinitionException:
        No bean named 'notExist' available
[多个候选] NoUniqueBeanDefinitionException: No qualifying bean of type 'IocDemo$Pay'
          available: expected single matching bean but found 2: wx,ali
[指定名字] WxPay

五张速记卡

六个自测（能脱口而出才算过）

1. 三级缓存里，singletonFactories 存的是 ObjectFactory 而不是对象，为了什么？
2. A、B 循环依赖，实测在哪一步之后 earlySingletonObjects 里才出现 a？此时三级缓存里还剩谁？
3. @PostConstruct 和 afterPropertiesSet 谁先执行？各自是被谁调起来的？
4. 原型 Bean 上挂 @PreDestroy，容器 close() 时会执行吗？为什么？
5. 为什么构造器注入的循环依赖无法靠三级缓存解决？请从 doCreateBean 的语句顺序回答。
6. 线上报 has been injected into other beans [...] in its raw version，你会改哪三处？

动手清单与自查表