Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "how to solve the problem of Spring circular dependence". Many people will encounter such a dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Preface

The problem of circular dependence is a bad street interview question. before detoxification, let's review two knowledge points:

When we first learned Spring, we knew IOC, control reversal, it will manually create the control of the object in the program, to the Spring framework to manage, we do not need to manually go to all kinds of new XXX.

Although it is Spring management, don't you have to create objects? there are many steps to create Java objects, such as new XXX, serialization, clone (), etc., but Spring creates objects through reflection + factory and puts them in containers. We usually assign values to object attributes before using them. It can be understood that there are two steps.

All right, just make an impression of these two steps, and then let's move on to circular dependency. Let's start with the concept of circular dependency.

What is circular dependency?

The so-called circular dependency means that A depends on BJournal B and A, and there is a circular dependency between them. Or A depends on B, B, C, C and A, forming a circular dependency. Or rely on yourself. The dependencies between them are as follows:

Here, taking the direct interdependence of two classes as an example, their implementation code may be as follows:

Public class BeanB {private BeanA beanA; public void setBeanA (BeanA beanA) {this.beanA = beanA;}} public class BeanA {private BeanB beanB; public void setBeanB (BeanB beanB) {this.beanB = beanB;}}

The configuration information is as follows (the same is injected with annotations, but the configuration file is used for ease of understanding):

After Spring starts, reading the configuration file above will first instantiate An in order, but when it is created, it is found that it depends on B, then it is de-instantiated B, and it is also found that it depends on A. how does Nima do? Infinite cycle.

Spring "certainly" will not let this happen. As we said in the preface, the Spring instantiation object is divided into two steps. The first step is to create an original object without setting properties, which can be understood as "semi-finished product"-- officially called early reference to An object (EarlyBeanReference). So when instantiating B, it is found that it depends on A, and B will set the "semi-finished object" to complete the instantiation first. Now that B is instantiated, A can get a reference to B and complete instantiation, which is actually Spring's idea of solving circular dependencies.

It doesn't matter if you don't understand, first have a general impression, and then let's look at how Spring is solved from the source code.

Source code detoxification

Code version: 5.0.16.RELEASE

Before the Spring IOC container reads the Bean configuration to create an Bean instance, it must be instantiated. Only after the container is instantiated can you get the Bean instance from the IOC container and use it. Circular dependency occurs in the process of instantiating Bean, so let's review the process of obtaining Bean first.

Get Bean process

The simplified process for obtaining bean instances in the Spring IOC container is as follows (excluding various packaging and inspection processes)

Approximate flow order (can be combined with the source code, I will not post, if I post too much, vomiting, vomiting):

The process starts with the getBean method. GetBean is a shell method, and all the logic goes directly to the doGetBean method.

TransformedBeanName converts name to real beanName (name may be the case where FactoryBean begins with the & character or has an alias, so it needs to be converted)

Then use the getSingleton (beanName) method to find out whether the instance sharedInstance exists in the cache (the same container in Spring will only be created once for a single instance. If you get the bean later, you can get it directly from the cache)

If any, sharedInstance may be a fully instantiated bean or a raw bean, so it can be returned after getObjectForBeanInstance processing.

Of course, sharedInstance may also be null, so the logic of creating bean will be executed and the result will be returned.

In the third step, we mentioned the concept of caching, which is the three-level cache designed by Spring to solve the problem of singleton circular dependency.

/ * * Cache of singleton objects: bean name-- > bean instance * / private final Map singletonObjects = new ConcurrentHashMap; / * * Cache of singleton factories: bean name-- > ObjectFactory * / private final Map singletonFactory = this.singletonFactories.get (beanName) If (singletonFactory! = null) {/ / third-level cache, move it to the second-level cache. GetObject () will talk about singletonObject = singletonFactory.getObject (); this.earlySingletonObjects.put (beanName, singletonObject); this.singletonFactories.remove (beanName) } return singletonObject;}

If there is no cache, we will create it, and then take a singleton object as an example, and then take a look at the logic of creating a bean (curly braces indicate that the inner class calls the method):

1. The creation of bean starts with the following code, an anonymous inner class method parameter (always feels that the readability of Lambda is not as easy to understand as the inner class)

If (mbd.isSingleton ()) {sharedInstance = getSingleton (beanName, ()-> {try {return createBean (beanName, mbd, args);} catch (BeansException ex) {destroySingleton (beanName); throw ex;}}); bean = getObjectForBeanInstance (sharedInstance, name, beanName, mbd);}

There are two main methods inside the getSingleton () method.

Public Object getSingleton (String beanName, ObjectFactory singletonFactory) {/ / create singletonObject singletonObject = singletonFactory.getObject (); / / put singletonObject into the cache addSingleton (beanName, singletonObject);}

The implementation of 2.getObject () anonymous inner class actually calls createBean (beanName, mbd, args).

3. Go inside, the main implementation logic is in the doCreateBean method, first create an original bean object through createBeanInstance

4. Then addSingletonFactory adds the bean factory object to the singletonFactories cache (tertiary cache)

5. Fill the attributes into the original bean object through the populateBean method, and parse the dependencies. Suppose you find the dependency B when you fill the attributes after creating A, and then when you create the dependency object B, you find that the dependency An is the same process and go to getBean (A). At this time, the third-level cache already has the "semi-finished product" of beanA. At this point, the original reference to the An object can be injected into the B object (and moved to the secondary cache) to solve the circular dependency problem. At this point, the getObject () method returns the fully instantiated bean even if the execution is finished.

6. Finally, call addSingleton to put the fully instantiated bean object into the singletonObjects cache (first-level cache) and finish the work.

Spring solves circular dependency

It is suggested to match the "source code" to see the logic diagram below for a better meal.

In fact, the process has already been mentioned above, combined with the above picture, let's take a look at the details and sort it out again in vernacular:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Spring to create a bean is divided into two steps: creating the original bean object, then populating the object properties and initializing

Every time before creating a bean, we will check the cache to see if there is the bean. Because it is a singleton, there can only be one.

When we create the original object of beanA and put it in the third-tier cache, it's time to populate the object properties, then we find that we rely on beanB, and then we create beanB. In the same process, when we create the beanB fill property, we find that it depends on beanA, and it is the same process. The difference is that the original object beanA just put into the third-level cache can be found at this time, so there is no need to continue to create it. Use it to inject beanB to complete the creation of beanB

Now that the beanB has been created, the beanA can complete the steps of populating the properties, and then execute the rest of the logic, which is completed in a closed loop

This is the process for Spring to solve circular dependencies in singleton mode.

But in this place, no matter who looks at the source code, there will be a little doubt. Why do you need a three-level cache? it is enough for me to rush to the second level.

The revolution has not yet succeeded, but comrades still need to work hard.

When following the source code, it is found that when you need to reference the "semi-finished product" of beanA to create a beanB, the "pre-reference" will be triggered, that is, the following code:

ObjectFactory singletonFactory = this.singletonFactories.get (beanName); if (singletonFactory! = null) {/ / level 3 cache singletonObject = singletonFactory.getObject (); this.earlySingletonObjects.put (beanName, singletonObject); this.singletonFactories.remove (beanName);}

SingletonFactory.getObject () is an interface method. The specific implementation method here is in

Protected Object getEarlyBeanReference (String beanName, RootBeanDefinition mbd, Object bean) {Object exposedObject = bean; if (! mbd.isSynthetic () & & hasInstantiationAwareBeanPostProcessors ()) {for (BeanPostProcessor bp: getBeanPostProcessors ()) {if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp / / this sentence is the core of such a long paragraph, that is, when the bean is to be exposed in advance, / / give a chance to customize the operation bean / / by rewriting the getEarlyBeanReference method of the post processor. / / it is worth noting that if it is exposed in advance, but not referenced in advance. Then the post processor does not take effect! / / this is also the meaning of the existence of three-level cache, otherwise the second-level cache can solve the problem of circular dependency exposedObject = ibp.getEarlyBeanReference (exposedObject, beanName) } return exposedObject;}

This method is why Spring uses the third-level cache instead of the second-level cache. Its purpose is for post-processing. If there is no AOP post-processing, it will not go into the if statement and directly return exposedObject, which is equivalent to doing nothing, and the second-level cache will be enough.

So it is concluded that this three-level cache should have something to do with AOP, continue.

In the source code of Spring, getEarlyBeanReference is the default method of the SmartInstantiationAwareBeanPostProcessor interface. The only class that really implements this method is * * AbstractAutoProxyCreator**, which is used for pre-exposed AOP proxies.

@ Override public Object getEarlyBeanReference (Object bean, String beanName) throws BeansException {Object cacheKey = getCacheKey (bean.getClass (), beanName); this.earlyProxyReferences.put (cacheKey, bean); / / A pair of bean Spring AOP agents return wrapIfNecessary (bean, beanName, cacheKey) in advance;}

This is a bit dry, let's have a small demo, we all know that Spring AOP, transactions, etc. are implemented through proxy objects, while the proxy objects of transactions are automatically completed by the automatic proxy creator. In other words, what Spring finally puts into the container is a proxy object, not the original object. Suppose we have the following business code:

@ Service public class HelloServiceImpl implements HelloService {@ Autowired private HelloService helloService; @ Override @ Transactional public Object hello () {return "Hello JavaKeeper";}}

This Service class uses transactions, so a JDK dynamic proxy object, Proxy, is eventually generated. As it happens, it also has its own circular dependency, which perfectly meets the needs of our scenario.

Let's customize a post-processing to see the effect:

@ Component public class HelloProcessor implements SmartInstantiationAwareBeanPostProcessor {@ Override public Object getEarlyBeanReference (Object bean, String beanName) throws BeansException {System.out.println ("early exposure:" + beanName); return bean;}}

As you can see, there is our own implementation of HelloProcessor in the calling method stack, indicating that this bean will be processed by the AOP agent.

From the source code, let's take a look at the process of creating a bean that circulates itself:

Protected Object doCreateBean (...) {... Boolean earlySingletonExposure = (mbd.isSingleton () & & this.allowCircularReferences & & isSingletonCurrentlyInCreation (beanName)) / / if you need to expose in advance (support circular dependency), register an ObjectFactory to the third-level cache if (earlySingletonExposure) {/ / add the bean factory object to the singletonFactories cache and get the early reference to the original object / / anonymous inner method getEarlyBeanReference is a method of the post processor / / SmartInstantiationAwareBeanPostProcessor, / / its effect is to ensure that you are cyclically dependent It is the proxy object addSingletonFactory (beanName, ()-> getEarlyBeanReference (beanName, mbd, bean)) that is entered by another Bean @ Autowire. } / / Note here: if it is cyclically dependent here, it will go to the getEarlyBeanReference above, thus creating a proxy object to be transferred from the third-level cache to the second-level cache / / notice that the object is still in the second-level cache and not in the first-level cache. And the next two steps at this time are still using exposedObject, which is still the original object ~ ~ populateBean (beanName, mbd, instanceWrapper); exposedObject = initializeBean (beanName, exposedObject, mbd) / / because the transaction AOP automatic proxy creator after the getEarlyBeanReference creates the proxy, the initializeBean will not be created repeatedly.) / / so after these two big steps, the exposedObject is still the original object, and the proxy object created through getEarlyBeanReference is still in the third-level cache. / / Circular dependency check if (earlySingletonExposure) {/ / Note the false passed by the second parameter here It means that the getObject () method will not be called again in the third-level cache, and the proxy object is still in the second-level cache, so what we have here is a proxy object / / finally assigned to exposedObject and then return out, and finally added to the first-level cache by addSingleton (). This ensures that our container is actually a proxy object in the end. Instead of the original object ~ Object earlySingletonReference = getSingleton (beanName, false) If (earlySingletonReference! = null) {if (exposedObject = = bean) {exposedObject = earlySingletonReference;}}...}}

Self-explanation:

Q: I still don't understand. Why is it so designed? even if there is a proxy, it is OK to cache a proxy at the second level. | Why use a three-tier cache?

Let's take a look at the relevant code. Let's say we are now in a secondary cache architecture. When we create A, we don't know if there is a circular dependency, so we put in the secondary cache to expose ahead of time, and then create B, which is also put into the secondary cache. At this time, we find that we are cyclically dependent on A, and we go to the secondary cache to find it. Yes, but if there is an AOP proxy at this time, what if we want a proxy object that is not the original object? Can only change the logic, in the first step, regardless of 3721, all Bean will complete the AOP proxy, if this is the case, there is no need for three-level cache, but this is not only unnecessary, but also contrary to the design of Spring's lifecycle combining AOP and Bean.

Therefore, Spring "superfluously" encapsulates the instance into ObjectFactory (tertiary cache). The main key point is that the getObject () method does not return the instance directly, but uses the getEarlyBeanReference method of SmartInstantiationAwareBeanPostProcessor to process the bean for the instance. That is to say, when the post processor exists in Spring, all singleton bean will be exposed to the tertiary cache in advance after instantiation, but not all bean have circular dependencies. That is, the steps from the third-level cache to the second-level cache may not be performed. It may be created directly after exposure, and will be directly added to the first-level cache without being referenced in advance. Therefore, it is possible to ensure that only bean that is exposed in advance and referenced will perform this post-processing.

Protected Object getSingleton (String beanName, boolean allowEarlyReference) {Object singletonObject = this.singletonObjects.get (beanName); if (singletonObject = = null & & isSingletonCurrentlyInCreation (beanName)) {synchronized (this.singletonObjects) {singletonObject = this.earlySingletonObjects.get (beanName) If (singletonObject = = null & & allowEarlyReference) {/ / three-level cache acquisition. The storage / / getObject () method in key=beanName value=objectFactory,objectFactory is used to get the instance ObjectFactory singletonFactory = this.singletonFactories.get (beanName) exposed in advance. If (singletonFactory! = null) {/ / third-level cache, move it to the secondary cache singletonObject = singletonFactory.getObject (); this.earlySingletonObjects.put (beanName, singletonObject); this.singletonFactories.remove (beanName) } return singletonObject;} boolean earlySingletonExposure = (mbd.isSingleton () & & this.allowCircularReferences & & isSingletonCurrentlyInCreation (beanName)); if (earlySingletonExposure) {if (logger.isDebugEnabled ()) {logger.debug ("Eagerly caching bean'" + beanName + "'to allow for resolving potential circular references") } / / add the bean factory object to the singletonFactories cache and get the early reference to the original object / / anonymous internal method getEarlyBeanReference is a method of the post processor / / SmartInstantiationAwareBeanPostProcessor, / / its effect is to ensure that it is cyclically dependent Even if it is entered by another Bean @ Autowire, it is the proxy object ~ AOP automatic proxy creator ~ addSingletonFactory (beanName, ()-> getEarlyBeanReference (beanName, mbd, bean)) that will be created in this method. }

Ask again: the AOP proxy object is put into the three-level cache in advance, without property filling and initialization, how does the proxy ensure the injection of dependent properties?

This also involves the implementation of the dynamic proxy in Spring, whether it is the cglib proxy or the proxy class generated by the jdk dynamic proxy, the target object target will be saved in the last generated proxy $proxy, when the $proxy method is called, the h.invoke will be called back, and the h.invoke will call back the original method of the target object target. So, in fact, when the AOP dynamic proxy, the original bean has been saved in the early exposure agent, and then the original bean continues to complete the attribute filling and initialization operation. Because traget is a reference to the original bean in the AOP proxy $proxy, the subsequent improvement of the original bean is equivalent to the perfection of the target in Spring AOP, which ensures that the attributes of the AOP are populated and initialized!

Non-singleton circular dependence

After looking at the circular dependency of the singleton pattern, let's take a look at the non-singleton case, assuming that our configuration file looks like this:

Start Spring and the result is as follows:

Error creating bean with name 'beanA' defined in class path resource [applicationContext.xml]: Cannot resolve reference to bean' beanB' while setting bean property 'beanB'; Error creating bean with name' beanB' defined in class path resource [applicationContext.xml]: Cannot resolve reference to bean 'beanA' while setting bean property' beanA'; Caused by: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'beanA': Requested bean is currently in creation: Is there an unresolvable circular reference?

Dependency injection cannot be done for prototype-scoped bean,Spring containers because the Spring container does not cache prototype-scoped bean, so an bean being created cannot be exposed in advance.

The reason is easy to understand. The prototype pattern creates an instance object for each request. Even if the cache is added and there are too many circular references, it will be troublesome. Therefore, Spring does not support this method and directly throws an exception:

If (isPrototypeCurrentlyInCreation (beanName)) {throw new BeanCurrentlyInCreationException (beanName);}

Constructor circular dependency

What we talked about above is the circular dependency problem of singleton bean injected through Setter method. The partners using Spring also know that dependency injection also includes constructor injection and factory method injection (rarely used), so if constructor injection also has cyclic dependency, can it be done?

Let's change the code and configuration file again.

Public class BeanA {private BeanB beanB; public BeanA (BeanB beanB) {this.beanB = beanB;}} public class BeanB {private BeanA beanA; public BeanB (BeanA beanA) {this.beanA = beanA;}}

Execution result, exception again

Take a look at the official statement.

Circular dependencies

If you use predominantly constructor injection, it is possible to create an unresolvable circular dependency scenario.

For example: Class A requires an instance of class B through constructor injection, and class B requires an instance of class A through constructor injection. If you configure beans for classes An and B to be injected into each other, the Spring IoC container detects this circular reference at runtime, and throws a BeanCurrentlyInCreationException.

One possible solution is to edit the source code of some classes to be configured by setters rather than constructors. Alternatively, avoid constructor injection and use setter injection only. In other words, although it is not recommended, you can configure circular dependencies with setter injection.

Unlike the typical case (with no circular dependencies), a circular dependency between bean An and bean B forces one of the beans to be injected into the other prior to being fully initialized itself (a classic chicken-and-egg scenario).

It probably means:

If you mainly use constructor injection, circular dependency scenarios cannot be solved. It is recommended that you use setter injection instead of constructor injection.

In fact, it does not mean that as long as it is a constructor injection, there will be a circular dependency problem. When Spring creates a Bean, it is created according to the natural order by default. Let's call the first created bean the main bean, and the above An is the main bean. As long as the way the main bean injection depends on bean is setter, it doesn't matter whether it depends on bean injection, it can be solved, and vice versa

So above we AB circular dependency problem, as long as An is injected in setter, there will be no circular dependency problem.

The interviewer asked: why?

Spring's solution to circular dependency relies on Bean's concept of "intermediate state", which refers to a state that has been instantiated but not yet initialized. The process of instantiation is created through the constructor, if A has not been created, how can it be exposed in advance, so the circular dependency of the constructor can not be solved, I have always thought that there should be a chicken before an egg.

Small summary | wouldn't it be a problem if an uninitialized type An object was injected into B in advance?

Although an uninitialized An object is injected into B in advance when creating B, a reference to the An object injected into B is always used in the process of creating A, and then An is initialized based on this reference. so there's no problem.

How does Spring solve circular dependencies?

In order to solve the problem of singleton circular dependency, Spring uses three-level cache. The first cache is singleton pool (singletonObjects), the second cache is pre-exposure object (earlySingletonObjects), and the third cache is pre-exposure object factory (singletonFactories).

Suppose An and B loop reference, instantiate A, put it into the three-level cache, then fill the attribute, find that it depends on B, the same process is also instantiated and put into the three-level cache, and then find that you rely on A when you fill the attribute. At this time, you can find the early exposed A from the cache. If there is no AOP proxy, the original object of A will be injected into B directly after the initialization of B is completed. After attribute filling and initialization, B completes the remaining steps of A. if there is an AOP agent, do AOP processing to get the object An after the proxy, inject B, and go through the rest of the process.

Why use a three-tier cache? Can secondary caching solve circular dependencies?

If there is no AOP proxy, the second-level cache can solve the problem, but in the case of AOP proxy, using only the second-level cache means that all Bean have to complete the AOP proxy after instantiation, which violates the principle of Spring design. At the beginning of the design, Spring uses AnnotationAwareAspectJAutoProxyCreator as a post-processor to complete the AOP proxy in the last step of the Bean life cycle, rather than AOP proxy immediately after instantiation.

That's all for the content of "how to solve the problem of Spring circular dependency". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.