spring为什么要使用三级缓存来解决循环依赖

.main.

已于 2023-11-16 18:46:43 修改

阅读量330

点赞数

文章标签： spring 缓存 java

于 2023-11-16 16:01:36 首次发布

本文链接：https://blog.csdn.net/qq_45743985/article/details/134443215

版权

出现循环依赖的原因

AService依赖BService

@Service("aService")
public class AService {
    @Autowired
    BService bService;
}

BService依赖AService

@Service("bService")
public class BService {
    @Autowired
    AService aService;
}

此时就出现了循环依赖

想要搞明白循环依赖，首先要先搞清楚bean的生命周期：SpringBean生命周期-CSDN博客

AService Bean的创建流程

AService创建（doCreateBean方法）的生命周期
0. creatingSet("aService") // 将aService放入 this.singletonsCurrentlyInCreation中表示aService正在创建中

1．创建一个AService普通对象--->singletonFactories<aService，lambda> // 通过反射创建普通对象然后将普通对象和BeanDefinition通过一个lambda放入singletonFactories三级缓存中（该lambda会去判断是否需要进行aop等代理操作，如果没有出现循环依赖就不需要执行lambda中的内容），用于在出现循环依赖的情况下便于二级缓存拿到普通对象

boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
				isSingletonCurrentlyInCreation(beanName));
		if (earlySingletonExposure) {
			if (logger.isTraceEnabled()) {
				logger.trace("Eagerly caching bean '" + beanName +
						"' to allow for resolving potential circular references");
			}
			// 循环依赖-添加到三级缓存
			addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
		}

2．填充bService属性--->去单例池中找BService对象--->创建BService的Bean对象

3. 填充其他属性

4.其他操怍（完成属性依赖后，继续执行初始化前(被@PostConstruct注解修饰的方法)和初始化中(实现了InitializingBean接口并重写afterPropertiesSet())的相关操作）

5．初始化后(AOP)--->如何判断之前是否有过aop呢？ earlyProxyReferences这个map会存储执行过aop操作的bean

5.5 在earlySingleonObjects中找到aService对象，让该对象引用完整的AService

if (earlySingletonExposure) {
            // 会从earlyProxyReferences中获取之前创建的aService对象
			Object earlySingletonReference = getSingleton(beanName, false);
			if (earlySingletonReference != null) {
				if (exposedObject == bean) {
                    // 赋值
					exposedObject = earlySingletonReference;
				}

6．放入单例池

BService Bean的创建流程

1．创建一个BService普通对象

2．填充aService属性--->去单例池中找AService对象-->creatingSet-->出现了循环依赖-去二级缓存中找->earlySingletonObjects--没找着，接着去三级缓存中去找->singletonFactories--找到后调用存放的lambda表达式->lambda-在lambda中会进行判断AService对象是否使用了aop，如果使用了则会执行代理相关操作，如果没有则不执行->AService代理对象-然后将代理的对象或者实例对象放入二级缓存中，并且删除三级缓存中的该实例->earlySingletonObjects

3．填充其他属性

4．其他操作

5．初始化后

6．放入单例池

循环依赖情况下AService如何感知是否已经进行了aop代理操作

在出现了循环依赖的情况下如果aService需要进行aop操作，在bService已经对aService进行了aop操作的情况下，aService在走到初始化后的aop操作时不应该进行aop操作，那么aService是如何知道bService已经对aService进行了aop操作的呢？

// 两个方法都在AbstractAutoProxyCreator类中，比较两个方法可以

	// bService去三级缓存中调用lambda中存放的方法，在对aService执行aop相关操作之前会先把该对象存入earlyProxyReferences中
	@Override
	public Object getEarlyBeanReference(Object bean, String beanName) {
		Object cacheKey = getCacheKey(bean.getClass(), beanName);
		this.earlyProxyReferences.put(cacheKey, bean);
		// wrapIfNecessary执行aop相关操作
		return wrapIfNecessary(bean, beanName, cacheKey);
	}
	
	
		// aService初始化后 ，在执行aop相关操作之前会先判断earlyProxyReferences中是否有该bean，如果有表示执行过aop，就不需要在执行了
		@Override
	public Object postProcessAfterInitialization(@Nullable Object bean, String beanName) {
		if (bean != null) {
			Object cacheKey = getCacheKey(bean.getClass(), beanName);
			if (this.earlyProxyReferences.remove(cacheKey) != bean) {
			// wrapIfNecessary执行aop相关操作
				return wrapIfNecessary(bean, beanName, cacheKey);
			}
		}
		return bean;
	}

三级缓存总结

1.单例池 singleonObjects：

作用获取已经创建好的bean对象不需要重复生成

2.第二级缓存 earlySingleonObjects：

作用，再出现循环依赖的情况下，如果AService不仅依赖了BService还依赖了CService，而且CService也依赖了AService，

如果没有二级缓存只有三级缓存时，如果是没有aop相关操作的话就没有问题，如果aop操作的话就会出现在BService获取了AService的代理对象后，CService还要重新获取AService代理对象，就会出现B和C依赖的AService不是同一个的情况，为了保证不重复去生产bean保证单例所有需要earlySingleonObjects二级缓存

3.第三级缓存 singletonFactories：

三级缓存的作用是让spring解决循环依赖变得更见方便一点，如果没有第三级缓存，那么当出现循环依赖时，无法拿到被依赖的对象实例。
如果三级缓存不是使用lambda的形式，没有存入普通对象和BeanDefinition，只存了普通实例对象的话，如果该普通对象初始化后需要进行aop(需要aop就需要代理操作，进行代理操作就会产生代理对象，那么就会发生不是同一个对象的情况)操作的话又会出现问题，相似的如果存入的都是代理的对象不仅浪费极大的性能，而且bean对象也不都是需要进行aop操作的，又会出现不是同一个对象的情况

spring三级缓存中最终打破循环的缓存就是第三级缓存

@Async注解对循环循环依赖的影响

@Service("aService")
public class AService {
    @Autowired
    BService bService;

    @Async
    public void test(){
    System.out.println(bService.toString);    
    }
}

如果AService存在循环依赖和aop相关操作的情况下，AService中的方法还使用了@Async异步注解，那么就会报错

Error creating bean with name 'testBeanLifecycle': Unsatisfied dependency expressed through field 'testBeanLifecycleServiceImpl'; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'testBeanLifecycleServiceImpl': Bean with name 'testBeanLifecycleServiceImpl' has been injected into other beans [BServiceImpl] 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. This is often the result of over-eager type matching - consider using 'getBeanNamesForType' with the 'allowEagerInit' flag turned off, for example.

原因是被@Async注解注释的方法和aop切入的方法相同，都有一个对应的BeanPostProcessor来处理

	@Override
	public Object applyBeanPostProcessorsAfterInitialization(Object existingBean, String beanName)
			throws BeansException {

		Object result = existingBean;
		for (BeanPostProcessor processor : getBeanPostProcessors()) {
            // Bean初始化后会执行所有相关的BeanPostProcessor 包括aop和@Async
			Object current = processor.postProcessAfterInitialization(result, beanName);
			if (current == null) {
				return result;
			}
			result = current;
		}
		return result;
	}

但是和aop的postProcessAfterInitialization方法不同，@Async对应的BeanPostProcessor.postProcessAfterInitialization()并不会判断之前是否执行过代理操作，

    // @Async相关的BeanPostProcessor 
	@Override
	public Object postProcessAfterInitialization(Object bean, String beanName) {
		if (this.advisor == null || bean instanceof AopInfrastructureBean) {
			// Ignore AOP infrastructure such as scoped proxies.
			return bean;
		}

		if (bean instanceof Advised) {
			Advised advised = (Advised) bean;
			if (!advised.isFrozen() && isEligible(AopUtils.getTargetClass(bean))) {
				// Add our local Advisor to the existing proxy's Advisor chain...
				if (this.beforeExistingAdvisors) {
					advised.addAdvisor(0, this.advisor);
				}
				else {
					advised.addAdvisor(this.advisor);
				}
				return bean;
			}
		}

		if (isEligible(bean, beanName)) {
			ProxyFactory proxyFactory = prepareProxyFactory(bean, beanName);
			if (!proxyFactory.isProxyTargetClass()) {
				evaluateProxyInterfaces(bean.getClass(), proxyFactory);
			}
			proxyFactory.addAdvisor(this.advisor);
			customizeProxyFactory(proxyFactory);

			// Use original ClassLoader if bean class not locally loaded in overriding class loader
			ClassLoader classLoader = getProxyClassLoader();
			if (classLoader instanceof SmartClassLoader && classLoader != bean.getClass().getClassLoader()) {
				classLoader = ((SmartClassLoader) classLoader).getOriginalClassLoader();
			}
			return proxyFactory.getProxy(classLoader);
		}

		// No proxy needed.
		return bean;
	}

所以在执行到Async对应的postProcessAfterInitialization时就会又创建一个代理对象，此时代理对象不止一个，Bean判断不是同一个Bean，并且有别的Bean依赖该Bean，抛出异常。

		if (earlySingletonExposure) {
			Object earlySingletonReference = getSingleton(beanName, false);
			if (earlySingletonReference != null) {
                // 和之前三级缓存中使用lambda表达式创建的普通bean对象不是同一个，进入else
				if (exposedObject == bean) {
					exposedObject = earlySingletonReference;
				}
				else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
					String[] dependentBeans = getDependentBeans(beanName);
					Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
					for (String dependentBean : dependentBeans) {
						if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
							actualDependentBeans.add(dependentBean);
						}
					}
					if (!actualDependentBeans.isEmpty()) {
                    // 有依赖该Bean的Bean，但是Bean不相同，抛出异常
						throw new BeanCurrentlyInCreationException(beanName,
								"Bean with name '" + beanName + "' has been injected into other beans [" +
								StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
								"] 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. This is often the result of over-eager type matching - consider using " +
								"'getBeanNamesForType' with the 'allowEagerInit' flag turned off, for example.");
					}
				}
			}
		}

解决方式

@Service("aService")
public class AService {
    @Autowired
    @Lazy
    BService bService;

    @Async
    public void test(){
    System.out.println(bService.toString);    
    }
}

给BService加上@Lazy注解，被@Lazy注解修饰的变量不会立即开始依赖注入，而是直接创建一个代理对象，在该实例被真正调用时才进行注入操作。但是此时AService已经完成了创建，不再有循环依赖的情况发生。

构造方法注入的循环依赖

@Service("aService")
public class AService {
    
    BService bService;

    public AService(BService bService){
        this.bService = bService;
    }
}

@Service("bService")
public class BService {
    
    AService aService;

    public BService (AService aService){
        this.aService= aService;
    }
}

使用构造器注入发生的循环依赖，spring本身是没有办法处理的

因为spring Bean的创建第一步就是通过构造器来创建普通对象的，此时构造器发生了循环依赖，就没办法创建普通对象了也就没有后续的将普通对象存入缓存的操作了。

解决方法

解决方法和@Async的解决方案一致，给其中一个构造器上加上@Lazy注解，直接创建代理对象就可以跳出循环依赖。

非单例模式的循环依赖问题

非单例模式下的循环依赖由于创建Bean的过程中不再有三级缓存，没有存放普通对象的地方，所以非单例模式下的循环依赖Spring没有办法解决。

解决方法

和之前一样加上@Lazy注解即可。

@Service("aService")
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
public class AService {
    @Autowired
    BService bService;
}

@Service("bService")
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
public class BService {
    @Autowired
    @Lazy
    AService aService;
}

.main.

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
spring为什么要使用三级缓存来解决循环依赖

如果三级缓存不是使用lambda的形式，没有存入普通对象和BeanDefinition，只存了普通实例对象的话，如果该普通对象初始化后需要进行aop(需要aop就需要代理操作，进行代理操作就会产生代理对象，那么就会发生不是同一个对象的情况)操作的话又会出现问题，相似的如果存入的都是代理的对象不仅浪费极大的性能，而且bean对象也不都是需要进行aop操作的，又会出现不是同一个对象的情况。2．填充bService属性--->去单例池中找BService对象--->创建BService的Bean对象。
复制链接

扫一扫