package com.rpktech.poc;
import java.util.Date;

public enum SingletonWithEnum {
	INSTANCE;	

	private volatile int count;
	private volatile Date date;		

        public int getCount() {	return count;}

	public void setCount(int countParam) { synchronized(this){ count = countParam; }}

	public Date getDate() {  return new Date(date.getTime());}

	public void setDate(Date dateParam) { synchronized(this){ date = (Date) dateParam.clone();}}

	public String printObject() {
		return "Singleton [count=" + getCount() + ", date=" + getDate() + "]";
	}

}

To test it with serialization and de-serialization I have used google’s GSON library.

package com.rpktech.poc;

import java.util.Date;

import com.google.gson.Gson;
import com.google.gson.GsonBuilder;

public class TestSingletonWithEnum{
	public static void main(String[] s)
	{
		SingletonWithEnum object1 = SingletonWithEnum.INSTANCE;

		object1.setCount(5);
		object1.setDate(new Date());		

		Gson gson = new GsonBuilder().create();

		SingletonWithEnum object2 = gson.fromJson(gson.toJson(object1), SingletonWithEnum.class);

		object2.setCount(3);

		if(object1 == object2)
			System.out.println("Same");
		else
			System.out.println("Differnent");

		System.out.println(object1.printObject());
		System.out.println(object2.printObject());

	}
}

Output

Same
Singleton [count=3, date=Thu Feb 12 20:39:47 IST 2015]
Singleton [count=3, date=Thu Feb 12 20:39:47 IST 2015]

Enum is good choice for singleton because :

1. Enum fields will be initialized when INSTANCE is first accessed or when enum is first accessed. So we can achieve lazy initialization functionality by not using INSTANCE until it (singleton object) is required.
2. You can not extend a proper Singleton since it’s supposed to have a private constructor, so using an enum is fine in place of class (Effective Java Item 2: Enforce the singleton property with a private constructor)

class SomeClass {
  private Resource resource = null;
  public Resource getResource() {
    if (resource == null)
      resource = new Resource();
    return resource;
  }
}

As you can see above “resource” will be initialized only when it will be needed. But this will not work in multi-threaded environment. Because multiple threads can be at line 5 at the same time and it will create multiple objects. To prevent this we can use synchronized keyword at the method level but creating “synchronized methods” are bad for performance, it cost more. So next thought comes to put synchronized block inside the function. Now code look like below

class SomeClass {
  private Resource resource = null;
  public Resource getResource() {
    if (resource == null) {
      synchronized(SomeClass.class){
        if (resource == null)
          resource = new Resource();
      }
    }
    return resource;
  }
}

Above code seems certainly better. It synchronizes “resource” so at a time only one thread can enter and initialize the resource. This implementation is called “Double checking lock” or DCL. But this is also having one issue with Java Memory Model. That is partially initialized objects can be returned. DCL has been explained very well in Brain Goetz article here. I will summarize it in the following statement.

When JVM executes multiple instructions, it can rearrange instructions such that actual result will not change but performance will increase. So when doing new Resource(), it can first allocate memory for object, return the reference to that memory location into “resource” variable and then it will start initialization of inner fields by calling constructor of “Resource object”. As the reference is returned before the constructor is called, it will result into partially created object which is undesirable because its a multi-threading environment and other threads can start using that reference when they found it “not null”.

This problem is very rare and it does not come on all the platforms because few JVMs actually implement the JMM properly. But we can overcome this issue by scarifying performance optimization which was happening by reordering of instructions. If we declare our lazy initialized objects to be volatile then JVM will not rearrange the order of instructions. Note that all the fields inside resource should also be volatile. If your resource class is some third party class and internal fields are not volatile then there are still chances of partially constructed objects. So this way we can improve more but it is still not fixed fully. After implementing volatile; now code will look like this

class SomeClass {
  private volatile Resource resource = null;
  public Resource getResource() {
    if (resource == null) {
      synchronized(SomeClass.class){
        if (resource == null)
          resource = new Resource();
      }
    }
    return resource;
  }
}

The above solution(partially fixed) works from Java 1.5 or later. Brain Goetz had written another article in which he showed a fully working solution for lazy initialization. But it works only for static fields where there should be only one instance of the field shared across all the objects like “db connection instance”. Here is the JSR-133 which covers DCL issue and introduced “Demand Holder idiom”. I will summaries it here.

Class initialization is inherently thread-safe and if you can have an object initialized on class initialization the object creation too are thread-safe.

So here is the less complicated solution of Lazy Initialization In Multi-threaded environment for static fields.

class SomeClass {

	  public Resource getResource() {
	    return ResourceHolder.instance;
	  }

	  // Resource Holder
	  private static class ResourceHolder{
	         private static final Resource instance = new Resource();
	  }
}

In above example resource will be only be created when getResource is called first time. As the class initialization is thread-safe so resource creation will automatically be thread-safe. But notice that inner class is static so this instance will be static. Static is must here, we can not remove it to support lazy initialization of non-static fields because if we remove “static” from inner class then we can not write “ResourceHolder.instance”. We have to create an object of that and object creation is not thread-safe only class loading is thread safe. This will also work for lazy initialization of singleton class because internally they have static field.

Note that if you have multiple static fields for lazy initialization then you have to create multiple static inner classes.

Here is the lazily initialized thread-safe singleton class

public class MySingletonClass{

   private MySingletonClass(){

   }
   public static MySingletonClass getInstance(){
         return IntiailizationOnDemandClassHolder.instance;
   }

   private static class IntiailizationOnDemandClassHolder{
         private static final MySingletonClass instance = new MySingletonClass();

   }

}

Tom has compared performance of all the approched in his blog.

This is over 25 times faster on our benchmark!

Above singleton will work fine but still sometimes people want to protect singleton from cloning, reflection and de-serialization & serialization so there will not be more than one objects of a singleton class. My next article will explain that more in detail.

Continue to Safe Singleton

References

• http://www.javaworld.com/article/2074979/java-concurrency/double-checked-locking–clever–but-broken.html
• http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#dcl
• http://stackoverflow.com/questions/5958767/is-double-checked-locking-is-broken-a-java-only-thing?rq=1
• http://stackoverflow.com/questions/4926681/why-is-double-checked-locking-broken-in-java?rq=1
• http://stackoverflow.com/questions/3578604/how-to-solve-the-double-checked-locking-is-broken-declaration-in-java
• http://www.javamex.com/tutorials/double_checked_locking_fixing.shtml
• http://literatejava.com/jvm/fastest-threadsafe-singleton-jvm/