Before spring 2.0, there were only two types of bean scopes: singleton (singleton) and non-singleton (also called prototype). Bean. Therefore, Spring 2.0 now has five types of beans by default. Of course, Spring 2.0 refactored the design of bean types, and designed flexible bean type support. In theory, there can be countless types of beans. Users can add new bean types according to their own needs to meet the needs of practical application requirements.
1. singleton scope (scope default value)
When a bean's scope is set to singleton, there will only be one shared bean instance in the Spring IOC container, and all requests to the bean will only return the same instance of the bean as long as the id matches the bean definition. In other words, when a bean definition is set to singleton scope, the Spring IOC container will only create a single instance of that bean definition. This singleton will be stored in the singleton cache, and all subsequent requests and references to the bean will return the cached object instance. Note here that the singleton scope and the singleton in the GOF design pattern The example is completely different. The singleton design pattern means that only one class exists in a ClassLoader, while the singleton here means that a container corresponds to a bean, that is to say, when a bean is identified as a singleton, only one class in the spring IOC container will be used. One such bean exists.
配置实例：
<bean id="role" class="spring.chapter2.maryGame.Role" scope="singleton"/> 或者 <bean id="role" class="spring.chapter2.maryGame.Role" singleton="true"/>
2. prototype
For beans deployed in the prototype scope, each request (injecting it into another bean, or calling the container's getBean() method programmatically) will generate a new bean instance, which is equivalent to a new operation. For prototype Scoped beans, it is very important that Spring cannot be responsible for the entire life cycle of a prototype bean. After the container initializes, configures, decorates or assembles a prototype instance, it hands it over to the client, and then it The prototype instance goes unnoticed. Regardless of the scope, the container will call the initialization lifecycle callback methods of all objects, and for prototypes, any configured destructor lifecycle callback methods will not be called. It is the client code's responsibility to clean up prototype-scoped objects and release any expensive resources held by prototype beans. (One possible way to have the Spring container release resources held by a singleton-scoped bean is by using a bean's post-processor that holds a reference to the bean to be cleaned up.)
配置实例：
<bean id="role" class="spring.chapter2.maryGame.Role" scope="prototype"/> 或者 <beanid="role" class="spring.chapter2.maryGame.Role" singleton="false"/>
3. request
request means that a new bean will be generated for each HTTP request, and the bean is only valid within the current HTTP request. Configuration examples: When request, session, and global session are used, first do the following in the web.xml that initializes the web Configuration: If you are using a web container of Servlet 2.4 and above, then you only need to add the following ContextListener to the XML declaration file web.xml of the web application:
<web-app>
...
<listener> <listener-class>org.springframework.web.context.request.RequestContextListener</listener-class> </listener> ... </web-app>
If it is a web container before Servlet2.4, then you need to use an implementation of javax.servlet.Filter:
<web-app>
..
<filter> <filter-name>requestContextFilter</filter-name> <filter-class>org.springframework.web.filter.RequestContextFilter</filter-class> </filter> <filter-mapping> <filter-name>requestContextFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> ... </web-app>
Then you can configure the scope of the bean:
<bean id="role" class="spring.chapter2.maryGame.Role" scope="request"/>
4. session
The session scope indicates that a new bean will be generated for each HTTP request, and the bean is only valid in the current HTTP session. Configuration instance: Configuration instance: The same as the premise of the request configuration instance, the web startup file can be configured as follows Configuration:
<bean id="role" class="spring.chapter2.maryGame.Role" scope="session"/>
5. global session
The global session scope is similar to the standard HTTP Session scope, but it only makes sense in portlet-based web applications. The Portlet specification defines the concept of a global Session, which is shared by all the various portlets that make up a portlet web application. Beans defined in the global session scope are limited to the lifetime scope of the global portlet Session. If you use the global session scope to identify the bean in the web, then the web will automatically use it as the session type. Configuration instance: Same as the premise of the request configuration instance, after configuring the web startup file, you can configure it as follows:
<bean id="role" class="spring.chapter2.maryGame.Role" scope="global session"/>
6. Custom bean assembly scope
In spring 2.0, the scope can be extended arbitrarily, you can customize the scope, and even you can redefine the existing scope (but you cannot override singleton and prototype), the scope of spring is defined by the interface org.springframework .beans.factory.config.Scope to define, customize your own scope as long as you implement this interface