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

This article mainly introduces Spring to solve the example analysis of circular dependence, the article is very detailed, has a certain reference value, interested friends must read it!

Here we first borrow a picture to feel it visually. Look at the picture:

In fact, I think you should be able to talk about the picture through the above picture. The so-called circular dependence is actually a kind of endless loop. Imagine an example from life where you, as a hunk, like a girl, who falls in love with your gay friend, the sissy, but who wants to pick up the soap you throw when you go to the shower.

Yes, this is the root cause of circular dependence. When spring starts in the process of parsing configuration to create beans. First I initialize A and find that I need to reference B, then I initialize B and find that I reference C, and then I initialize C and find a fucking result, C references A. It initializes A once again and loops endlessly, just like your damn sick triangle.

Since this seemingly insoluble triangular relationship has been formed, what can be done to solve it? I believe that smart you have begun to think about solutions in the face of such embarrassing situations. It doesn't matter if you want to come out or not. Let's see how the great gods of spring solve this problem.

Spring's solution to circular dependencies is the three-level cache and pre-exposure described in the title.

Spring's third-level cache is mainly singletonObjects, earlySingletonObjects, and singletonFactors.

Code 1-1:

/** Cache of singleton objects: bean name --> bean instance */ private final Map singletonObjects = new ConcurrentHashMap(256); /** Cache of singleton factories: bean name --> ObjectFactory */ private final Map singletonFactory = this.singletonFactories.get(beanName); //get from L3 cache if (singletonFactory != null) { singletonObject = singletonFactory.getObject(); //get bean this.earlySingletonObjects.put(beanName, singletonObject); //Promotes the fetched bean to the L2 cache this.singletonFactories.remove(beanName); //remove from L3 cache } } } } return singletonObject; }

The above method is the process of obtaining a single bean by Spring. For the explanation of some of the methods, I directly borrow the abstracts of other bloggers:

isSingletonCurrentlyInCreation(): Determines whether the current singleton bean is under creation. The bean is being created, that is, the bean is initialized but not initialized. There is a process that complements Spring's idea of solving bean circular dependencies, because the core of Spring's solution to singleton beans lies in early exposure of beans.

allowEarlyReference: Literally means to allow a quote to be obtained in advance. What it really means is whether it is allowed to get objects from the singletonFactors cache via getObject(). Why is there such a field? The reason for this is that singletonFactories is Spring's secret to solving singleton beans.

All right, so here we're going to clarify what Spring goes through when we execute the following code to get a bean named user.

Codes 1-3:

ClassPathResource resource = new ClassPathResource("bean.xml"); DefaultListableBeanFactory factory = new DefaultListableBeanFactory(); XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(factory); reader.loadBeanDefinitions(resource); UserBean user = (UserBean) factory.getBean("user");

By tracing the source code, we found that getBean() method calls AbstractBeanFactory.doGetBean() method, in which the key getSingleton() we mentioned above is called. Since the cache is empty when the first bean is fetched at the start of the project, null is returned directly. Trace the source code found, in doGetBean() after the call to AbstractAutowireCapableBeanFactory.doCreateBean() method to create beans, detailed process on its own trace the source code. There is a code in this method:

Code 1-4:

// 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)); //Determine whether the bean allows early exposure by condition if (earlySingletonExposure) { if (logger.isTraceEnabled()) { logger.trace("Eagerly caching bean '" + beanName + "' to allow for resolving potential circular references"); } addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean)); //Allow early-exposed beans to be added to the L3 cache}

From the above code we found that beans that can be exposed in advance are added to the third-level cache SingletonFactories through the addSingletonFactory() method. Let's see how it works.

Codes 1-5:

protected void addSingletonFactory(String beanName, ObjectFactory singletonFactory) { Assert.notNull(singletonFactory, "Singleton factory must not be null"); synchronized (this.singletonObjects) { if (! this.singletonObjects.containsKey(beanName)) { this.singletonFactories.put(beanName, singletonFactory); //Add to L3 cache this.earlySingletonObjects.remove(beanName); this.registeredSingletons.add(beanName); } } }

At this point, our user bean is added to the third-level cache, so what kind of bean will be added to the third-level cache? There are three criteria in codes 1-4:

Singleton

Beans that allow circular references

The current bean is being created

At this point, the bean user has been created, but it is not yet a complete bean and needs subsequent initialization. But this doesn't affect other beans referencing it. Assuming user is A in the start diagram, then when initializing A (user), it finds that A has a property B, and when calling the method applyPropertyValues() to set this B. Spring will find that B has not yet been created, and then it will repeat the process of creating A by calling doCreate() to create B, and then add it to the L3 cache. When setting the attribute C of B, it will find that C has not yet been created, and then repeat the previous doCreate() step to create C. C is created and initialized to find that C references A. The key place is code 1-2 above.

When C sets attribute A, getSingleton() is called to get bean, because A has been added to the third-level cache at codes 1-4, C can directly get the instance of A and set it successfully, and then continue to complete its own creation. After initialization is complete, call the following method to add yourself to the L1 cache.

Codes 1-6:

protected void addSingleton(String beanName, Object singletonObject) { synchronized (this.singletonObjects) { this.singletonObjects.put(beanName, singletonObject); this.singletonFactories.remove(beanName); this.earlySingletonObjects.remove(beanName); this.registeredSingletons.add(beanName); }} The above is all the content of this article,"Sample Analysis of Spring Solving Circular Dependency", thank you for reading! Hope to share the content to help everyone, more relevant knowledge, welcome to pay attention to the industry information channel!

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.