高频面试题：Spring 如何解决循环依赖？

西多

就在spring docs里面关于DI的描述里面，介绍constructor injection一篇里面有个讨论constructor injection和field injection的段落。
里面有提到应该尽可能地使用constructor injection。

小奕士郎

昨天面试阿里问了这个题，还好提前看了一下，但是没有仔细看源码，没有达到面试官想要的深度

说真话容易

我8个月经验，今年3月面试的时候被问到了，理解错意思了，我以为问的是出现了循环依赖怎么解决，就说了几种自己碰到过的解决方法，尴尬

经典老歌

这个问题我看源码搞明白了，即使不用构造器注入依然可能会有循环依赖的问题。例如@Async就是典型的例子，@Transactional是在从单例工厂获取时就实现代理了，而@Async则是在注入后才实现代理对象。而有时成功有时失败是由于操作系统不同导致读取jar时文件顺序不一样，最后实例创建循序不一样。

江夏申焱

文档我最近也看了，你说这个是setter和constructor两种当时优先使用构造方法，循环依赖的情况下考虑用setter但这都是xml内部的当时的比较，xml和注解则是各有又是，注解往往是更好的选择，但是xml可以在拿不到源码的情况下声明bean

海天边

现在xml唯一强处就是在当前类没法写在代码里面的时候，但是这种情况spring boot都通过大量预置的autoconfiguration解决掉了。
而且，从spring boot的changelog可以看出，是越来越偏向于「不变」，而构造器注入正是为了不变性而服务的一个环节。

靖爷的翔龙拾捌涨

??注解注入和构造器注入有关系吗？

老子徐二的刚

我的意思是，xml现在在spring boot环境下已经几乎没用了，唯一用途是初始化那些老框架，稍微有点知名度的框架spring boot都已经做好自动装配或者框架自身提供starter，xml已经失去大部分使用场景，所以setter注入方式也已经不需要再考虑兼容，从而可以开始转向构造器注入。

臭美姐姐

不是吧，注解的方式既不属于构造器注入也不属于setter注入啊

鑨

@Autowired只是有了@ComponentScan之后为了简化注入的一个产物而已，本质还是setter，并且在xml和javaconfig里面都无法配置（private字段）必须scan才能用，和spring框架强绑定。