Detailed explanation of the correctness of spring loop dependency and the sequential relationship of bean injection

1、 Preface @ h_ 404_ 6@

We know that spring can be lazy loaded, that is, it instantiates beans when they are really used. Of course, this is not all true. For example, configuring the lazy init attribute of a bean can control the loading timing of spring. At present, the performance and memory of the machine are relatively high, and lazy loading is basically not used. Beans are loaded when the container is started, and the startup time is a little longer. In this way, a lot of burden can be reduced when actually obtaining beans for business use. This will be analyzed later. When we use beans, the most direct way is to get them from factroy, which is the source of loading bean instances@ H_ 404_ 6@

Recently, when I was working on a project, I encountered a wonderful problem, that is, the correctness of bean dependency injection has something to do with the sequence of bean direct injection, but under normal circumstances, it has nothing to do with the sequence. What's the situation? Don't worry, let me come together@ H_ 404_ 6@

2、 Ordinary bean cyclic dependency - independent of injection order @ h_ 404_ 6@

2.1 example and principle of cyclic dependency @ h_ 404_ 6@

The above circular dependency injection works normally because spring provides the earlybeanreference function. First, spring has a concurrent map named singletonobjects to store all instantiated and initialized beans, Singletonfactories are used to store bean information (beanname, and a callback factory) that needs to solve circular dependencies. When beana is instantiated, getBean ("beana") will be triggered; First, check whether there is beana in singletonobjects. If yes, it returns: @ h_ 404_ 6@

（1） @H_404_6@

Beana is definitely not instantiated at the beginning, so if allowcircularreferences = true (the default is true) and the current bean is a singleton and the bean is currently being created, put the bean information into the singletonfactories singleton map before initializing the attribute: @ h_404_6@

（2） @H_404_6@

Then inject beanb into the instance. During attribute injection, getBean ("beanb") will be generated. If beanb is not found in singletonobjects, beanb will be instantiated and put into singletonfactories. Then inject beana into the instance and trigger getBean ("beana"); At this time, the instantiated beana will be returned to (1) getsingleton. After the initialization of beanb, add beanb to singletonobjects, and then return. After the initialization of beana, add beana to singletonobjects, and then return @ h_404_6@

2.2 switch allowing cyclic dependence @ h_ 404_ 6@

There is an attribute allowcircularreferences in the classpathxmlapplicationcontext class to control whether circular dependencies are allowed. The default is true. If it is set to false, it is found that circular dependencies can still operate normally. Check the source code: @ h_ 404_ 6@

Know that the container will be refreshed when the classpathxmlapplicationcontext is constructed by default@ H_ 404_ 6@

The refresh method calls refreshbeanfactory: @ h_ 404_ 6@

That's it. We're calling modulecontext Before setallowcircularreferences (false), the callback customizebeanfactory reserved by spring for setting the bean factory has been executed. The final reason is that the bean factory has been refreshed before calling the setting, so the test code is changed to: @ H_ 404_ 6@

Now the test will throw an exception: @ h_ 404_ 6@

Caused by: org. springframework. beans. factory. BeanCreationException: Error creating bean with name 'beanA' defined in class path resource [beans-circile.xml]: Cannot resolve reference to bean 'beanB' while setting bean property 'beanB'; nested exception is org. springframework. beans. factory. BeanCreationException: Error creating bean with name 'beanB' defined in class path resource [beans-circile.xml]: Cannot resolve reference to bean 'beanA' while setting bean property 'beanA'; nested exception is org. springframework. beans. factory. BeanCurrentlyInCreationException: Error creating bean with name 'beanA': Requested bean is currently in creation: Is there an unresolvable circular reference? @ H_ 404_ 6@

3、 Circular dependency between factory bean and ordinary bean - related to injection order @ h_ 404_ 6@

3.1 test code @ h_ 404_ 6@

Factory bean @ h_ 404_ 6@

For simplicity, just write a public variable @ H_ 404_ 6@

XML configuration @ h_ 404_ 6@

The factory bean myfactorybean is used to wrap the test class. First, set the property of myfactorybean, then create a test instance in the afterpropertiesset method of myfactorybean, set the property, instantiate myfactorybean, and finally call the GetObject method to return the created test object. Here, myfactorybean depends on the dependbean, and the dependbean itself depends on test, so this is a circular dependency @ H_ 404_ 6@

Test: @ h_ 404_ 6@

Result: @ h_ 404_ 6@

Caused by: org. springframework. beans. factory. BeanCreationException: Error creating bean with name 'com. alibaba. test. circle. DependentBean#1c701a27': Autowiring of fields Failed; nested exception is org. springframework. beans. factory. BeanCreationException: Could not autowire field: private com. alibaba. test. circle. Test com. alibaba. test. circle. DependentBean. test; nested exception is org. springframework. beans. factory. BeanCurrentlyInCreationException: Error creating bean with name 'test': factorybean which is currently in creation returned null from getObject @H_ 404_ 6@

3.2 cause analysis @ h_ 404_ 6@

When instantiating test, getBean ("test") will be triggered to see whether the current bean exists @ H_ 404_ 6@

If it does not exist, an instance of test will be created. After creation, the current bean information will be put into the singletonfactories single map @ H_ 404_ 6@

Then inject the attribute into the instance, which will getBean ("dependbean"), @ H_ 404_ 6@

If it is found that the dependbean does not exist, it will be instantiated and put into singletonfactories, @ H_ 404_ 6@

Then inject Autowired test, and then trigger getBean ("test"); At this time, (1) getsingleton returns the instantiated test. Since test is a factory bean, test. GetObject (); @ h_404_6@

The afterpropertieset of myfactorybean has not been called yet, so test Getobject() returns null. @ h_404_6@

The following is the process created by spring bean: @ h_ 404_ 6@

Getbean() - > create instance - > Autowired - > set attribute - > afterPropertiesSet@H_404_6 @

That is, the GetObject method is called earlier than the afterpropertieset method@ H_ 404_ 6@

Then we modify myfactorybean as follows: @ h_ 404_ 6@

In other words, if test = = null is not as good as the internal judgment of GetObject, call afterpropertieset, and then if test = = null is creating a test instance within afterpropertieset, it looks good. I really want to solve our problem. But in fact, it still can't, because the postpropertieset uses the dependbean internally, and at this time, the dependbean = null@ H_ 404_ 6@

3.3 thinking about how to solve @ h_ 404_ 6@

3.2 the reason for the analysis is that Myfactorybean was created first, and the DepentBean was created in the process of creating Myfactorybean, and the instance of Autowired Myfactorybean was needed when DepentBean was created, then the getObject method was invoked before calling afterPropertiesSet, so null was returned. H_ 404_ 6@

What if you first create a depentbean and then create a myfactorybean? The following analysis process: @ h_ 404_ 6@

First, the depentbean will be instantiated and added to singletonfactories @ H_ 404_ 6@

The dependbean instance will Autowired test, so the test instance @ h will be created first_ 404_ 6@

Create a test instance, and then add singletonfactories @ H_ 404_ 6@

The test instance will inject the property into the dependbean instance, so it will getBean ("dependbean")@ H_ 404_ 6@

If getBean ("dependbean") finds that there is already a dependbean in singletonfactories, it returns the dependbean object @ H_ 404_ 6@

Because the dependbean is not a factory bean, the dependbean @ h is returned directly_ 404_ 6@

The test instance property will be injected into the depentbean instance successfully, and the test instance initialization is OK @ H_ 404_ 6@

The dependbean instance will Autowired test instance OK @ h_ 404_ 6@

According to this analysis, it is feasible to create a depentbean first and then instantiate myfactorybean. Modify the XML as follows: @ h_ 404_ 6@

Test run result: @ h_ 404_ 6@

name:zlx @H_ 404_ 6@

hello: zlx@H_404_6 @

If you can, according to this analysis, if the declaration order of the above XML configuration is adjusted, there will certainly be errors, because the test is created earlier than the dependentbean. This is true under the test. In addition, it is conceivable that when factory beans rely on factory beans circularly, they will inevitably fail regardless of the declaration order@ H_ 404_ 6@

3.3 a thought @ h_ 404_ 6@

First inject the dependentbean that needs to be used in myfactorybean, and then inject myfactorybean. The problem is solved. Then, if you need to use the created object with id = "test" in another bean, how should this bean inject that? Will it succeed in a way similar to the following? Let's think ^ ^ @ h_ 404_ 6@

4、 Summary @ h_ 404_ 6@

When ordinary beans are interdependent, the bean injection order does not matter, but when factory beans are interdependent with ordinary beans, ordinary beans must be instantiated first. This is because of the particularity of factory beans, that is, they have a GetObject method@ H_ 404_ 6@

Well, the above is the whole content of this article. I hope the content of this article has a certain reference value for your study or work. If you have any questions, you can leave a message. Thank you for your support for programming tips@ H_ 404_ 6@