Bean scopes

sigleton：

Spring singleton is best described as per container and per bean.

The singleton scope is the default scope in Spring.

prototype：

creation of a new bean instance every time a request for that specific bean is made。

use the prototype scope for all beans that are stateful, while the singleton scope should be used for stateless beans.

prototype-scoped bean as somewhat of a replacement for the Java 'new' operator.

Spring does not manage the complete lifecycle of a prototype bean。It is the responsibility of the client code to clean up prototype scoped objects and release any expensive resources that the prototype bean(s) are holding onto.

request（web专用）、session（web专用）、globle session（web专用）

servlet 2.4+ web.xml

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

servlet 2.3 web.xml

<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>

the global session scope is similar to the standard HTTP Session scope (described immediately above), and really only makes sense in the context of portlet-based web applications.

if you are writing a standard Servlet-based web application and you define one or more beans
as having global session scope, the standard HTTP Session scope will be used, and no error will be raised.

<bean id="userPreferences" class="com.foo.UserPreferences" scope="session">
<!-- this next element effects the proxying of the surrounding bean -->
<aop:scoped-proxy/>
</bean>

<!-- a singleton-scoped bean injected with a proxy to the above bean -->
<bean id="userService" class="com.foo.SimpleUserService">
<!-- a reference to the proxied 'userPreferences' bean -->
<property name="userPreferences" ref="userPreferences"/>
</bean>
</beans>

<bean id="userPreferences" class="com.foo.UserPreferences" scope="session"/>
<bean id="userManager" class="com.foo.UserManager">
<property name="userPreferences" ref="userPreferences"/>
</bean>
From the above configuration it is evident that the singleton bean 'userManager' is being injected with a
reference to the HTTP Session-scoped bean 'userPreferences'. The salient point here is that the
'userManager' bean is a singleton... it will be instantiated exactly once per container, and its dependencies (in
this case only one, the 'userPreferences' bean) will also only be injected (once!). This means that the
'userManager' will (conceptually) only ever operate on the exact same 'userPreferences' object, that is the
one that it was originally injected with. This is not what you want when you inject a HTTP Session-scoped
bean as a dependency into a collaborating object (typically). Rather, what we do want is a single
'userManager' object, and then, for the lifetime of a HTTP Session, we want to see and use a
'userPreferences' object that is specific to said HTTP Session.