So, Singleton or Monostate?

Continuing with the design pattern fun, lets talk about one of the most commonly used pattern, Singleton and an alternative called Monostate. I too wrote about singleton pattern relative to Joshua Bloch’s Effective Java a few days back.

The Basic Difference in Two
Well what is this monostate we talk about? Monostate is very similar to a singleton and you may call it a conceptual singleton. The basic difference between the two is that-

    • Problem with Singleton –
      The intent is to ensure that only a single instance of an entity is created, which in turn ensures a single state of that entity which can be shared across threads. But, sharing the only instance we have brings synchronization into picture. Now we have a problem, is there a way to stay away from synchronization as our only instance may have been used extensively?
public class Singleton {
	private static Singleton instance = null;
	private static String stateVariable = null;

	// Prevent explicit constructions
	private Singleton() {

	// Notice the synchronized keyword here
	public synchronized static Singleton getInstance() {
		if (instance == null) {
			instance = new Singleton();
		return instance;

	 * Getter setter for state variables
    • How Monostate overcomes this problem- Monostate overcomes this problem by simply allowing more than one instances to be created, while maintaining a single state. Confused? Have a look at the following snippet.
public class Monostate {
	private static String stateVariable = null;

	// Allow explicit constructions
	public Monostate() {

	// Returns the current state
	public String getStateVariable() {
		return stateVariable;

	 * Sets the new state, since the state variable is static. All states are
	 * updated.
	public void setStateVariable(String stateVariable) {
		Monostate.stateVariable = stateVariable;

Lets Chew over this a little

      1. Singleton’s constructor is private to prevent explicit object creation. Since, in monostate we want to allow object creation for two threads, we want more than one instance. One for each thread. Thus, we make the constructor public.
      2. Setters and getters remain the same, as they are the ones which update and fetch the state.
      3. Is this totally thread safe? No it isn’t.

Not thread safe? So, why should one use it?

      1. Is not completely thread safe. But, it of course reduces the synchronization issues.
      2. Scenario where it could be useful- In stock market, there are several factors which may affect the performance of a company. Certain global factors which affect the performance should have an atomic state and also must be shared across the various events happening in the share market. So, the state of these global factors must be a monostate.
      3. Deletion of the instances will not result in deletion of the state.
      4. One wouldn’t subclass a singleton. But monostate can be easily sub-classed and behavior can be overriden.

The only bad thing I can think of about monostate is that it consists of creation and deletion of objects, which no doubt are expensive operations.

But, one should be careful when selecting between the two. Ask yourself the question, ‘Do I need a single instance or single state?’


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: