Is singleton stateful?

Hi I got this asked in a开发者_C百科n interview question paper.

Singleton and Prototype (non-singleton) which is stateful and which is stateless

I am not sure if prototype is stateless ? Is there any problem with the question ?

---

The question itself is poorly worded. You can have state in both Singletons and Prototypes (instances), as in it is legal code, but you do not need to have state in either cases. Since Spring is mentioned, I will try to answer this in regards to working with Spring.

In terms of Spring bean scope, singleton will cause the ApplicationContext to create a single instance and use that instance everywhere the bean is asked for. prototype will cause the ApplicationContext to create a new instance each time the bean is asked for.

It is ok for both of these to be stateful.

---

This question looks pretty legal (though poorly worded) if you read "stateless" as "doesn't have conversational state", i.e. a state related to a conversation with a particular client.

In these terms, singleton-scoped beans are usually stateless, because they are used by multiple clients simultaneosly and their states are not client-specific.

On the contrary, prototype-scoped beans are often created in a context of a conversation with a particular client (though request and session scopes may be more appropriate sometimes), so that their states are related to those conversations (because if your bean don't need to keep any conversational state, you can make it a singleton). In this sense prototype beans are stateful.

---

Prototype beans and Singleton beans can both hold state. However, according to the Spring documentation, "you should use the prototype scope for all beans that are stateful, while the singleton scope should be used for stateless beans."

---

A better question might be "Is Singleton thread-safe?"

It's perfectly thread-safe if the state it contains is read-only and immutable. You just have to be more careful if it's mutable. If yes, it could be in danger of becoming a bottleneck for your app. Synchronizing that shared, writable state must be done.

---

singleton is not data object, think about singleton as data wrapper, point of access methods,

singleton may be destroyed but presented state stored separately and independently and will be presented after singleton recreated (android sends greetings, destroyed singletons is notorious trap)

---

stateless beans: beans that are singleton and are initialized only once. The only state they have is a shared state. These beans are created while the ApplicationContext is being initialized. The SAME bean instance will be returned/injected during the lifetime of this ApplicationContext. .

stateful beans: beans that can carry state (instance variables). These are created every time an object is required.

---

A stateless singleton is pretty much a collection of static methods; it's no different from a static util class, and it doesn't really matter how many instances there are: 0, 1, 2 or infinity.

Therefore singletons are usually stateful.

(This is why it's nonsensical to argue that a singleton implemented in enum has serialization problem automatically taken care of. It the singleton is stateless, the argument is moot; if the singleton is stateful, the argument is broken)