Excerpt from Spring decryption
Scope is used to declare that the objects in the IOC container should be in a qualified scenario or that the object's survival space, that is, before the IOC container enters the appropriate scope, the objects are generated and assembled, and the container usually destroys the objects after they are no longer qualified for those scopes. Let's make an analogy! We are all in the Community (container), if the middle school teachers as a class definition, then when the container initializes these classes, the middle school teachers can only be confined to the middle school this scenario, secondary school, it could be regarded as the scope of secondary school teachers.
The spring container initially provides the scope type of the two beans: Singleton and prototype, but after release 2.0, another three scope types, the Request,session and global session types, are introduced. However, these three types are limited and can only be used in Web applications, meaning that it is only reasonable to use these three scopes in ApplicationContext that support Web applications.
You can use the bean's singleton or scope property to specify a scope for the corresponding object, where the scope property can be used only in the XSD-formatted document life, similar to the one shown in the following code:
Dtd:
<bean id = "MockObject1" class= "..." singleton= "false"/>
Xsd:
<bean id = "MockObject1" class= "..." scope= "prototype"/>
Note: The singleton here is different from the singleton pattern in design mode, and the bean labeled Singleton is a container that guarantees that this type of bean has only one shared instance within the same container. The singleton mode ensures that only one instance of this type exists in the same classloader.
1,Singleton
Singleton type of bean definition, there is only one instance in a container, and all dependencies on that type of bean refer to this single instance, as if every kindergarten would have a slide, the kindergarten children use this slide together, and for kindergarten containers, The slide is a singleton bean.
In addition, the bean definition of the singleton type, the easy start, to the first time he was requested to instantiate the start, as long as the container does not destroy or exit, the type of a single instance of the bean will survive.
In general, if you do not specify the Bean's Scope,singleton is the container default scope, so, the following three configurations, the form actually achieved the same effect:
DTD or XSD:
<bean id = "MockObject1" class= "..."/>
Dtd:
<bean id = "MockObject1" class= "..." singleton= "true"/>
Xsd:
<bean id = "MockObject1" class= "..." scope= "singleton"/>
2,prototype
Scope is a prototype bean, when a container receives a request to an object of that type, it regenerates a new object to the requester each time, although the instantiation of this type of object and the property setting are all handled by the container, but as soon as it is ready, And after the object instance is returned to the requester, the container does not have a reference to the current object, and the requester needs to be responsible for the management of the current object's subsequent life cycle, including the object's destruction. That is, each time the container returns a new instance of the object from the requester, the object "dies".
Let's continue the metaphor of kindergarten, we are going to divide apples today! The Apple Bean's scope attribute is declared as prototype, in each child to receive the apple, we are sending a new Apple to him, after the end, the children love how to eat, when to eat, when to eat, but pay attention to eat the core of the fruit to throw to the garbage box Oh! For those object types that cannot be shared, the scope to which they are defined should be set to prototype, and generally, beans declared as prototype are stateful, such as objects that are saved as each customer information.
You can define prototype types of beans in a way:
Dtd:
<bean id = "MockObject1" class= "..." singleton= "false"/>
Xsd:
<bean id = "MockObject1" class= "..." scope= "prototype"/>
3.request, session and global session
These three types are new after spring2.0, they are not as generic as singleton and prototype, because they are only applicable to Web applications, usually with xmlwebapplicationcontext common use, will be discussed in detail in chapter 6th, here is a brief introduction.
Request
<bean id = "Requestprecessor" class= "... Requestprecessor "scope=" Request "/>
The spring container, Xmlwebapplicationcontext, creates a completely new Requestprecessor object for each HTTP request, and when the request finishes, the object's life cycle ends. When there are 10 HTTP requests coming in, the container will create 10 new Requestprecessor instances for each of the 10 requests, and they do not interfere with each other, and in a not very strict sense, the request can be seen as a special case of prototype, In addition to the more specific scenes, the semantics are similar.
Session
For Web applications, the most common place in the session is the user's login information, for this information in the session, we can use the following form of the scope for the session:
<bean id = "Userpreferences" class= "... Userpreferences "scope=" Session "/>
The spring container creates its own new instance of userpreferences for each individual session, and he will survive longer than the bean of the request scope, and the other aspects really make no difference.
Global session:
<bean id = "Userpreferences" class= "... Userpreferences "scope=" Globalsession "/>
The global session is only meaningful for applications in Porlet-based Web applications, and he maps to the Porlet global scope session, if this scope is used in a common servlet Web application, The container treats it as the scope of the normal session.
Scope of the bean in spring is detailed