Spring Scope Scope

The scope of spring will have an impact on the bean's life cycle and how it is created.

Mainly divided into five types of scopes

Singleton  
         (default) There is only one bean instance in the spring IOC container, and the bean exists as a single instance.  prototype
         Each time a bean is called from the container, a new instance is returned, which is equivalent to the operation of the new Xxxbean () whenever Getbean () is called.  Request    
         Each HTTP request creates a new bean that applies only to the WEBAPPLICATIONCONTEXT environment.  Session     
         The same HTTP session shares a bean, and different HTTP sessions use different beans, and the scope applies only to the WEBAPPLICATIONCONTEXT environment.  globalsession
　　　　  

In the low version of spring, because there are only two bean scopes, the singleton= "true|false" configuration, spring2.0 for backwards compatibility, still supports this configuration. However, the SPRING2.0 recommends a new configuration approach:   scope= "< scope type >"

Singleton scope

Spring provides natural, single-instance mode functionality in a container, and any pojo does not need to write special code that can be configured only

Note:spring will set the bean's default scope to Singleton.

Singleton Example:

<BeanID= "Car"class= "Com.baobaotao.scope.Car"Scope= "Singleton"/><BeanID= "Boss1"class= "Com.baobaotao.scope.Boss"> 　　 < Propertyname= "Car"ref= "Car"/></Bean>

Where the car bean is declared as singleton (because the default is singleton, so you can not specify it explicitly).

By default, spring's ApplicationContext container automatically instantiates all singleton beans and caches them in the container at startup.

Although it takes some time to start, it brings two benefits :

The first instantiation of the bean in advance will reveal some potential configuration issues early on. Next, the bean is saved in a cached way, and it is no longer instantiated when the bean is used at runtime, which speeds up the efficiency of the operation.

If the user does not want the singleton bean to be instantiated in advance when the container starts, it can be controlled by the lazy-init property:

<id= "BOOS1"  class= "Com.baobaotao.scope.Boss"  lazy-init  = "true"><name= "Car"  ref= "Car"/></bean>　　

Lazy-init= "true" beans are still instantiated in advance in some cases: if the bean is referenced by another bean that needs to be instantiated in advance, Spring ignores the deferred instantiation setting.

Prototype scope

Specifying non-singleton scope beans with scope= "prototype"

Cases:

<BeanID= "Car"class= "Com.baobaotao.scope.Car"Scope= "Prototype"/><BeanID= "Boss1"class= "Com.baobaotao.scope.Boss"> 　　 < Propertyname= "Car"ref= "Car"/></Bean><BeanID= "Boss2"class= "Com.baobaotao.scope.Boss"> 　　 < Propertyname= "Car"ref= "Car"/></Bean>

Boss1,boss2 refers to a separate car instance.

By default, the spring container does not instantiate the prototype bean at startup. In addition, theSpring container will not manage its life cycle once the prototype bean is handed over to the caller.

Web application environment-related bean scopes (request,session and globalsession.)

Scopes that users can use only if they use Webapplicationcontext

Before using these scopes, however, you must first make some additional configuration in the Web container, which you can configure with the HTTP request listener in a high-version Web container:

 <  web-app  >   ...  <  listener 　　　　>  <  listener-class  >   Org.springframework.web.context.request.RequestContextListener  </ listener-class  >  </ listener  >   ...  </ web-app  >  

A careful friend may have a question: when we introduce webapplicationcontext initialization, we have contextloaderlistener the Web container with

Spring container Consolidation, why do we introduce an additional requestcontextlistener to support the other 3 scopes of beans?

Using Contextloaderlistener when integrating the spring container, it implements the Servletcontextlistener listener interface, Servletcontextlistener is only responsible for monitoring the Web container startup and shutdown events. And Requestcontextlistener implements the Servletrequestlistener listener interface, which listens for HTTP request events, The listener is notified of every request received by the Web server.

The spring container start and close operations are triggered by the Web container's startup and shutdown events, but if the beans in the spring container require request,session,globalsession scope support, The spring container itself must obtain the HTTP request event for the Web container, which "drives" the control logic of the bean scope in the event of the HTTP request.

Request Scope

The request scope bean corresponds to an HTTP request and lifecycle, taking into account the following configuration:

<name= "Car"  class= "Com.baobaotao.scope.Car"  scope = "Request" />

This way, each time the HTTP request is called to the car bean, the spring container creates a new car bean, which is destroyed when the request is processed.

Session scope

Assume that the scope of the above car is adjusted to the session type:

<name= "Car"  class= "Com.baobaotao.scope.Car"  scope = "Session" />

With this configuration, the car bean's scope spans the entire HTTP session,session and all HTTP requests share the same car bean, and the instance is destroyed when the HTTP session ends.

Globalsession Scope

The following configuration fragment sets the scope of the car to Globalsession:

<name= "Logincontroller"  class= "Com.baobaotao.scope.Car " Scope = "Globalsession" />

Globalsession scopes are similar to session scopes, but are only used in portlet Web apps. The Portlet specification defines the global session concept, which is composed of portlets

All child portlets of the Web app are shared. If not in the Portlet Web application environment, Globalsession is naturally equivalent to having a field in the session.

Spring Scope Scope