Detailed explanation of spring IOC container knowledge points

Spring IOC container can be compared to a restaurant. When you come to a restaurant, you usually directly greet the waiter: order! What are the ingredients of the dish? How to make vegetables with raw materials? Maybe you don't care at all. The IOC container is the same. You only need to tell it that it needs a bean, and it will throw the corresponding instance to you. As for whether the bean depends on other components and how to complete its initialization, you don't need to care at all.

As a restaurant, if you want to make dishes, you need to know the raw materials and recipes. Similarly, IOC container needs to record and manage this information in some way to manage various business objects and their dependencies. The beandefinition object assumes this responsibility: each bean in the container will have a corresponding beandefinition instance, which is responsible for saving all necessary information of the bean object, including the class type of the bean object, whether it is an abstract class, construction methods and parameters, other properties, etc. When the client requests the corresponding object from the container, the container will return a complete and available bean instance for the client through this information. Wechat search web_ Get more dry goods after resource pays attention!

Raw materials are ready (look at beandefinition as raw materials), start cooking, etc. you also need a recipe. Beandefinitionregistry and beanfactory are the recipes. Beandefinitionregistry abstracts the bean registration logic, while beanfactory abstracts the bean management logic, and the implementation classes of each beanfactory are specifically responsible for bean registration and management 。 The relationship between them is as follows:

Defaultlistablebeanfactory, as a general beanfactory implementation, also implements the beandefinitionregistry interface, so it undertakes the registration management of beans. It can also be seen from the figure that the beanfactory interface mainly includes methods for managing beans such as getBean, containbean, GetType and getaliases, while the beandefinitionregistry interface includes methods for registering and managing beandefinition such as registerbeandeffinition, removebeandefinition and getbeandefinition.

Here is a simple code to simulate how the bottom layer of beanfactory works:

// 默认容器实现
DefaultListablebeanfactory beanRegistry = new DefaultListablebeanfactory();
// 根据业务对象构造相应的BeanDeFinition
AbstractBeanDeFinition deFinition = new RootBeanDeFinition(Business.class,true);
// 将bean定义注册到容器中
beanRegistry.registerBeanDeFinition("beanName",deFinition);
// 如果有多个bean，还可以指定各个bean之间的依赖关系
// ........

// 然后可以从容器中获取这个bean的实例
// 注意：这里的beanRegistry其实实现了beanfactory接口，所以可以强转，
// 单纯的BeanDeFinitionRegistry是无法强制转换到beanfactory类型的
beanfactory container = (beanfactory)beanRegistry;
Business business = (Business)container.getBean("beanName");

This code is only to illustrate the general workflow at the bottom of beanfactory. The actual situation will be more complex. For example, the dependencies between beans may be defined in external configuration files (XML / properties) or annotated. The whole workflow of spring IOC container can be roughly divided into two stages

The above is all the knowledge points introduced this time. Thank you for your learning and support.