The principle and implementation of Spring IOC

General Understanding:

Inversion of control: The idea is that objects are controlled by the user, but with Spring, the whole object can be managed by Spring

DI: Dependency injection, which injects the value of the corresponding attribute into a specific object. @AutoWired and populateBean perform the injection of the attribute value

Container: Store objects, using the Map structure for storage. There is usually a three-level cache in Spring. SingletonObjects holds the complete bean object.

The entire bean lifecycle, from creation to use to destruction, is managed by the container (bean life cycle)

There are several steps:

1, involves the creation process of the container (the beanFactory, DefaultListableBeanFactory), to set some parameters in bean plant (BeanPostProcessor, Aware interfaces subclass) properties and so on

Load the parse bean object and prepare the beanDefinition of the bean object to be created (parsing of XML or annotations).

3, spring beanFactoryPostProcessor processing, here is the extension point, PlaceHolderConfigurSupport, ConfigurationClassPostProcessor

4. Registration function of BeanPostProcessor to facilitate subsequent extension of bean objects

5. Instantiate BeanDefinition objects into concrete bean objects by reflection.

6. Initialization process of bean object (fill properties, call methods of Aware subclass, call BeanPostProcessor preprocessing method, call init-Mehtod method, call BeanPostProcessor postprocessing method)

7. Generate the complete bean object, which can be obtained directly through the getBean method

8. Destruction process

Beans in Spring are generated by reflection and contain many extension points, such as the most commonly used extension to BeanFactory, extension to beans (handling placeholders), and the core of IOC is to fill in the properties and life cycle of a specific bean

The underlying implementation of Spring IOC

Underlying implementation: working principle, process, data structure, process, design pattern, design idea

Understanding and implementing process: Reflection, factory, design pattern, key methods (createBeanFactory, getBean,doGetBean,createBean,doCreateBean,createBeanInstance(getDeclaredConstructor,newinstance),populateBean,initializi NgBean)

1, first by createBeanFactory create a Bean plant (DefaultListableBeanFactory)

2, start loop to create object, because the container bean default is singleton, so the priority is getBean,doGetBean from the container, if not found,

Create objects by reflection using the createBean (doCreateBean) method, usually using getDeclaredConstructor (newInstance).

4. PopulateBean is populated with the attributes of the object

5. Perform additional initialization operations (initializingBean)

The life cycle of the bean

Remember the flow in the diagram

Don’t just say the key points in the diagram, expand the description

Instantiate beans: Generate objects reflectively

PopulateBean (), loop-dependent problem (level 3 caching)

3, call aware interface related methods: invokeAwareMethod (complete BeanName, the BeanFactory, BeanClassLoader object attribute set)

4. Call BeanPostProcessor’s preprocessing method: Use more (ApplicationContextPostProcessor, set the ApplicationContext, Environment, ResourceLoader, EmbeddValueResolver etc.)

5. Call the initMethod method: invokeInitmethod() to determine whether the initializingBean interface is implemented. If so, call afterPropertiesSet

Call BeanPostProcessor’s postprocessing method: Spring’s AOP is implemented here, Abstractauto XyCreator

Register the destuction-related callback interface: hook function

7, to obtain the complete object, you can use getBean to obtain the object

8. Destruction Process, 1; To determine if the DispoableBean interface is implemented, call destroyMethod

Spring loop dependencies

Level 3 caching, pre-exposure objects, AOP

Total: what is the cyclic dependency problem, A depends on B,B depends on A

Bean creation process: instantiate, initialize (populate properties)

1. Create object A first, instantiate object A, at this time object A property B is empty, fill property B

2, find B object from the container, if found, direct assignment does not have the problem of loop dependency (not found), create B object directly

3, instantiate B object, then a property in B object is empty, fill a property

4. Create object A from the container

The cause of the closed loop

At this point, if will ponder, will find A object exists, but at this time of A object is not A complete state, only completed the instantiation but unfinished initialization, if in the process of program calls, have an object reference, can be completed in late to his assignment operation, can give priority to the nonholonomic state object assignment priority, Waiting for subsequent operations to complete the assignment exposes a reference to an incomplete object in advance, so the core of the solution is to separate instantiation and initialization. This is also the key to solving the problem of loop dependency.

When all the objects are complete instantiation and after initialization, but also put full objects in the container, the container at this time objects exist in the several states, complete instantiation = but not initialized, complete state, because in the container, so will use different map structure for storage, where there will be a level 1 cache and the second level cache, If there are objects with the same name in level 1 cache, then there are no objects with the same name in level 2 cache, because they are looked up in the order of 1, 2, and 3. Level 1 cache holds complete objects and level 2 cache holds non-complete objects

Why level 3 caching? The value type of the tertiary cache is ObjectFactory, which is a functional interface that ensures that only one bean object with the same name can be used throughout the container.

If an object needs to be proxied, or if a proxy object needs to be generated, should a normal object be generated first? to

Common object and the agent is not appear in the container at the same time, so when an object needs to be the agent, then use a proxy object before overwriting the ordinary objects, in the process of the actual call, there is no way to determine when the object is used, so requires that when an object is called priority to determine whether this object needs to be agent, GetEarlyBeanReference () is similar to the implementation of a callback mechanism, so that when passed a lambda expression, the object can be overridden by the lambda expression, getEarlyBeanReference()

Therefore, all bean objects are first placed in the level 3 cache when they are created, and then returned to proxy objects if they need to be proxied, or normal objects if they don’t

Cache placement time and delete time

After createBeanInstance, addSingletonFactory

Level 2 cache: Remove level 3 cache getSingleton the first time an object is determined from level 3 cache whether it is a proxy object or a normal object

Level 1 cache: after the whole object is generated, put it into the level 1 cache. Delete the level 2 cache and level 3 cache :addSingleton

The Bean Factory and FactoryBean

Similarity: Both are used to create bean objects

Differences: When creating objects using the BeanFactory, you have to follow a strict lifecycle process, which is too complex. If you want to simply customize the creation of an object and hand it over to Spring to manage, you need to implement the FactroyBean interface

IsSingleton: Whether the object is a singleton

GetObjectType: Gets the type of the returned object

GetObject: Custom process for creating objects (new, reflection, dynamic proxy)

Design patterns used in Spring

Singleton pattern: Beans are singleton by default

Prototype mode: Specify scope to prototype

Factory mode: BeanFactory

Template method: postProcessBeanFactory, onRefresh initPropertyValue

The strategy pattern: XmlBeanDefinitionReader PropertiesBeanDefinitionReader

Observer modes: Listener, Event, and multicast

Adapter mode: Adapter

Decorator mode: BeanWrapper

Chain of Responsibility pattern: Using AOP creates a chain of interceptors

Proxy mode: Dynamic proxy

Delegate pattern: Delegate

Spring AOP’s underlying implementation principles

A dynamic proxy

Aop is an extension of IOC. There was IOC first, and then AOP, just one new extension point added to the whole ioc process: BeanPostProcessor

General: AOP concepts, application scenarios, dynamic proxies

Points:

There is a step in the bean creation process to extend the bean implementation. Aop itself is an extension capability, so it is implemented in the post-processing method of BeanPostProcessor

1, Proxy object creation process (advice, aspect, pointcut)

Generate proxy objects using JDK or Cglib

3, in the implementation of the method call, will call to the generated bytecode file, directly back to find DynamicAdvisoredInterceptor intercept method in the class, method starts from now on

4. Generate the chain of interceptors based on previously defined notifications

5. Get each notification in turn from the interceptor chain. During the invocation, there is a CglibMethodInvocation object that starts at -1 and executes it once to find the next notification.

Spring transaction rollback

How is Transaction management implemented in Spring?

R: Spring transactions are implemented by AOP. First, specific proxy objects are generated, and then specific operation logic is executed according to the whole process of AOP. Under normal circumstances, core functions are completed through notification, but transactions are not implemented through notification. Instead, it is implemented through a TransactionInterceptor, and then invokes to implement the specific logic

Points: 1. Do preparatory work first, analyze transaction related attributes on each method, and judge whether to start a new transaction according to specific attributes

2, when need to enable, get database connection, turn off automatic commit function, start transaction

3. Perform specific SQL logic operations

4, in the process of operation, if failed, then will pass the completeTransactionAfterThrowing seems to complete the transaction rollback operation, the rollback of specific logic is by doRollBack method, implementation is also to get connection object, through the connection object is rolled back and forth

5, if the implementation process, there is no any accident from happening, so to complete the transaction by commitTransactionAfterReturning commit operation, specific logic is submitted by doCommit method, implementation is also to get connected, through the connection object to submit

6. When the transaction is completed, the relevant transaction information needs to be cleared cleanupTransactionInfo

If you want to talk more detailed, need to know TransactionInfo TransactionStatus,

Spring transaction propagation

How many propagation properties are there? Seven kinds of

​ Required,Requires_new,nested,Support,Not_Support,Never,Mandatory

What if one transaction nested another?

Method A calls method B, and methods AB have transactions and different propagation characteristics. Then, if A has an exception, what should B do? If B has an exception, what should A do?

R: Propagation of transactions refers to how a transaction should be handled during nested calls of different methods, whether the same transaction or different transaction, whether an exception is rolled back or committed, and the related impact between the two methods. In daily work, most of the methods used are required, Requires_new,nested

First, the different classification of transactions can be divided into three categories: support current transaction, do not support current transaction, nested transaction

2. If the outer method is required and the inner method is required,requires_new,nested

3. If the outer method is requires_new and the inner method is required,requires_new,nested

4. If the outer method is nested, the inner method is required,requires_new,nested