程序员经典面试题：怎么解决 spring 的 bean 循环依赖问题？

解偶。

由于，bean 的初始化过程互相依赖，导致无法创建，类似死锁。一般的循环依赖是指，在属性上使用装配的注解。

普通的 pojo 类也可以有循环依赖。如两个类各自持有一个对方的引用，并在构造方法中调其空参构造。这样就会导致循环依赖，最终报异常，stackoverflow
栈溢出。

在这种情况下，我们该怎样解决呢？

最简单的，使用 set 方法，不在构造函数中去实例化。人与人的思维是相通的，我相信在 Spring 容器的实现过程中，肯定有人有过这种想法。但最终没有采纳。因为，使用 set 方法是有局限性的。

1.一般的，在构造方法中的参数都是必要的，在实例化后就可以直接使用了。如果有人没有 set 就使用了会报错。

2.Spring 一直强调激发 pojo 潜能。如果，采用了 set，则必须要实现 set 方法，产生了侵入性。并且，有些时候，我们的属性是不希望被更改的。

在 set 方法这条路走不通后，我们还需要思考。这两个类的构造方法，依赖过于亲密。怎么办？既然是依赖亲密，首先想到的就是解偶。当发现两个类循环依赖时，就先使用一个 null 去实例化一个对象，然后再进行另一个对象的实例化，最后，给 null 赋值为一个新的对象。

说完了我们在 pojo 中的处理。接下来就看看 spring，众所周知，springIOC 使用了三级缓存。一共三级缓存都是用来解偶的吗？不是，按照我们 pojo 中的想法，只需要一层就可以了。三级缓存，肯定是先有一级，发现一级不行，有了二级，二级不行有了三级，并不是天生的三级缓存。

那么我们看看这三级缓存到底做了什么呢？

第一级，用于实现 IOC 容器的单例池。

发现了循环依赖后，开始考虑用二级缓存解偶。如果，假设，我们是就是写 spring 的程序员。我们会发现什么问题呢？不考虑推断构造，假设每个类中都有一个空参构造方法。那么，每次实例化时，我们只需要把这个对象扔进二级缓存里。当发生循环依赖时，让被注入的对象去实例化，然后在二级的池子中取出来就可以了。类似 pojo，再给之前的对象赋值。

原本，到这里已经皆大欢喜了。但是，伟大的代理思想，出现了面相切面编程，那可真是香极了。但是，成也萧何败也萧何。我们的容器，有一些循环依赖的对象最终要装配的是代理对象。结果，我们现在只是在实例化时就扔进了普通对象。有的注入普通对象就可以了，有的注入代理对象就可以了。这可咋办。

此时，我们发现，我们解决不了，代理对象和普通对象的唯一性关系。因为他们都过于依赖于缓存了。又出现了关键字依赖，面对依赖的办法就是再多一层，解偶依赖。所以，再来一层缓存，只要这层缓存能保证，当对象有代理时只产生一个代理代理对象，没有代理时就拿出一个普通对象。这样就解决了我们的问题。众所周知，spring 在三级缓存中，缓存了一个 lamda 表达式，用于解决这个问题。

所以，spring 是怎么解决循环依赖的，用二级缓存。那三级缓存是干嘛的？用于，解决普通对象和代理对象的唯一性问题。