如下所示：
BeanA类依赖于BeanB类，同时BeanB类取决于BeanA类。这种依赖性形成了封闭环，我们将这种依赖关系称为圆形依赖性。相似，如下图所示。：
在上图中，BeanA类取决于BeanB类，BeanB类依赖于BeanC类，而BeanC类依赖于BeanA类。这样，它也形成了一个封闭的循环。另一个例子：
在上图中，他引用了自己并与自己形成了依赖。这也是一个依赖的闭环。
我们继续扩展先前的内容，并将属性添加到ModifyService。代码如下：
将属性添加到queryservice，代码如下：
通过这种方式，modifyservice依赖于Queeryservice，而QueeryService也依靠ModifyService形成闭环。那么在这种情况下会发生什么问题？
让我们来调试上一个代码。初始化GPApplicationContext初始化后，我们将遵循断点。让我们跟随IOC容器中的情况，如下所示：：
开始项目，我们发现，只要循环依赖关系的属性与无自动关联，并且无周期依赖性关系的属性具有自动分配，如下图所示：
这是如何原因的？分析原因后，我们发现bean上的IOC容器的初始化基于beandefinition循环迭代，并且有一定顺序。在这种方式中，当注入依赖项时，对象对应对应。对于需要分配的属性可能尚未初始化，如果没有初始化，就没有相应的实例注入。
特定代码如下：
添加getsingleton（）方法：
修改getBean（）方法，将以下代码添加到getBean（）方法：
修改supersbean（）方法，该代码如下：
我们都知道，弹簧AOP，交易等是通过代理对象实现的，并且交易的代理对象由自动代理创始人完成。原始对象。
在这里，我们结合了循环依赖性，然后分析AOP代理对象的创建过程以及最终放入容器中的动作。请参阅以下代码：
该服务类使用交易，因此它最终将生成一个JDK Dynamic代理对象代理。碰巧它具有自己的循环依赖性。按下Spring的源代码部分以创建BEAN来查看DoCreatebean（）方法：）方法：
以上代码分析是代理对象具有其自身的周期依赖性。Spring使用三级缓存来解决此问题。
如果没有循环依赖性，则春季处理过程略有不同，并继续跟进源代码：
根据上述代码分析，只要使用代理，尚未被周期引用的代理仍然是弹簧容器中缓存的代理对象。如果我们关闭弹簧容器的周期依赖关系，那就是，将允许CircularReference的值设置为false，然后会出现问题吗？首先关闭循环依赖关系开关。
关闭循环依赖性后，上述代码中有一个循环依赖关系。操作计划将具有以下异常：
这里的异常类型也是beanCurrantyIncreationException，但错误位置位于默认情况下。
让我们分析弹簧将是实例化的B。当将A分配给其属性时。完成B实例完成后，它将继续分配B属性。由于我们关闭了周期依赖性，因此没有高级暴露。因此，B无法直接获得A的参考地址，并且只能创建A. A. A. A.再创建。发生所有异常。分析程序运行过程：
粗糙的操作步骤如下：
从上面的代码可以看出，即使关闭了循环依赖关系开关，缓存到容器中的对象仍然是代理对象。显然，@Autowired被分配给代理对象的属性。
最后，以Abvistautautoproxycreator为例，以查看自动代理创建者的详细信息实现了与周期相关的代理对象。
基于上述分析，可以知道自动代理创始人保证只有一次创建代理对象，并且自动注入循环依赖项的自动注入仍然是代理对象。从上面的分析，结论是，在弹簧容器中，是否存在循环依赖性，甚至是弹簧容器的循环依赖函数，它都会影响弹簧AOP代理的创建过程，但对结果没有影响。换句话说，Spring屏蔽了容器中对象的详细信息，因此用户完全未知。
本文最初是创建“ Tom Bullet Architecture”的。请指出重印的来源。技术在于共享，我分享我的幸福！如果本文对您有所帮助，请注意并喜欢；如果您有任何建议，也可以发表评论或私人消息。您的支持是我坚持创建的动力。注意“ Tom Bullet Architecture”以获取更多技术干货！