Singleton and Prototype Bean scope in Spring framework

The Spring Framework is the de facto framework for dependency injection, with a proven track record in developing scalable, resilient and secure cloud-native environments.

When using Spring Beans, beginners often feel a little confused about Spring beans and their scope.

The following is my attempt to illustrate a simple example of Singleton and Prototype Bean scoping.

Singleton Bean scope : As its name suggests, beans with Singleton scope have only one instance available in the Spring application context. However, it is worth noting that the same bean can have multiple instances under different bean names in Spring constants. Example.

This idea is somewhat different from the concept of Singleton design pattern, which states that once a Java class is designed as a singleton, the JVM will have only a single instance available in memory.

Illustration 1.0  The illustration below shows an account service Spring bean. The bean can have different names. The same service can exist under two different names in the Spring context.

5ce67ff733879582bd9ded16fafb0803.jpeg
 

When we refer to a singleton class in a Java application, only one instance of the class is available. However, in Spring, Singleton does not mean that there is only one instance of the type in the context, it can have multiple instances of the type with different names. Example.

Prototype Bean Scoping : When an application programmer defines the scope of a bean as prototype, it means that every time someone requests a reference to a bean, the Spring framework returns a completely new bean instance. Spring framework manages object types.

Illustration 1.1:  The illustration below defines a prototype-scoped bean and explains that every time we request Spring, Spring will provide a new instance of the requested bean.

8a1c8ffc075972c1e6a0454c00ebbffa.jpeg
 

Why should a bean have prototype scope?

Prototype scope is to avoid race conditions when two threads access Singleton Bean. Due to the interleaved nature of multi-threaded environments, this is a classic concurrency problem where the results of operations are unpredictable. Therefore, in order to ensure that each thread gets its own copy of the bean, the developer wants to ensure that each thread gets its own copy.

What is a race condition?

Take a stock app, for example. The stock price is updated every second, and the code used to update the stock price for a specific stock ID is written in a concurrency context, which means there may be multiple callers trying to update the price of stock X. Consider a sequence of steps:

1.Mike attempts to update the price of stock X to $110. 2.Mike reads the price of stock X and increases it to $120. 3. Meanwhile, before Mike writes this to main memory, he goes to the bathroom. 4. Bob comes back with coffee and sees the old stock value on the screen as 105. He updates the value of stock X to $125. 5.Mike comes back and updates the value of stock X again to $120. 6. Because of this construction, the update that Mike wants to make to stock X is not visible to Bob, and he overwrites it again. 7. This is a typical race condition, I hope everyone understands, like Mike and Bob can be replaced by thread A and thread B here, in a concurrent environment.

If StockPrice is defined as a prototype-scoped bean, then each thread gets its own copy of StockPrice and they do not interfere with each other. However, getting different copies of the Stock price does not eliminate the need to synchronize the Stock price updates for a given stock, it needs to be done in a series of atomic steps, but to avoid complexity we can skip this discussion in order to understand the Prototype Bean scope.

Illustration 1.2:  The following illustration defines a prototype-scoped bean and explains that each thread obtains a new instance of the prototype bean.

9c2695937836cd20381cd5a7f9cd7e48.jpeg

Summarize:

1. By default, the scope of Spring beans is Singleton. 2.Singleton scoped beans can have multiple instances under different names in the Spring application context. 3. Prototype bean is a convention provided by the Spring framework. A new instance of the bean will be provided by the framework every time it is requested. 4. Prototype scoped beans can be used for Singleton scoped beans, but we should pay attention to how we get the bean from the context, because if the Prototype bean is defined inside a Singleton bean, there will only be one prototype bean instance provided by Spring. , which defeats its own purpose. 5. To avoid race conditions, you can use Prototype Bean scope.


Guess you like

Origin blog.csdn.net/weixin_37604985/article/details/132440007