Springboot回圈依賴實踐紀實-有解無憂

測驗的Springboot版本: 2.6.4，禁止了回圈依賴，但是可以通過application.yml開啟（哈哈）

@Lazy注解解決回圈依賴

情況一：只有簡單屬性關系的回圈依賴

涉及的Bean:

ASerivce及其實作類ASerivceImpl
BSerivce及其實作類BSerivceImpl

com.example.demo.service.AService

package com.example.demo.service;


public interface AService {
    void zaWaLuDo();
}

com.example.demo.service.impl.AServiceImpl

package com.example.demo.service.impl;

import com.example.demo.service.AService;
import com.example.demo.service.BService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class AServiceImpl implements AService {

    @Autowired
    public BService bService;

    @Override
    public void zaWaLuDo(){
        System.out.println("ToKiOToMaLei!");
    }
}

com.example.demo.service.BService

package com.example.demo.service;

public interface BService {

}

com.example.demo.service.impl.BServiceImpl

package com.example.demo.service.impl;

import com.example.demo.service.AService;
import com.example.demo.service.BService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class BServiceImpl implements BService {
    @Autowired
    public AService aService;
}

此時ASerivce和BService構成回圈依賴的關系：

測驗類：`com.example.demo.service.AServiceTest`

package com.example.demo.service;

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;

@SpringBootTest
class AServiceTest {
    @Autowired
    AService aService;

    @Test
    public void test(){
        aService.zaWaLuDo();
    }

}

此時運行test方法，將會報錯：

java.lang.IllegalStateException: Failed to load ApplicationContext

	at org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:132)
	at org.springframework.test.context.support.DefaultTestContext.getApplicationContext(DefaultTestContext.java:124)
	at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:118)
	at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:83)
	at org.springframework.boot.test.autoconfigure.SpringBootDependencyInjectionTestExecutionListener.prepareTestInstance(SpringBootDependencyInjectionTestExecutionListener.java:43)
	at org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:248)
	at org.springframework.test.context.junit.jupiter.SpringExtension.postProcessTestInstance(SpringExtension.java:138)
	at org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.lambda$invokeTestInstancePostProcessors$8(ClassBasedTestDescriptor.java:363)
	at org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.executeAndMaskThrowable(ClassBasedTestDescriptor.java:368)
	at org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.lambda$invokeTestInstancePostProcessors$9(ClassBasedTestDescriptor.java:363)
......省略.....
Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'AServiceImpl': Unsatisfied dependency expressed through field 'bService'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'BServiceImpl': Unsatisfied dependency expressed through field 'aService'; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'AServiceImpl': Requested bean is currently in creation: Is there an unresolvable circular reference?
	at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.resolveFieldValue(AutowiredAnnotationBeanPostProcessor.java:659)
	at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:639)
	at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:119)

最重要的一句應該是：

美觀處理過：
Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: 
	Error creating bean with name 'AServiceImpl': Unsatisfied dependency expressed through field 'bService'; 
nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: 
	Error creating bean with name 'BServiceImpl': Unsatisfied dependency expressed through field 'aService'; 
nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: 
	Error creating bean with name 'AServiceImpl': Requested bean is currently in creation: 
		Is there an unresolvable circular reference?

Spring提醒我們可能存在circular reference，就是大名鼎鼎的回圈依賴，

解決辦法

在其中任意一個屬性注入@Autowired上加入懶加載@Lazy即可跑通，比如在AService的實作類中加入：

package com.example.demo.service.impl;

import com.example.demo.service.AService;
import com.example.demo.service.BService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.Lazy;
import org.springframework.stereotype.Service;

@Service
public class AServiceImpl implements AService {

    @Autowired
    @Lazy //懶加載
    public BService bService;

    @Override
    public void zaWaLuDo(){
        System.out.println("ToKiOToMaLei!");
    }
}

此時，運行測驗方法test()的運行結果就是：

ToKiOToMaLei!

說明aService.zaWaLuDo()方法執行成功

原始碼分析

參考：https://www.zhihu.com/question/438247718

主要是靠Spring中（人為定義）的三級快取有關：
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry#getSingleton(java.lang.String, boolean)

第一級快取：**Map<String, Object> singletonObjects**
第一級快取的作用？

用于存盤單例模式下創建的Bean實體（已經創建完畢），

該快取是對外使用的，指的就是使用Spring框架的程式員，

存盤什么資料？

K：bean的名稱

V：bean的實體物件, 或者說：“成品”物件（有代理物件則指的是代理物件，已經創建完畢）

第二級快取：**Map<String, Object> earlySingletonObjects**
第二級快取的作用？

用于存盤單例模式下創建的Bean實體（該Bean被提前暴露的參考,該Bean還在創建中），

該快取是對內使用的，指的就是Spring框架內部邏輯使用該快取，

存盤的資料：

K：bean的名稱

V：bean的實體物件，“半成品”物件（有代理物件則指的是代理物件，該Bean還在創建中）

第三級快取：**Map<String, ObjectFactory<?>> singletonFactories**
第三級快取的作用？

通過ObjectFactory物件來存盤單例模式下提前暴露的Bean實體的參考（正在創建中），

該快取是對內使用的，指的就是Spring框架內部邏輯使用該快取，

此快取是解決回圈依賴最大的功臣

存盤什么資料？

K：bean的名稱

V：ObjectFactory，該物件持有提前暴露的bean的參考

一、注入AService時，首先進入org.springframework.beans.factory.support.AbstractBeanFactory#doGetBean:

				// Create bean instance.
				if (mbd.isSingleton()) {
					sharedInstance = getSingleton(beanName, () -> {
						try {
							return createBean(beanName, mbd, args);
						}
                        ...
                        }

看看getSingleton方法的原型，org.springframework.beans.factory.support.DefaultSingletonBeanRegistry#getSingleton(java.lang.String, org.springframework.beans.factory.ObjectFactory<?>)：

public Object getSingleton(String beanName, ObjectFactory<?> singletonFactory)

所以此時doGetBean方法會進入lambda方法中的，呼叫createBean方法來得到一個ObjectFactory
接著我們進入到org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory的doCreateBean方法, 打上斷點看看：

當beanName='AServiceImpl'的時候，先根據反射創建了一個Object類的AServiceImpl的bean，里面的BService為null：

protected Object doCreateBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args){
 	...省略...
        Object bean = instanceWrapper.getWrappedInstance(); //ASericeImpl@4686
    	Class<?> beanType = instanceWrapper.getWrappedClass(); //beanType = "class com.example.demo.service.impl.AServiceImpl"
    ...省略...
}

判斷該bean是否已經被提前暴露

protected Object doCreateBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args)
			throws BeanCreationException {
    	...省略...
        
        //判斷該bean是否已經被提前暴露
       	//Eagerly cache singletons to be able to resolve circular references
		// even when triggered by lifecycle interfaces like BeanFactoryAware.
		boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
				isSingletonCurrentlyInCreation(beanName));
    	//如果是，就呼叫addSingletonFactory方法，
		if (earlySingletonExposure) {
			if (logger.isTraceEnabled()) {
				logger.trace("Eagerly caching bean '" + beanName +
						"' to allow for resolving potential circular references");
			}
			addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
		}
   	 ...省略...
}

若沒有被提前暴露，就進入到陳述句：

		// Initialize the bean instance.
		Object exposedObject = bean;
		try {
            //呼叫populateBean方法后，AService中的BService屬性就不再是null，而是一個$Proxy@4981$，
            //應該是個代理的物件，解決注入的燃眉之急
			populateBean(beanName, mbd, instanceWrapper);
            //做一些初始化的操作
			exposedObject = initializeBean(beanName, exposedObject, mbd);
		}

將該bean暴露

		// Register bean as disposable.
		try {
			registerDisposableBeanIfNecessary(beanName, bean, mbd);
		}

接著就將其回傳

return exposedObject;

此時，exposedObject物件里的bService還是 $Proxy$

二、回到org.springframework.beans.factory.support.AbstractBeanFactory#doGetBean方法：

				if (mbd.isSingleton()) {
					sharedInstance = getSingleton(beanName, () -> {
						try {
                            //這時候回到了這里，lambda運算式會得到上面的exposedObject
							return createBean(beanName, mbd, args);
						}

此時會回到getSingleton方法中，進入getSingleton方法內部：

				try {
                    //其中的singletonFactory呼叫getObject就是lambda運算式回傳的exposedObject，也就是里面的bService還是$Proxy$
					singletonObject = singletonFactory.getObject();
					//標記為新的單例bean
                    newSingleton = true;
				}

最后我們看看，this.singletonObjects中的AService：

可以看到用bService中注入了一個神秘的 $Proxy$ ，然后寫入了一級快取中，經除錯后發現是在getSingleton方法中，呼叫addSingleton方法寫入的，這時候二級、三級快取全程都沒寫入過資料，

				if (newSingleton) {
					addSingleton(beanName, singletonObject);
				}

三、回到test()方法：

    @Test
    public void test(){
        aService.zaWaLuDo();
    }

此時，aService中的bService還是個&Proxy$

這時候繼續就會正常執行aService.zaWaLuDo_()_，程式正常結束，

總結下就是這種情況下，aService會由doCreateBean方法創建，而bService是某種代理的東西存在其中，

四、我們改寫一下兩個Service，使AService需要呼叫BService的方法：

AServiceImpl

package com.example.demo.service.impl;

import com.example.demo.service.AService;
import com.example.demo.service.BService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.Lazy;
import org.springframework.stereotype.Service;

@Service
public class AServiceImpl implements AService {

    @Autowired
    @Lazy
    public BService bService;

    @Override
    public void zaWaLuDo(){
        System.out.println("ToKiOToMaLei!");
        bService.starPuLaXin();
    }
}

BServiceImpl

package com.example.demo.service.impl;

import com.example.demo.service.AService;
import com.example.demo.service.BService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class BServiceImpl implements BService {
    @Autowired
    public AService aService;

    @Override
    public void starPuLaXin() {
        System.out.println("Za WaLuDo!");
    }
}

我們先在執行aServuce,zaWaLuDo()之前打個斷點看看此時的aService是什么情況：

可以看到跟上面的情況是一樣的，

這個時候我們在org.springframework.beans.factory.support.AbstractBeanFactory#getBean(java.lang.String)方法打個斷點看看，這時候會進入org.springframework.beans.factory.support.AbstractBeanFactory#doGetBean方法，執行：

		// Eagerly check singleton cache for manually registered singletons.
		Object sharedInstance = getSingleton(beanName);

sharedInstance是這樣的：

里面的bService還是一個 $Proxy$ ，我們一直除錯到getBean方法結束，他最侄訓進入到jdk代理org.springframework.aop.framework.JdkDynamicAopProxy中執行方法：

//方法引數
Object[] argsToUse = AopProxyUtils.adaptArgumentsIfNecessary(method, args);
//target根據引數argsToUse執行方法method的結果
retVal = AopUtils.invokeJoinpointUsingReflection(target, method, argsToUse);

于是就會執行結果：

ToKiOToMaLei!
Za WaLuDo!

五、研究一下aService和bService的注入程序，二者都會進入doCreateBean方法，aService會入上面的程序一樣被創建，我們研究一下bService的創建程序，當執行到:

		try {
			populateBean(beanName, mbd, instanceWrapper);
			exposedObject = initializeBean(beanName, exposedObject, mbd);
		}

執行完populateBean方法，exposedObject(即將成型的bService)就被注入了aService：

但是這個aService中的bService實際上還只是個 $Proxy$ ，在接下來的程序中，aService中的bService一直都還只是個 $Proxy$ ，就像bService中的aService也一直都還是個 $Proxy$ ，所以可以推斷，這種情況下Spring不關心二者是否真的存了個“成品”物件，只是有個“半成品”物件利用通過jdk動態代理AOP執行bService的方法而已, 最侄訓到：org.springframework.aop.framework.JdkDynamicAopProxy#invoke中執行bService的方法.

情況二：構造器注入回圈依賴示例

com.example.demo.service.CService

package com.example.demo.service;

public interface CService {
    void goldExperience();
}

com.example.demo.service.DService

package com.example.demo.service;

public interface DService {
}

com.example.demo.service.impl.CServiceImpl

package com.example.demo.service.impl;

import com.example.demo.service.CService;
import com.example.demo.service.DService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class CServiceImpl implements CService {

    private DService dService;

    @Autowired
    public CServiceImpl(DService dService) {
        this.dService = dService;
    }

    @Override
    public void goldExperience() {
        System.out.println("MUDAMUDAMUDAMUDA!!!!");
    }
}

com.example.demo.service.impl.DServiceImpl

package com.example.demo.service.impl;

import com.example.demo.service.CService;
import com.example.demo.service.DService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class DServiceImpl implements DService {
    private CService cService;

    @Autowired
    public DServiceImpl(CService cService) {
        this.cService = cService;
    }
}

com.example.demo.service.CServiceTest

package com.example.demo.service;

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;

import static org.junit.jupiter.api.Assertions.*;

@SpringBootTest
class CServiceTest {
    @Autowired
    CService cService;

    @Test
    public void test(){
        cService.goldExperience();
    }
}

運行測驗方法，同樣報回圈依賴的錯誤，

解決方法

在引數里添加@Lazy方法：

package com.example.demo.service.impl;

import com.example.demo.service.CService;
import com.example.demo.service.DService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.Lazy;
import org.springframework.stereotype.Service;

@Service
public class CServiceImpl implements CService {

    private DService dService;

    @Autowired
    public CServiceImpl(@Lazy DService dService) { //引數上添加了@Lazy方法
        this.dService = dService;
    }

    @Override
    public void goldExperience() {
        System.out.println("MUDAMUDAMUDAMUDA!!!!");
    }
}

原始碼分析

跟情況一一樣，也是通過注入一個"假"的物件解決：

將代碼改成情況一的呼叫dService的方法也是通過jdk動態代理AOP解決，

Springboot解決回圈依賴的原始碼閱讀

在application.yml中開啟:

spring:
  main:
    allow-circular-references: true

我們先除錯一下看看：

發現cService中的dService是貨真價實的

我們嘗試除錯看看能不能搞清楚Springboot到底是怎么注入的，在老地方org.springframework.beans.factory.support.AbstractBeanFactory#getBean(java.lang.String)打個斷點，研究一下dService是怎么做的：

	@Override
	public Object getBean(String name) throws BeansException {
		return doGetBean(name, null, null, false);
	}

一直除錯到org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor才終于有點眉目:

			if (value != null) {
				ReflectionUtils.makeAccessible(field);
				field.set(bean, value);
			}

此時的各變數是這樣的：

field.set(bean, value)方法內部是getFieldAccessor_(_obj_)_.set_(_obj, value_)_;后面的set_(_obj, value_)_就是已編譯好的位元組碼了，執行下一步后，dService中缺乏的cService就有東西了，所以可以推測是一個寫入程序，

我們看看其巨長無比的呼叫堆疊：

在這句所在的inject方法頭部打個注解，看看有沒有頭緒，cService是從哪來的，重新啟動一下

當創建dService時，會進入到該方法體，初始的時候value啥也沒有，接著會進到：

...
	value = https://www.cnblogs.com/excelsiorly/archive/2022/03/10/resolveFieldValue(field, bean, beanName); //進入本句
...
    if (value != null) {
        ReflectionUtils.makeAccessible(field);
        field.set(bean, value);
    }

一直呼叫到org.springframework.beans.factory.config.DependencyDescriptor#resolveCandidate方法：

	public Object resolveCandidate(String beanName, Class<?> requiredType, BeanFactory beanFactory)
			throws BeansException {

		return beanFactory.getBean(beanName); //beanName="CServiceImpl"
	}

此時由進入到了老朋友org.springframework.beans.factory.support.AbstractBeanFactory#getBean(java.lang.String)方法中，回傳了一個CServiceImpl物件給上面的resolveFieldValue(field, bean, beanName);接著就進入到field.set(bean, value);中將其注入，那么神奇的事情肯定是發生在beanFactory.getBean(beanName);中

老辦法，再打個斷點，回到取CServiceImpl物件的時候看看：

接著他會進入老朋友org.springframework.beans.factory.support.AbstractBeanFactory#getBean(java.lang.String)方法中，我們step into，在執行完Object sharedInstance = getSingleton(beanName)后就有了CServiceImpl物件，只不過他的dService還是null:

protected <T> T doGetBean(
			String name, @Nullable Class<T> requiredType, @Nullable Object[] args, boolean typeCheckOnly)
			throws BeansException {

		String beanName = transformedBeanName(name);
		Object beanInstance;

		// Eagerly check singleton cache for manually registered singletons.
		Object sharedInstance = getSingleton(beanName);
    ....

最后還是會field.set(bean, value);給dService先注入，

看到這里感覺非常混亂，感徑訓是按那幅圖來看吧：

在創建cService呼叫doCreateBean方法，執行了addSingletonFactory：

{
	addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
}
// Initialize the bean instance.
		Object exposedObject = bean;
		try {
			populateBean(beanName, mbd, instanceWrapper);
			exposedObject = initializeBean(beanName, exposedObject, mbd);
		}

三級快取this.singletonFactories 中便存入了“半成品”物件的自己：

cService執行到populateBean的時候，旋即進入到了dService的doCreateBean
dService通過addSingletonFactory也往三級快取this.singletonFactories 中便存入了“半成品”物件的自己，此時c、d都在三級快取this.singletonFactories里：
當dService執行了下一句，即populateBean之后，cService從三級快取換入到了二級快取this.earlySingletonObjects：

此時其內部的dService為空：
到這一步，我們再理清一下呼叫鏈：
dService執行到getSingleton后：

// Create bean instance.
if (mbd.isSingleton()) {
    sharedInstance = getSingleton(beanName, () -> {
        try {
            return createBean(beanName, mbd, args);
        }

在getSingleton內部執行了addSingleton_(_beanName, singletonObject_)_之后，便把自己寫入了三級快取this.singletonObjects中，并把半成品的cService注入到自己中，形如：

之后就回到了cService->populateBean的執行，最終去到了field.set_(_bean, value_)_中，此時bean為cService, value為dService（內部的cService的dService仍未空），執行完之后，就鏈接上了！神奇！：
待cService ->populateBean執行結束后，回到cService -> doGetBean的執行，進行完cService -> getSingleton后，二級快取this.earlySingletonObjects中的cService也移入了一級快取this.singletonObjects之中：
此時，基本上解決了回圈參考的問題，

總結一下

我們認為一個物件的創建可分為兩步：
1. 實體化：可認為是一個在記憶體中劃分空間的程序
2. 初始化：為該物件的屬性賦值的程序
cService在創建的時候，先只進行了實體化，此時是一個“半成品”物件，寫入三級快取中存盤；
旋即進行其所需要的dService物件的創建，而dService會進行實體化之后，也將“半成品”的自己寫入三級快取中，
此時cService會嘗試進行初始化（為屬性賦值），他需要寫入dService，但事實上會為dService賦值為null，然后寫入二級快取，此時的cService仍然是個“半成品”，
接著又回到dService的創建，這時候他也會進行一個初始化，將二級佇列中的完成了“假”的初始化的“半成品”物件cService，給自己所需的屬性注入，完成了初始化程序，并寫入了一級快取，
然后就回到了cService還在進行中的創建程序，這個時候cService是個“假”的“半成品”，在二級快取，而dService是個真的成品，他確實擁有了cService物件，
cService這時候也會將一級快取中的dService，一個真正完成了初始化的物件，注入到自己的屬性中，這個時候二者終于完成了互相注入，cService也完成了初始化，進入了一級快取，回圈依賴得以解決，

為什么需要三級快取？

我大概總結了一下流程：

可以看出，互相依賴的兩個物件有三種狀態：

只有“存在”，沒有內部的“半成品”形態一物件
注入了“半成品”形態一物件的“半成品”形態二物件
注入了“半成品”形態二物件的完全體“成品”物件

因有客觀上有三種狀態的物件，所以才利用三級快取來分別存盤，比較科學的說明如下：

三級快取

singletonObjects

一級快取， Cache of singleton objects bean name --> bean instance，存放完整物件，

earlySingletonObjects

二級快取， Cache of early singleton objects bean name --> bean instance 提前曝光的BEAN快取，存放半成品物件，

singletonFactories

三級快取， Cache of singleton factories bean name --> ObjectFactory，需要的物件被代理時，就必須使用三級快取（否則二級就夠了），解決回圈依賴中存在aop的問題存放 lambda 運算式和物件名稱的映射，

作者：JavaEdge
鏈接：https://www.zhihu.com/question/438247718/answer/2331910821
來源：知乎
著作權歸作者所有，商業轉載請聯系作者獲得授權，非商業轉載請注明出處，

參考

https://www.zhihu.com/question/438247718
https://blog.csdn.net/qq_18298439/article/details/88818418

本文僅為分享學習經歷，歡迎批評指正

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/440488.html

標籤：其他

上一篇：flowable 更新說明

下一篇：為什么年輕一代連作業系統基礎都不懂？

Springboot回圈依賴實踐紀實

@Lazy注解解決回圈依賴

情況一：只有簡單屬性關系的回圈依賴

測驗類：com.example.demo.service.AServiceTest

解決辦法

原始碼分析

情況二：構造器注入回圈依賴示例

解決方法

原始碼分析

Springboot解決回圈依賴的原始碼閱讀

總結一下

為什么需要三級快取？

三級快取

singletonObjects

earlySingletonObjects

singletonFactories

參考

測驗類：`com.example.demo.service.AServiceTest`