The nature of circular dependency problems
Definition of circular dependencies and common scenarios
In the Spring framework, dependency injection is one of its core features, which allows dependencies between objects to be dynamically injected at runtime. However, when the dependencies between multiple beans form a closed loop, the circular dependency problem occurs. Simply put, circular dependency means that Bean A depends on Bean B, and Bean B depends on Bean A, or there are more complex multi-bean circular dependency chains.
Common circular dependency scenarios include constructor injection circular dependencies and attribute injection circular dependencies. The following are the code examples to show these two scenarios.
Constructor injection cycle dependencies
@Component
public class ConstructorBeanA {
private ConstructorBeanB beanB;
@Autowired
public ConstructorBeanA(ConstructorBeanB beanB) {
= beanB;
}
}
@Component
public class ConstructorBeanB {
private ConstructorBeanA beanA;
@Autowired
public ConstructorBeanB(ConstructorBeanA beanA) {
= beanA;
}
}In the above code, ConstructorBeanA depends on ConstructorBeanB through the constructor, and ConstructorBeanB also depends on ConstructorBeanA through the constructor. When the Spring container tries to create these two beans, it will fall into an infinite loop because creating ConstructorBeanA requires creating ConstructorBeanB first, and creating ConstructorBeanB first requires creating ConstructorBeanA first.
Property injection circular dependencies
@Component
public class PropertyBeanA {
@Autowired
private PropertyBeanB beanB;
}
@Component
public class PropertyBeanB {
@Autowired
private PropertyBeanA beanA;
}In the scenario of property injection circular dependency, PropertyBeanA depends on PropertyBeanB through property injection, and PropertyBeanB also depends on PropertyBeanA through property injection. Although the circular dependency of attribute injection can be solved through Spring's level 3 cache mechanism, the circular dependency of constructor injection cannot be solved through this mechanism, because constructor injection requires that dependency injection be completed when the bean is instantiated, and the bean has not yet entered the stage of exposure.
Problems caused by circular dependencies
Loop dependencies cause Spring containers to fall into an infinite loop when creating beans, eventually throwing a BeanCurrentlyInCreationException exception. This is because without a suitable solution, Spring will constantly try to create interdependent beans and cannot complete the initialization process of the bean. For example, when creating ConstructorBeanA, it needs to call its constructor and pass in an instance of ConstructorBeanB, and at this time, ConstructorBeanB has not been created, so Spring starts creating ConstructorBeanB. However, when creating ConstructorBeanB, an instance of ConstructorBeanA is needed, which will fall into a dead loop and cause the program to fail to run normally.
The composition and function of Level 3 cache
Level 1 Cache - Fully Initialize Bean's Repository
Definition and data structure of first-level cache
Level 1 cache, also known as singleton pool, is usually implemented in Spring using ConcurrentHashMap<String, Object>. Where, the key is the name of the bean and the value is the fully initialized Bean instance. ConcurrentHashMap is thread-safe, which ensures that access and operation of level one cache is safe in a multi-threaded environment.
// Example definition of Level 1 cacheprivate final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
The role of first-level caching
Level 1 cache is where the ultimate storage of available beans in Spring. When a bean goes through all initialization steps, including instantiation, property injection, initialization method calls, etc., and eventually becomes a complete bean that can be used directly, it will be put into the first-level cache. If other beans need to rely on this bean, they can be directly obtained from the first-level cache, avoiding the overhead of repeatedly creating beans. For example, when a service layer bean needs to rely on a data access layer bean, Spring will first look for the data access layer bean from the first level cache, and use it directly if it exists.
The timing of using level 1 cache
In the final stage of bean creation, when the bean completes all initialization operations and passes through various post-processor processing, Spring will put the bean into the first-level cache. At the same time, the information about the bean will be removed from the second-level cache and the third-level cache to ensure that the bean only exists in the first-level cache.
Level 2 Cache - Early exposure of Bean temporary storage
Definition and data structure of secondary cache
Level 2 cache is also a Map structure, usually implemented using ConcurrentHashMap<String, Object>. It is used to store early exposed bean objects that have been instantiated but have not performed subsequent operations such as property filling.
// Example definition of Level 2 cacheprivate final Map<String, Object> earlySingletonObjects = new ConcurrentHashMap<>(16);
The role of secondary caching
The main function of L2 cache is to provide a place to temporarily store early exposure of beans when solving circular dependencies. When a bean has just been instantiated but has not completed all initialization steps, in order to prevent problems in circular dependency scenarios, Spring will first put this early exposed bean into the secondary cache. In this way, when other beans need to rely on it, they can first get the bean reference that has not been fully initialized from the secondary cache, avoiding unnecessary recursive creation. For example, in the loop dependency scenarios of PropertyBeanA and PropertyBeanB mentioned earlier, when PropertyBeanA is created and exposed to the secondary cache early, a reference to PropertyBeanA can be obtained from the secondary cache when creating PropertyBeanB, thus breaking the loop.
The timing of using Level 2 cache
After the bean instantiation is completed, Spring will place the earlier references of the bean into the secondary cache. During subsequent attribute injection and initialization, if you find that other beans depend on the bean, you will first try to get a reference to the bean from the secondary cache. When the bean finally completes all initialization operations and puts it into the first-level cache, the reference to the bean is removed from the second-level cache.
Level 3 Cache - Delayed factory for creating beans
Definition and data structure of Level 3 cache
Level 3 cache is a Map<String, ObjectFactory<?>> structure, where the key is the name of the Bean and the value is an ObjectFactory object. ObjectFactory is a functional interface that has only one getObject() method used to create Bean objects.
// Example definition of Level 3 cacheprivate final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);
The role of Level 3 cache
The main function of Level 3 caching is to provide a mechanism for delaying loading and creating beans. During bean creation, especially when dealing with circular dependencies, it is able to obtain early exposed bean objects through ObjectFactory. In this way, Spring can create beans at the right time, avoiding the circular dependency problems that can be caused by direct creation. For example, in some cases, some additional processing or enhancement of the bean may be required, which can be done only when needed through the ObjectFactory, rather than when the bean is instantiated.
Time to use Level 3 cache
After the bean instantiation is completed, Spring creates an ObjectFactory object and places it in the Level 3 cache. This ObjectFactory object is called when you need to get an earlier exposed bean. When the ObjectFactory is obtained from the Level 3 cache and its getObject() method is called, the obtained bean will be placed in the Level 2 cache and the ObjectFactory will be removed from the Level 3 cache.
Detailed process of solving circular dependencies using level 3 cache
Create Bean A
Instantiate Bean A
When the Spring container starts creating a BeanA, it will first call the constructor of BeanA to instantiate it. At this stage, BeanA is just an object that has just been created. All its properties are still default values and no such operations have been performed. For example, if BeanA has a name attribute, the value of name is null at this time.
// Example of BeanA's constructorpublic class BeanA {
private BeanB beanB;
public BeanA() {
// Constructor logic }
}Putting early references to Bean A into Level 3 cache
After BeanA instantiation is completed, Spring creates an ObjectFactory object that encapsulates the logic for obtaining early references to BeanA. Then put this ObjectFactory object into the Level 3 cache.
// Example logic for putting early references of BeanA into Level 3 cache("beanA", () -> getEarlyBeanReference(beanName, mbd, bean));Depend on Bean B during attribute injection
Start attribute injection
After the BeanA instantiation is completed and its earlier references are placed into the Level 3 cache, Spring begins to inject BeanA's attributes. During this process, all dependencies of BeanA are checked.
Discovering dependence on Bean B
When checking that BeanA depends on BeanB, the Spring container will try to get BeanB. Since the container has not yet fully initialized BeanB, Spring will enter the process of creating BeanB.
Create Bean B and discover dependencies on Bean A
Instantiate Bean B
The Spring container starts creating BeanB, and will also call the BeanB constructor to instantiate it. At this time, BeanB is just an object that has just been created, and its properties have not been injected yet.
// Example of BeanB's constructorpublic class BeanB {
private BeanA beanA;
public BeanB() {
// Constructor logic }
}Putting early references to Bean B into Level 3 cache
Similar to BeanA, after BeanB instantiation is completed, Spring creates an ObjectFactory object and puts it into the Level 3 cache.
Discovering dependency on Bean A
When performing attribute injection of BeanB, it was found that BeanB depends on BeanA. At this point, Spring will try to get BeanA from the cache.
Get Bean A from Level 3 cache
Check the cache
Spring first checks whether BeanA exists in the first level cache. Since BeanA has not been fully initialized, it does not exist in the first level cache. Then the secondary cache will be checked, and there is no in the secondary cache either. Finally, the Level 3 cache will be checked and found that the Level 3 cache has the ObjectFactory corresponding to BeanA.
Get Bean A with Early Exposure
Spring will call the getObject() method of the ObjectFactory corresponding to BeanA to obtain a reference to the BeanA that was exposed in the early stage. Then remove the reference to this BeanA from the Level 3 cache and put it into the Level 2 cache.
Complete the creation of Bean B
Injecting a reference to Bean A
Inject references to BeanAs retrieved from the secondary cache into BeanB. At this time, although BeanB is getting a BeanA reference that has not been fully initialized, this is enough to break the circular dependency.
Complete the initialization of Bean B
BeanB continues to complete the injection and initialization of other properties. During this process, since there is already a reference to BeanA, the recreation of BeanA will no longer be triggered, thus avoiding circular dependencies. Finally, BeanB completes all initialization operations and is placed in the first-level cache.
Complete the creation of Bean A
Get a quote from Bean B
BeanA gets a fully created BeanB, which is obtained from the first-level cache.
Complete the initialization of Bean A
BeanA continues to complete its remaining attribute injection and other initialization operations. Finally, BeanA also completes all initialization steps and is placed in the first-level cache. At this time, both BeanA and BeanB have been successfully created, and the circular dependency problem between them has been properly resolved.
Through such a fine level three caching mechanism, Spring successfully broke the deadlock of circular dependency, ensuring that the dependency injection and initialization between beans can be correctly carried out, providing developers with a stable and reliable dependency management environment. At the same time, we should also note that this mechanism cannot solve the circular dependence of constructor injection. During the development process, we should try to avoid the occurrence of circular dependence of constructor injection.
The above is a detailed explanation of the method of Spring using Level 3 cache to process circular dependencies. For more information about Spring's Level 3 cache to process circular dependencies, please pay attention to my other related articles!