In spring, When to use Prototype Scope and Singleton Scope, and when to use just new operator?

1) And why default is Singleton Scope?
For some domain object like Class SalesOrder.
If the SalesOrder object is singleton, then mean all request will use the same SalesOrder object? then all user will overwirte the same SalesOrder object?
Or for domain object, we should use @Prototype Scope? Or better just use new operator?

2) Any guideline for when to use Spring Singleton scope, prototype scope and when to use just java new operator?

3) for spring documentation, it mentions

As a rule, you should use the prototype scope for all stateful beans and the singleton scope for stateless beans.

any example of what is stateful beans and what is stateless beans?
Usually service layer, data access layer, controller layer is stateless beans? (As there is @Service, @Repository and @Controller stereotype annotation, and spring default is singleton scope, so I guess this three layer is stateless beans).

Sorry than my concept for when to use which bean scope is poor.

You may want to read this https://nullbeans.com/prototype-vs-singleton-spring-beans-differences-and-uses/ .
It says that singleton is good for resource intensive components such as database service component. You don't want to create a new database component
when you need to connect to the database.

Himai Minh wrote:You may want to read this https://nullbeans.com/prototype-vs-singleton-spring-beans-differences-and-uses/ .
It says that singleton is good for resource intensive components such as database service component. You don't want to create a new database component
when you need to connect to the database.

the post still just said
Singleton:Used in stateless situations.
Prototype:Used for stateful situations.

NO explanation and no example of what is stateless/stateful situation, WHY stateless choose singeleton, stateful choose prototype

And has no information for my question for entity object (value object) like Users Class, SalesOrder class....these are stateless or stateful? Or use new operator is better....

In fact, I search many article and most just said WHAT is singleton or prototype scope and just one statement said stateless choose singleton and stateful choose prototype, but no more detail explanation of WHY has this rule.

Singleton bean is  stateless because it is shared . So, it should not contain any state for any other component.

Prototype bean is stateful because it is not shared among other components. Each component can have its own prototype copy of the bean.
So, one copy of the prototype bean can be used by one component and save some states for that component.

Stateless means that an object doesn't evolve over time. Its fields are assigned a value when the object is constructed, and they don't change afterwards. The best example of stateless objects are immutable objects, because they CAN'T change after they've been created.

Stateful objects are those that have an internal state that changes over time.

Now, I really don't like how all online guides just say: singletons are stateless and prototypes are stateful. It completely misses the point, and it doesn't offer an insight into why most applications are set up that way.

Roughly speaking, your web application consists of two types of objects. The first type are services with a lifetime that is longer than a single request, i.e. they can be used by more than one request, often even by multiple requests simultaneously. These services usually have the singleton scope: you create them once, and they are reused for the duration of the application.

The second type are objects that are needed only temporarily. They are created at some point during the lifetime of a single request, used, and then discarded again. They are not shared between different requests, and often they are not even used outside of the method where they are first needed. These objects have the prototype scope: a new instance of them is created every time they are injected.

It doesn't really matter whether prototypes are stateful or not. Just design them any way you require.

Singletons on the other hand MUST be stateless. Because they are shared between different requests, they can be accesses by multiple threads at the same time. This means they need to be thread-safe. To make an object thread-safe, you have two options:

The first option is to use concurrency utilities to carefully synchronize access to the object. The problem with this approach is that it causes requests to block until other requests are finished with the shared service. For high traffic websites, this approach is a no-go.

The second option is to make the class stateless. An object that doesn't change its internal state can be used by multiple requests simultaneously, without blocking.

Stephan van Hulst wrote:Stateless means that an object doesn't evolve over time. Its fields are assigned a value when the object is constructed, and they don't change afterwards. The best example of stateless objects are immutable objects, because they CAN'T change after they've been created.

Stateful objects are those that have an internal state that changes over time.

Now, I really don't like how all online guides just say: singletons are stateless and prototypes are stateful. It completely misses the point, and it doesn't offer an insight into why most applications are set up that way.

Roughly speaking, your web application consists of two types of objects. The first type are services with a lifetime that is longer than a single request, i.e. they can be used by more than one request, often even by multiple requests simultaneously. These services usually have the singleton scope: you create them once, and they are reused for the duration of the application.

The second type are objects that are needed only temporarily. They are created at some point during the lifetime of a single request, used, and then discarded again. They are not shared between different requests, and often they are not even used outside of the method where they are first needed. These objects have the prototype scope: a new instance of them is created every time they are injected.

It doesn't really matter whether prototypes are stateful or not. Just design them any way you require.

Singletons on the other hand MUST be stateless. Because they are shared between different requests, they can be accesses by multiple threads at the same time. This means they need to be thread-safe. To make an object thread-safe, you have two options:

The first option is to use concurrency utilities to carefully synchronize access to the object. The problem with this approach is that it causes requests to block until other requests are finished with the shared service. For high traffic websites, this approach is a no-go.

The second option is to make the class stateless. An object that doesn't change its internal state can be used by multiple requests simultaneously, without blocking.

Sorry but still has some unknown, if create a stateless object that doesn't change its internal state, then is this like create a class with all static member and static method? Why need create such Singleton, stateless object (bean) in spring?

I think let other components to share the same singleton Spring bean is for efficiency.
Creating multiple copies of a bean costs memory and time. So, some components can reuse the same singleton bean in a thread safe way.
https://docs.spring.io/spring-framework/docs/3.0.0.M3/reference/html/ch04s04.html

No comparing Creating multiple copies of a bean and create a bean with spring bean with singleton scope, but comparing a class with just static method and static final fields (so this is stateless?) with spring bean with singleton scope.

You don't use operator new for Spring. Spring expects to handle instantiation internal to its bean factory. Only non-Spring beans should be constructed with new or its equivalents. Note also that a bean constructed with new is external to Spring, so it doesn't get the Spring benefits such as auto-wiring. So where possible make all your beans be Spring Beans.

Spring's bean factory constructs singleton instances by default. Note that when I say "singleton" here, I mean that there's a single instance, not that it's classically Singleton, with the enforcement mechanisms for ensuring that the bean is totally and forever singleton. The only enforcement would be Spring itself.

Spring singleton instances can be, and often are stateful.  But a stateful singleton object's primary purpose is to ensure single definitive property values between all participants. Often, however, there are only 2 participants because Spring does so much of what it does by wiring standard components together. So that's OK. If there are more participants, and especially if there are Threads involved, Spring does not enforce synchronization, so that's something the bean itself would be obliged to deal with.

Tim Holloway wrote:You don't use operator new for Spring. Spring expects to handle instantiation internal to its bean factory. Only non-Spring beans should be constructed with new or its equivalents. Note also that a bean constructed with new is external to Spring, so it doesn't get the Spring benefits such as auto-wiring. So where possible make all your beans be Spring Beans.

Spring's bean factory constructs singleton instances by default. Note that when I say "singleton" here, I mean that there's a single instance, not that it's classically Singleton, with the enforcement mechanisms for ensuring that the bean is totally and forever singleton. The only enforcement would be Spring itself.

Spring singleton instances can be, and often are stateful.  But a stateful singleton object's primary purpose is to ensure single definitive property values between all participants. Often, however, there are only 2 participants because Spring does so much of what it does by wiring standard components together. So that's OK. If there are more participants, and especially if there are Threads involved, Spring does not enforce synchronization, so that's something the bean itself would be obliged to deal with.

NO, spring singleton instances is stateless, its field is shared by all request.
But after searching on Web, I find some different of using singleton bean than static method,
e.g. singleton bean can override interface method, static method cannot.
https://www.baeldung.com/java-static-class-vs-singleton

peter tong wrote:Sorry but still has some unknown, if create a stateless object that doesn't change its internal state, then is this like create a class with all static member and static method? Why need create such Singleton, stateless object (bean) in spring?

No. The use of static fields is a completely different matter. In general, you must stay far far away from static fields altogether, regardless of whether you're trying to implement a stateless or a stateful type.

A stateless type doesn't evolve over time. This doesn't mean it can't have any instance fields. It just means that those fields shouldn't change value after the object has been constructed, and any objects referenced by such fields should also be stateless. Once again, making a type immutable is a great way of ensuring an object is stateless.

Your services and controllers should be stateless. Here is an example:
@Service public final class ChessGameService {  private final ChessGameRepository repository;  @Autowired  public ChessGameService(ChessGameRepository repository) {    this.repository = requireThat("repository", repository, is(notNullValue()));  }  public ChessGame makeMove(String gameId, Move move) {    var game = repository.retrieveById(gameId).orElseThrow();    game.applyMove(move);    repository.store(gameId, game);    return game;  } }
This service is stateless because it only consists of a reference to a repository, and the reference never changes. The repository itself should also be stateless: it only consists of a reference to a data source.

An example of a class that is not stateless is the ChessGame class used inside the makeMove() method. The state of the game is changed when applyMove() is called. This isn't a problem, because the ChessGame is created by the repository at the start of the makeMove() method and then discarded by the controller at the end of the request. Its lifetime is restricted to a small part of the current request, so it won't be accessed by multiple threads.

If the ChessGame was stored in a field, rather than retrieved from a database, you'd be in trouble: the service that has a reference to the chess game is now stateful as well and can no longer be shared between requests safely.

Stephan van Hulst wrote: The use of static fields is a completely different matter. In general, you must stay far far away from static fields altogether, regardless of whether you're trying to implement a stateless or a stateful type.

While Stephan's post is full of wisdom, I want to highlight this particular one.

One thing I've learned over the years is that nine times out of 10, what I started as static ended up as instance. A single-purpose bean often ends up being used in unexpected ways and often those ways work best if their users are working with separate instances with independent values. Perhaps a good illustration is a bean that converts Fahrenheit to Celsius. Simple static methods referencing a set of simple static values: C = (F-32) * 5/9.

Then one day you need Farenheit to Kelvin, Or Celsius to Kelvin abstractly, or Celsius to Rankine. One bean can do all this, but not one instance, since the formula values change even though the formulas themselves don't So the original static-only bean becomes an instance.