Singleton scope
Only one shared instance of a singleton bean is managed, and all requests to beans with an identifier or identifiers matching that bean's definition result in the Spring container returning that particular bean instance.
In other words, when you assign a bean definition and it comes into singleton scope, the Spring IoC container creates exactly one instance of the object assigned by that bean definition. This single instance is stored in the cache of such singleton beans, and all subsequent requests and references to this named bean return the cached object. The following image shows how singleton scope works:
alt="">
The concept of a singleton bean in Spring is different from the concept of a singleton template as defined in the (Gang of Four/GoF) pattern book. In the case of a GoF singleton object, the object's scope is hard-coded such that for each ClassLoader, one and only one instance of the concrete class is created. Singleton scope in Spring is best described as per-container and per-bean. This means that if you define one bean for a particular class in one Spring container, the Spring container creates one and only one instance of the class defined by that bean definition. Singleton scope is Spring's default scope. To define a bean as a singleton object in XML, you can define the bean in the manner shown in the following example:
<bean id="accountService" class="com.something.DefaultAccountService"/>
<!-- the following is equivalent, although redundant (singleton scope is used by default) -->
<bean id="accountService" class="com.something.DefaultAccountService" scope="singleton"/>Prototype scope
The non-singleton prototype scope for bean deployment creates a new instance of the bean every time a request is made
for that particular bean. That is, a bean is injected into another bean or requested through a call to the getBean()
method in the container. In general, you should use prototype scope for all stateful beans and singleton scope for
non-stateful beans.
The following diagram illustrates the prototype scope in Spring:
alt="">
(The Data Access Object (DAO) is not typically configured as a prototype because a typical DAO does not retain any dialog state. It was easier to reuse the core schema for a singleton object).
The following example defines the bean as a prototype in XML:
<bean id="accountService" class="com.something.DefaultAccountService" scope="prototype"/>Unlike other scopes, Spring does not manage the full lifecycle of the prototype bean. The container instantiates, configures, and otherwise assembles a prototype object and passes it to the client, without further writing about that prototype instance. Thus, although the initialization lifecycle callback methods are called on all objects regardless of scope, in the case of prototypes, the configured destruction lifecycle callbacks are not called. Client code must clean up objects that are in prototype scope and free up valuable resources that prototype beans consume. To force the Spring container to free up the resources consumed by beans within the scope of the prototype, try using a special bean post-processor that contains a reference to the beans that need to be cleaned up.
In a sense, the Spring container's role with respect to prototype-scoped beans is a replacement for the Java new
operator. All lifecycle management after this point must be done on the client side. (For more information about the
bean lifecycle in a Spring container, see Lifecycle Callbacks.)
Single beans with prototype-bean dependencies
If you use singleton-scoped beans with dependencies on prototype beans, remember that dependencies are resolved when the instance is created. Thus, if you inject a dependency on a prototype bean into a bean that is in the scope of a singleton, an instance of the new prototype bean is created and then injected into the singleton bean. A prototype instance is a single instance that is provided to a bean within the scope of a singleton.
However, suppose you want a singleton-scoped bean to repeatedly receive new instances of a prototype-scoped bean at runtime. You won't be able to inject a dependency on a prototype-scoped bean into your singleton bean because injection occurs only once, when the Spring container instantiates the singleton bean, resolves, and injects its dependencies.
GO TO FULL VERSION