The definition and control of spring core--bean

In the previous two articles describing sring core and design patterns, the dependencies of IOC containers and beans were described. If you read the first 2, you'll know that spring's entire workings revolve around the IOC container and the bean. The IOC is a basket, and all the beans are thrown inside. In addition to providing a basket function to create and store beans, the IOC is also responsible for managing the relationship between beans and beans-dependency injection. As mentioned earlier, beans are the smallest unit of work for the spring core container, and some of the more advanced features of spring, such as facets, proxies, are implemented on a bean basis.

In addition to managing the relationship between beans and beans, the IOC provides functionality to control the bean itself, and this article describes the bean's lifecycle capabilities and state definition capabilities.

Predecessor dependencies
There is a dependency between the bean and the bean, which can be a strong dependency (directly declaring the dependency through XML and annotations), or it can be a weak dependency (applicationcontextaware, etc.). When a bean needs another bean to finish initializing itself to work, such as a bean-dependent datasoruce, the initialization of DataSource takes a long time. This time use depends-on to declare the pre-dependency:

Lazy Loading
Typically, all singleton types of beans are initialized after the container is created, simply by starting the JVM (after actually creating an instance of an implementation class for ApplicationContext).

The IOC supports all singleton beans when they are used, and the benefit of this is that the initialization time can be greatly reduced. However, if your application is not sensitive to the length of the boot time, it is recommended that all singleton be loaded at startup. This can cause problems to be discovered at startup, rather than being triggered by the user until it is run for a long time. Or, depending on the scenario, the decision is deferred, such as using lazy loading at development time, and shutting down during integration testing or on production.

You can set a global lazy load, or you can set a bean lazy load:

It is important to note that when setting up a separate bean lazy load, if there is a bean that does not delay loading to rely on him, it will actually be loaded at the time of initialization.

It is also emphasized that the "load" here is simply to indicate that a class is created and placed in a container by the IOC, and that the Classload method loads the bytecode in the class file into the method area.

Lazy loading is an extension of the singleton pattern in design mode, often referred to as lazy mode. A singleton usually has a double lock +volatile, a static class, and an enumeration of three ways to implement it. In the effective Java book, there is a deep analysis of three modes. In the case of spring containers, enumeration is certainly not a good way to use, static classes due to their own code level should also not be used, so the implementation of the double lock is more credible. But I did not go to see the source code, is only a guess.

Life cycle Approach
The creation, use, and eventual destruction of a bean is called the Bean's life cycle. The spring Framework provides a variety of fallback methods to handle various states or data for each stage of the bean's life cycle.

Initialize method

When a bean is initialized and injected with various parameters, the initialization method is called, which simply means that it is called after the creation is complete. The implementation of the initialization callback method has 2 paths: 1. Inherit the Org.springframework.beans.factory.InitializingBean interface, and then implement the Afterpropertiesset method. 2. Use the Init-method property on the bean's XML configuration to make the initialization to invoke:

Inheritance implementations:

Configuration implementation:

2 methods are equivalent, and the actual usage is which method should we use?

Initializingbean is a life cycle callback method implemented early in spring. But after JCP introduced the JSR-250 and JSR-330 specifications, Spring's great gods began to realize that the non-intrusive framework (not coupled) is the right path based on meta-programming ideas and configuration techniques. So now it is recommended to use the configuration file and JSR-250 @postconstruct (for the use of various annotation please follow the article). Still retaining the Initializingbean should be considered compatibility issues.

Method of Destruction
Corresponding to the method of creation, is the destruction methods. The corresponding destroy callback method is called before a class is to be destroyed. The Destroy method also has an inheritance implementation and configuration + annotation implementation:

Inheritance implementations:

Configuration implementation:

It is still recommended that the destruction means also use configuration or @predestroy to set the destruction method.

Global configuration initialization and destruction methods
The IOC container also provides configuration for the global configuration initialization and destruction method:

By using the Default-init-method and Default-destroy-method attribute parameters on the <beans> tab, you can uniformly specify the lifecycle method of initialization and destruction for all beans in the container.

If you set 2 default life cycle methods on <beans> and also specify Init-method or Destroy-method on <bean>, the callback method will be based on the <bean> configuration. This ensures that the global configuration can coexist with a separate configuration.

Points to note using initialize or Destroy 2 life cycle methods:

Both initialization and destruction provide 3 tools: XML configuration, annotations, and implementation interfaces. Each part of the system is developed by different teams and does not follow a uniform specification, and it is recommended to use annotations that meet the JSR specification-@PostConstruct, @PreDestroy. If it is a unified team, quasi-training consistent specification, it is recommended to use the global configuration of <beans> 's attribute uniform name.
If the bean is designed into proxy mode (for example, AOP is used), then the life cycle method is called, and it is possible that the proxy class has not been created. Because the life cycle method is called after the entity class has completed the corresponding work, it is not related to the proxy class.

The definition and control of spring core--bean