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

This article mainly explains "what is the backbone process of spring's IOC". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Next, let the editor take you to learn "what is the backbone process of spring's IOC"?

Preface

Recently, I have written several articles in the spring series, which have been well received by many readers, and some readers want me to write more articles on this subject. There are even private messages from readers asking me how to read the spring source code, so I plan to write a series of spring source code interpretation to give back to my fans who have always supported me.

I don't know if you have any of these experiences:

There is no way to start if you want to see the source code of spring.

There are so many spring source codes that you lose them when you look at them.

I don't know which is primary and which is secondary.

I remember the other day, but I forgot today.

Spring source code is very complex, to be honest, this kind of article is difficult to write, it is difficult to explain it clearly, it will be very long, readers may not have the patience to read it, and it is easy to forget after reading.

I intend to use the combination of picture and text to remove the dross and interpret only some of the essence, so as to give readers a clear idea when reading the source code so as not to get lost. And the most important thing is that you can remember a lot of key processes after reading it.

In the huge system of spring, IOC (inversion of Control) runs through all the time, and its function is self-evident. Let's start with IOC, introduce its backbone process, and give some guidance to friends in need.

Entrance

The top interface of the spring container is: BeanFactory, but we use more of its subinterface: ApplicationContext.

In general, if we want to manually initialize the spring container configured through the xml file, the code looks like this:

ClassPathXmlApplicationContext applicationContext = new ClassPathXmlApplicationContext ("applicationContext.xml"); User user = (User) applicationContext.getBean ("name")

If you want to manually initialize the spring container configured through the configuration class, the code looks like this:

AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext (Config.class); User user = (User) applicationContext.getBean ("name")

These two classes are supposed to be the most common entrances, but they both go the same way and end up calling the refresh method, which is the real entry for spring container initialization.

By the way, these are not the only classes that call the refresh method. Let's take a look at it as a whole with a diagram:

Although there are so many classes that call the refresh method, I decided to use the ClassPathXmlApplicationContext class as the column because it is classic enough and relatively less difficult.

Again, because of the huge amount of spring source code, even if I can finish it all at once, I'm afraid you won't have the patience to watch it. So I will use Hello, I also good way, ignore some details, only focus on the main points. If there are students who are interested in some details, please add me Wechat to communicate with me, or follow my follow-up articles, will explain in detail.

Refresh method r

The efresh method is the real entry to spring ioc, which is responsible for initializing the spring container.

Since the purpose of this method is to initialize the spring container, why isn't the method called init?

The answer is simple because it is called more than once.

The run method in the SpringAppication class of springboot calls the refreshContext method, which calls the refresh method once.

The onApplicationEvent method in the BootstrapApplicationListener class of springcloud calls the run method in the SpringAppication class. The refresh method is also called once.

This is why the refresh method is called twice if springcloud is introduced in the springboot project.

The initWebApplicationContext method in the FrameworkServlet class of springmvc calls the configureAndRefreshWebApplicationContext method, which calls the refresh method once, but determines in advance whether the container is active.

So the refresh here means to rebuild.

All right, let's cut the crap. Let's focus on the key steps of refresh:

In fact, at first glance, there seem to be many methods in the above picture, but there are not many core methods. I will mainly talk about the most important of them:

ObtainFreshBeanFactory

InvokeBeanFactoryPostProcessors

RegisterBeanPostProcessors

FinishBeanFactoryInitialization

Parsing the xml configuration file obtainFreshBeanFactory method parses xml's bean configuration, generates a BeanDefinition object, and registers with the spring container (to put it bluntly, many map collections).

After several layers of calls (not to mention the details, very simple), it is called to the loadBeanDefinitions method of the AbstractBeanDefinitionReader class:

This method loops through locations (applicationContext.xml file path), calling another loadBeanDefinitions method, parsing one file at a time.

After some series of coquettish operations, location is converted to inputSource and resource, and then to Document objects, which are parsed by aspects.

When parsing a xml file, you need to determine whether it is a default tag or a custom tag. The processing logic is different:

There are only four default tags for spring:

The corresponding processing methods are:

Note that common:, and so on are custom tags.

Starting with the processBeanDefinition method that handles the tag in the figure above, after a series of calls, it will eventually be called to the processBeanDefinition method of the DefaultBeanDefinitionDocumentReader class.

This method includes key steps: parsing the element to generate the BeanDefinition and registering the BeanDefinition.

The content of custom properties is interesting, but I won't talk about it here. I don't use it much now. Interested students add me Wechat to chat with me in private.

Generate BeanDefinition

Let's focus on how BeanDefinition is generated.

The above method calls the parseBeanDefinitionElement method of the BeanDefinitionParserDelegate class:

A label corresponds to a BeanDefinition object.

This method also calls the overloaded method of the same name: processBeanDefinition, which actually creates the BeanDefinition object and parses a series of parameters to populate the object:

In fact, the logic for creating a BeanDefinition is very simple, directly new an object:

The real complexity lies in the parsing and assignment of the various attributes above.

Register for BeanDefinition

The above generates a lot of BeanDefinition objects by parsing the xml file, so you need to register the BeanDefinition object with the spring container so that the spring container can initialize the bean.

The registerBeanDefinition method in the BeanDefinitionReaderUtils class is simple, with only two processes:

First take a look at how the registerBeanDefinition method of the DefaultListableBeanFactory class registers beanName:

Next, look at how the registerAlias method of the SimpleAliasRegistry class registers the alias alias:

In this way, the same alias can be found through multiple different name, and then the BeanDefinition can be found through name.

Modify BeanDefinition

The above BeanDefinition object is already registered in the spring container, so what if you want to modify the registered BeanDefinition object?

The BeanDefinition object is modified by the invokeBeanFactoryPostProcessors method in the refresh method.

After a series of calls, you end up with the invokeBeanFactoryPostProcessors method of the PostProcessorRegistrationDelegate class:

The process looks long, but the logic is relatively simple, mainly dealing with BeanDefinitionRegistryPostProcessor and BeanFactoryPostProcessor.

BeanDefinitionRegistryPostProcessor itself is a special BeanFactoryPostProcessor, which also executes the logic of BeanFactoryPostProcessor, but with an additional method.

ConfigurationClassPostProcessor is probably the most important BeanDefinitionRegistryPostProcessor, which handles @ Configuration annotations.

Register for BeanPostProcessor

After dealing with the previous logic, the refresh method then calls registerBeanPostProcessors to register BeanPostProcessor, which is very powerful, which will be explained in more detail in a later article.

After a series of calls, you end up with the registerBeanPostProcessors method of the PostProcessorRegistrationDelegate class:

Note that this step is just to register the BeanPostProcessor and actually use it later.

At this point, I believe you have a deeper understanding of "what is the backbone process of spring's IOC". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.