Today I studied the scope of scope. The default is singleton mode, i.e. scope="singleton". In addition, scope also has prototype, request, session, and global session scope. scope="prototype" multiple examples. When configuring the scope of a bean, its header file form is as follows:
How to use spring's scope:
<bean id="role" scope="singleton"/>
The scope here is used to configure the scope of springbean, which identifies the scope of bean.
Before spring 2.0, beans had only two scopes: singleton (singleton), non-singleton (also known as prototype). After Spring 2.0, three beans specifically designed for web application contexts have been added. Therefore, Spring 2.0 now has five types of beans by default. Of course, Spring 2.0 has 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 needs to meet actual application needs.
1. Singleton scope
When a bean's scope is set to singleton, there will only be one shared bean instance in the SpringIOC container, and all requests to beans, as long as the id matches the bean definition, only the same instance of the bean will be returned. In other words, when setting a bean definition to singleton scope, the SpringIOC container only creates a unique instance of that bean definition. This single instance will be stored in the singleton cache, and all subsequent requests and references to the bean will return the cached object instance. It should be noted here that the singleton scope and the singleton in the GOF design pattern are completely different. The singleton design pattern means that only one class exists in a ClassLoader, and 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 bean will exist in the spring IOC container.
Configuration instance:
<bean id="role" scope="singleton"/> or <bean id="role" singleton="true"/>
2. Prototype
Every request (injecting it into another bean, or calling the container's getBean() method in the form of a program) will produce a new bean instance, which is equivalent to a new operation. For beans with prototype scope, one is very important, that is, Spring cannot be responsible for the entire life cycle of a prototypebean. After the container initializes, configures, decorates or assembles a prototype instance, it handes it to the client, and then ignores the prototype instance. Regardless of the scope, the container will call the initialized lifecycle callback method of all objects, and for prototype, any configured destructed lifecycle callback method will not be called. It is the responsibility of the client code to clear the prototype scoped object and free any expensive resources held by the prototypebean. (One feasible way to have the Spring container free resources occupied by a singleton-scoped bean is by using the bean's postprocessor, which holds a reference to the bean to be cleared.)
Configuration instance:
<bean id="role" scope="prototype"/> or <beanid="role" singleton="false"/>
3. Request
The request indicates that a new bean will be generated for each HTTP request. At the same time, the bean is only valid in the current HTTPrequest. The configuration instance is:
When using request, session, and globalsession, you must first make the following configuration in the initialized web.xml:
If you are using a web container with Servlet 2.4 or above, 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 Servlet 2.4, then you need to use a javax.servlet.Filter implementation:
<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" scope="request"/>
4. Session
The session scope indicates that a new bean will be generated for each HTTP request. At the same time, the bean is only valid within the current HTTPsession. The configuration instance is:
Configuration instance:
Just like the prerequisite for configuring the request instance, after configuring the web startup file, you can configure it as follows:
<bean id="role" scope="session"/>
5. Globalsession
The globalsession scope is similar to the standard HTTPSession 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 different portlets that make up a portlet web application. Beans defined in the globalsession scope are limited to the life cycle of the global portletSession. If you use globalsession scope to identify beans in the web, the web will automatically be used as a session type.
Configuration instance:
Just like the prerequisite for configuring the request instance, after configuring the web startup file, you can configure it as follows:
<bean id="role" scope="global session"/>
Summarize
The above is all about this article's brief discussion on the scope scope in spring, and I hope it will be helpful to everyone. Interested friends can continue to refer to other related topics on this site. If there are any shortcomings, please leave a message to point it out. Thank you friends for your support for this site!