Spring 循环依赖解决方案

daiwei-dave

12298人浏览 · 2022-11-24 18:10:24

daiwei-dave · 2022-11-24 18:10:24 发布

一、Spring中的循环依赖

1.Spring中的循环依赖基础

1.什么是循环依赖？

循环依赖就是循环引用，就是两个或多个Bean相互之间的持有对方，比如A引用B，B引用C，C引用A，则它们最终反映为一个环。

我们这里以两个类A和B为例进行讲解，如下是A和B的声明：

@Component
public class A {
  private B b;
  public void setB(B b) {
    this.b = b;
  }
}
@Component
public class B {
  private A a;
  public void setA(A a) {
    this.a = a;
  }
}

结论先行：

1.构造器循环依赖----初始化失败

2.field属性注入并且是单列模式循环依赖（setter方式）----初始化成功

3.field属性注入循环依赖（prototype）----初始化失败

现象总结：同样对于循环依赖的场景，构造器注入和prototype类型的属性注入都会初始化Bean失败。因为@Service默认是单例的，所以单例的属性注入是可以成功的。

2.Spring 如何解决循环依赖？

Spring bean注入流程
类实例化 -> 属性注入 -> 执行初始化方法 -> (如果有需要)生成代理对象 -> 使用

三级缓存解决循环依赖流程

A、B两个类相互依赖，初始化A的时候，第一步实例化A完成（生成对象工厂实例放入三级缓存），注入依赖属性B，一级缓存查询B没有，二级缓存查询B没有，

初始化B（生成对象工厂实例放入三级缓存），注入依赖属性A，一级缓存查询A没有，二级缓存查询A没有，三级缓存查询到A的对象工厂，需要AOP增强则生成A的代理对象，没有则直接创建A实例对象，并将A放入到二级缓存，注入A的代理对象完成，生成代理对象B，B移入一级缓存。

继续A属性注入（B的代理对象），然后可能还会依赖注入C对象流程和B一致，所有依赖注入完成后A初始化，生成A的代理对象，发现A的代理对象已存在，则跳过，放入一级缓存。此时A的代理对象也是提前生成的，但是仅针对循环依赖提前生成。

下面为流程图：

三级缓存不存在循环依赖的正常生成流程

第一步实例化A完成（生成对象工厂实例放入三级缓存，此时虽然放入三级缓存，但没有生成代理对象），注入属性，执行初始化方法，生成代理对象，移入一级缓存。

spring为什么不能只用一二级缓存来解决循环依赖？ - sahara-随笔 - 博客园

3.spring中出现循环依赖的场景

spring中出现循环依赖主要有以下场景：

2.循环依赖常见的解决方案

1.重新设计

当有一个循环依赖，很可能是有一个设计问题并且各责任没有得到很好的分离。应该尽量正确地重新设计组件，以便它们的层次是精心设计的，也没有必要循环依赖。

如果不能重新设计组件（可能有很多的原因：遗留代码，已经被测试并不能修改代码，没有足够的时间或资源来完全重新设计…），但有一些变通方法来解决这个问题，如下面几种方式

2.延迟加载@Lazy注解---需要了解一下它的实现原理？？？

解决Spring 循环依赖的一个简单方法就是对一个Bean使用延时加载。也就是说：这个Bean并没有完全的初始化完，实际上他注入的是一个代理，只有当他首次被使用的时候才会被完全的初始化。

@Service
public class ServiceAImpl implements ServiceA {
    private ServiceB serviceB;

    public ServiceAImpl(@Lazy ServiceB serviceB) {
        this.serviceB = serviceB;
    }
}

3.Setter/Field 注入

简单地说，你对你需要注入的bean是使用setter注入（或字段注入），而不是构造函数注入。

@Service
public class ServiceAImpl implements ServiceA {
    private ServiceB serviceB;

    @Autowired
    public void setServiceB(ServiceB serviceB) {
        this.serviceB = serviceB;
    }
}

4.bean工厂延迟获取

        FeederServiceImpl feederService = SpringUtils.getBean(FeederServiceImpl.class);

这种方式可以解决业务中出现循环依赖的场景

二.spring 三级缓存实现原理

1.一级缓存

已经完成了bean的所有流程，即实例化、注入、初始化完成的bean实例，并放进了单列池中了。

一级缓存：
/** 保存所有的singletonBean的实例,已经完成了所有流程可以用的bean */
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>(64);

2.二级缓存

保存所有早期创建的Bean对象，这个Bean还没有完成依赖注入，但已经提前完成了AOP增强。

/** 保存所有早期创建的Bean对象，这个Bean还没有完成依赖注入 */
private final Map<String, Object> earlySingletonObjects = new HashMap<String, Object>(16);

为什么需要二级缓存？

如果出现循环依赖+aop时，多个地方注入这个动态代理对象需要保证都是同一个对象，而三级缓存中的取出来的动态代理对象每次都是新对象，地址值不一样。

3.三级缓存

singletonBean的生产工厂，即创建单列bean的工厂。

存的是一个函数接口，函数接口实现创建动态代理调用BeanPostProcessor 。为了避免重复创建，调用把返回的动态代理对象或者原实例存储在二级缓存中。

/** singletonBean的生产工厂，即创建单列bean的工厂*/
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<String, ObjectFactory<?>>(16);

在取三级缓存并创建bean时，ObjectFactory调用getObject()，不仅会取到bean实例而且还会判断是否生成代理对象，并放到二级缓存中。

为什么需要第三级缓存？

解决如果出现循环依赖，判断是否需要提前进行aop等操作

一级缓存：
/** 保存所有的singletonBean的实例,已经完成了所有流程可以用的bean */
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>(64);

二级缓存：

/** 保存所有早期创建的Bean对象，这个Bean还没有完成依赖注入 */
private final Map<String, Object> earlySingletonObjects = new HashMap<String, Object>(16);

三级缓存：
/** singletonBean的生产工厂，即创建单列bean的工厂*/
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<String, ObjectFactory<?>>(16);
 
/** 保存所有已经完成初始化的Bean的名字（name） */
private final Set<String> registeredSingletons = new LinkedHashSet<String>(64);
 
/** 
标识指定name的Bean对象是否处于创建状态，这个状态非常重要。
如果创建完毕之后，会将其从 singletonsCurrentlyInCreation 列表中移除，
并且会将创建好的 bean 放到另外一个单例列表中，这个列表叫做 singletonObjects即一级缓存中。
*/
private final Set<String> singletonsCurrentlyInCreation =
    Collections.newSetFromMap(new ConcurrentHashMap<String, Boolean>(16));

思考

1.为什么不使用一级缓存？

如果只使用一级缓存：

1.A先从单列池中查询A，没有则创建A，A对象实例化后准备依赖注入B

2.B对象先从单列池中查询B，没有则创建B，B对象实例化后准备依赖注入A

3.A又从单列池中查询A，此时A由于没有完成创建，单列池中没有A，又回重复1过程，从而造成死循环。

可见只使用一级缓存是会造成循环依赖的，那么就需要把只完成了类的实例化还没有进行后面依赖注入，初始化等过程的对象缓存起来（三级缓存），这样从一级缓存取不到，则取三级缓存。

如果这样貌似使用两级缓存就可以了，那为什么还需要三级缓存？

2.为什么需要二级缓存？只用一级缓存和三级缓存可以吗？

先说结论，

1.如果该对象不涉及AOP代理，只用二级缓存就能解决循环依赖了。

2.如果A不仅被B引用，还同时被C引用等，如果存在代理的情况。只用二级缓存也不能解决循环依赖，因为可能出现两个不同的代理对象违背单一原则。

看下图

在这里插入图片描述

即三级缓存获取到的对象工厂ObjectFactory，并取对象时，需要创建新的代理对象，为了防止创建新的代理对象违背单列原则，会将第一次创建的代理对象放到二级缓存中。

spring中为什么要三级缓存？二级不行吗？_知识浅谈的博客-CSDN博客_spring二级缓存与三级缓存

二级缓存因为代理存在的问题流程

第一步实例化A完成（原始实例放入二级缓存），注入依赖属性B，一级缓存查询B没有，二级缓存查询B没有，

初始化B（放入缓存），注入依赖属性A，一级缓存查询A没有，二级缓存查询A注入（此时A是原始实例，未被代理），生成代理对象B，移入一级缓存，继续A属性注入（B的代理对象），A初始化完成。

B中的依赖对象A是未代理的，存在问题（环境中存在代理和未代理的两种类型的同一个对象A）。

如果上述流程放入二级缓存的是代理对象，则和spring bean生成流程（实例最后生成代理对象）相悖。

二级缓存因为两个以上存在的问题

试想一下，如果出现以下这种情况，我们要如何处理？

@Service
public class TestService1 {

    @Autowired
    private TestService2 testService2;
    @Autowired
    private TestService3 testService3;

    public void test1() {
    }
}

@Service
public class TestService2 {

    @Autowired
    private TestService1 testService1;

    public void test2() {
    }
}

@Service
public class TestService3 {

    @Autowired
    private TestService1 testService1;

    public void test3() {
    }
}

TestService1依赖于TestService2和TestService3，而TestService2依赖于TestService1，同时TestService3也依赖于TestService1。

按照上图的流程可以把TestService1注入到TestService2，并且TestService1的实例是从第三级缓存中获取的。

假设不用第二级缓存，TestService1注入到TestService3的流程如图：

TestService1注入到TestService3又需要从第三级缓存中获取实例，而第三级缓存里保存的并非真正的实例对象，而是ObjectFactory对象。说白了，两次从三级缓存中获取都是ObjectFactory对象，而通过它创建的实例对象（主要是代理aop对象，如果没有aop对象则不会存在问题）每次可能都不一样的。

这样ObjectFactory就不一样了，违反的单一实例原则，这样不是有问题吗？

为了解决这个问题，spring引入的第二级缓存。上面图1其实TestService1对象的实例已经被添加到第二级缓存中了，而在TestService1注入到TestService3时，只用从第二级缓存中获取该对象即可。

3.为什么需要提前进行aop?按照spring生命周期初始化完成之后进行AOP代理对象创建不可以吗？

我们都知道Bean的aop动态代理创建时在初始化之后，但是循环依赖的Bean如果使用了AOP。那无法等到解决完循环依赖再创建动态代理，因为这个时候已经注入属性了，比如A已经注入到B对象的属性中了，此时B中的A对象就不是代理对象了。

所以如果循环依赖的Bean使用了aop. 需要提前创建aop。

并且还要提前判断是否需要进行提前AOP。

4.如何判断需要提前进行aop?

创建本身的时候是没法判断自己是不是循环依赖，只有在B 引用A （不同bean的引用）下才能判断是不是循环依赖（比如B引用A,A正在创建中，那说明是循环依赖），所以判断要写在getSingleton中。

假如A是proxy:
    
A创建Bean -->注入属性B-->getBean(B)-->创建B-->注入属性A---->getSingleton("a")之后写如下代码
==================================================================================================
public object getSingleton(beanName){
    先从一级缓存拿 省略code...

    if(二级缓存有吗？){  
        return 二级缓存中拿；
    }
    if(A是否还在创建中){
        说明是循环依赖.
        二级缓存=调用创建动态代理BeanPostProcessor（判断是否使用aop，没有依然返回原实例）；
    }

}

所以说二级缓存确实完全可以解决循环依赖的任何情况：包括扩展能力（因为也可以在这里调用BeanPostProcessor, 当然AOP也是基于BeanPostProcessor）

spring源码的实现方式如下：

org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#doCreateBean

 boolean earlySingletonExposure = mbd.isSingleton() && this.allowCircularReferences && this.isSingletonCurrentlyInCreation(beanName);
        if (earlySingletonExposure) {
            if (this.logger.isTraceEnabled()) {
                this.logger.trace("Eagerly caching bean '" + beanName + "' to allow for resolving potential circular references");
            }

            this.addSingletonFactory(beanName, () -> {
                return this.getEarlyBeanReference(beanName, mbd, bean);
            });
        }

earlySingletonExposure就是判断后的结果。

5.第三级缓存中为什么要添加ObjectFactory对象，直接保存实例对象不行吗?

答：不行，同二级缓存存在的原因一样。

因为假如你想判断是否对添加到三级缓存中的实例对象进行增强，直接用实例对象是行不通的，假如都是创建代理对象那违反单一原则，都不创建，则无法进行增强。所以得有一个中间态来判断是否需要加AOP加强以及存储加强后的结果避免重复创建。

针对这种场景spring是怎么做的呢？

答案就在AbstractAutowireCapableBeanFactory类doCreateBean方法的这段代码中：

它定义了一个匿名内部类，通过getEarlyBeanReference方法获取代理对象，其实底层是通过AbstractAutoProxyCreator类的getEarlyBeanReference生成代理对象。

版权声明：本文为CSDN博主「蜀州凯哥」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/m0_72088858/article/details/126698574

二、构造器注入与循环依赖

这种注入方式现在其实用的已经非常少了，但是我们还是有必要了解一下，看看如下代码：

@Service
public class TestService1 {

    public TestService1(TestService2 testService2) {
    }
}

@Service
public class TestService2 {

    public TestService2(TestService1 testService1) {
    }
}

运行结果：

Requested bean is currently in creation: Is there an unresolvable circular reference?

出现了循环依赖，为什么呢？

创建实例TestService1时需要执行构造方法，构造方法需要传入TestService2，所以开始初始化TestService2，这时并没有用到第三级缓存，所以会出现循环依赖的情况。

从图中的流程看出构造器注入没能添加到三级缓存，也没有使用缓存，所以也无法解决循环依赖问题。

那如何解决基于构造器所造成的循环依赖？

通过添加使用@Lazy注解，延迟加载

如下面代码：

@Service
public class TestService1 {

    public TestService1(TestService2 testService2) {
    }
}

@Service
public class TestService2 {
    @Lazy
    public TestService2(TestService1 testService1) {
    }
}

为什么能解决勒？

执行构造器的时候，实际上是用到的TestService2的代理对象

参考资料

1.高频面试题：Spring 如何解决循环依赖？https://zhuanlan.zhihu.com/p/84267654
2.Spring 如何解决循环依赖的问题
https://www.jianshu.com/p/8bb67ca11831

GitCode 开源社区

旨在为数千万中国开发者提供一个无缝且高效的云端环境，以支持学习、使用和贡献开源项目。

更多推荐

[转载]在Windows环境下安装GNU Radio

转自：在Windows环境下安装GNURadio_恐弱智_新浪博客GNU Radio是用Python开发的，大部分开源的工程能够在Linux环境下运行良好，而Windows下却运行的很勉强，而且安装配置都很复杂。GNU Radio算是个例外了，不光提供了Windows的二进制安装，还有比较详细的说明。我是Python小白，所以折腾了好久才弄好，特意记录下来，免得以后再装还折腾。GNU Radio的

GitCode 开源社区

centOS 8 使用dnf安装Docker

DNF是什么？CentOS 8使用YUM软件包管理器版本v4.0.4。现在，该版本使用DNF(已删除YUM)。DNF是软件包管理器。它会在Linux发行版上安装，执行更新并删除软件包。使用DNF安装Docker跳过具有损坏依赖性的程序包一个有效的解决方案是使您的CentOS 8系统使用以下--nobest命令安装最符合条件的版本：sudo dnf install docker...

GitCode 开源社区

定时同步数据库表(mysql+linux+crontab)

sync.sh里面的参数需要改变，ip/username/password/database/tablesync.sh#!/bin/sh# Please change the IP and password of the data source db.# Then change the table name.filename=/home/nington/db/$(date +%Y-%m