Using Synchronized keyword in Singleton Design Pattern

[Cbani]

Below is a code of a singleton design pattern. Got some doubt mentioned at the bottom.

public class SingleTon implements Cloneable
{
private SingleTon()
{

}

private static SingleTon singleTonInstance;

public static synchronized SingleTon getInstance()
{

if (singleTonInstance == null)
singleTonInstance = new SingleTon();

return singleTonInstance;

}

protected Object clone() throws CloneNotSupportedException
{
throw new CloneNotSupportedException();
}
}

Statement : If getInstance() is called by thousand threads at a time and lets say getInstance() takes 1 sec for each execution; then it takes 1000 sec for all the threads to complete.
Question : What could be the solution to this?

[r035198x]

See Singleton pattern - Wikipedia, the free encyclopedia

For options.

[Cbani]

Thanks. wz really helpfull.

[Cbani]

See Singleton pattern - Wikipedia, the free encyclopedia

For options.

hi r035198x,

I got the solution. but still i have a doubt that how is the Bill Pugh approach a thread safe one. Could you please ellaborate?

watining for your response
cbani

[r035198x]

As explained on wiki, the SingletonHolder class is only loaded on the very first call of getInstance. The instance is created on class loading. So creation of the instance though started by a thread by calling getInstance, is actually completed by the JVM when loading the SingletonHolder class.

[Cbani]

As said : So creation of the instance though started by a thread by calling getInstance, is actually completed by the JVM when loading the SingletonHolder class.

Now What I want to understand from the above statement is if two thread are calling getInstance at the same time wont it create 2 instances?

If no then how exactly is it doing the same?

Till now what i have understood from the wiki is the only use of inner class is just not create the instance at the class laoding time. instead created at the first call to getnstance.

please correct me if i am going wrong anywhere.

[r035198x]

Two instances wont get created because the code fore creating the instance is in a static initializer of the class which is called by the JVM when the class is loaded. The class is only ever loaded once and the initialzer runs soon after (only) once. So the instance is not created on the calling thread but by the JVM. That's why I said that the creation is completed by the JVM not by the calling thread.

[Cbani]

Hi r035198x,

One last question.

So, instead of writing an inner class if i write in below way what would be the difference other than lazy loading?

public class SingleTon
{

private static final Singleton INSTANCE = new Singleton();

private SingleTon()
{

}

private static SingleTon singleTonInstance;

public static SingleTon getInstance()
{

return INSTANCE ;

}

}

[r035198x]

Your SingleTon class will be loaded and the instance created before any calls to getInstance are made at all. i.e Your solution does not have lazy initilization of the singleton since your SingleTon class is always loaded.

More helpful links are

Initialization on demand holder idiom - Wikipedia, the free encyclopedia

Double-checked locking - Wikipedia, the free encyclopedia

[Tolls]

To be honest, the only advantage of the lazy loading one comes if you have a Class with other static methods in it beyond the getInstance(), otherwise it's next to pointless.

[Cbani]

Hi,

thanks got it. :)

[r035198x]

To be honest, the only advantage of the lazy loading one comes if you have a Class with other static methods in it beyond the getInstance(), otherwise it's next to pointless.

Added with the advantages of lazy loading itself ofcourse. Most singletons are so expensive to create that it's best not to create them expect if they are really required.

[Tolls]

Well, the class won't be loaded until the getInstance() is called anyway...in almost every circumstance I can think of. So the inner class gains you nothing, as far as I can see.

[r035198x]

Well, the class won't be loaded until the getInstance() is called anyway...in almost every circumstance I can think of. So the inner class gains you nothing, as far as I can see.

But you don't want to design your class assuming that you won't need to add any more static methods.
In JEE applications the Singleton might be loaded anyway even before getInstance is called due to its location.

[Tolls]

Any singleton with static methods beyond getInstance() is probably a util class in disguise...and therefore not really correct.

Never encountered a web app loading up stuff before it's actually used, I have to say. Then again, probably not looking all that closely to see...:)