Singleton Class

[vinora kumar]

Hi all
I have a doubt with singleton class
Usually we all declare a singleton class as following only

    
public class ClassicSingleton {
   private static ClassicSingleton instance = null;
   protected ClassicSingleton() {
      // Exists only to defeat instantiation.
   }
   public static ClassicSingleton getInstance() {
      if(instance == null) {
         instance = new ClassicSingleton();
      }
      return instance;
   }
}

Can any one tell me other possibilities of creating singleton class?
Problem with an above approach is instance is static variable
If two threads hits my getInstance() method at the same time, same sec
Then I will have two instances for sure…
So what’s the best way to create thread safe singleton class?
Another point is I hate to use the word ‘synchronized’ directly
Their should be some approach available?

[Jelle Klap]

The easiest way would be to use eager instantiation, instead of the lazy approach where the first call to getInstance() is responsible for initializtion of the static instance member.

[Ankit Garg]

first of all make the constructor private. Otherwise someone would create a sub-class from it and create multiple instances. The solution to your second problem is either to use eager instantiation or synchronize the getInstance method. The eager instantiation would work like this

public class ClassicSingleton {
   private static ClassicSingleton instance = new ClassicSingleton();
   private ClassicSingleton() {
      // Exists only to defeat instantiation.
   }
   public static ClassicSingleton getInstance() {
      return instance;
   }
}

[Rob Spoor]

And if you still want lazy evaluation, you can make the entire getInstance() method synchronized.

[Jelle Klap]

And if you want to prevent incurring the unneccesary synchronization overhead for each and every call to getInstance() you could leave the getInstance() method unsynchronized and use an initialization holder to still achieve lazy initialization. The same could be achieved using the double-checked locking approach, but that approach should ideally be avoided.

[Campbell Ritchie]

This is the beginner's forum, and it is probably best to explain new concepts fully.

Please explain double-checked locking; it used not to work, and used to be regarded as an error. That may no longer be true.

[vinora kumar]

thanks friends

[Rob Spoor]

See http://www.ibm.com/developerworks/java/library/j-dcl.html for the double-checking locking mechanism.

[Mike Simmons]

This may be the beginner forum, but I think the topic asked about is inherently more complex than is usually appropriate for this forum. Perhaps it should be moved.

The article Rob links to is a bit old. It explains the problems with double-checked locking prior to JDK 5. However in JDK 5 they improved the volatile keyword to make it a bit more useful, and now it is possible to reliably implement DCL in Java, if and only if you make your variable volatile.

More discussion of this and other approaches can be found here. Note that the comment by Allen Holub is from pretty old, and does not really apply any more. Volatile is significantly quicker than it used to be. You can also find more info here.

[Campbell Ritchie]

Agree with Mike S; once you get onto "volatile" you are well out of beginner's.

[Vadim Vararu]

Hey guys! I don't realize what's actually the difference between this:

# public class ClassicSingleton {
# private static ClassicSingleton instance = null;
# private ClassicSingleton() {
# // Exists only to defeat instantiation.
# }
# public static ClassicSingleton getInstance() {
# if(instance == null) {
# instance = new ClassicSingleton();
# }
# return instance;
# }
# }



and the eager instantiation:

# public class ClassicSingleton {
# private static ClassicSingleton instance = new ClassicSingleton();
# private ClassicSingleton() {
# // Exists only to defeat instantiation.
# }
# public static ClassicSingleton getInstance() {
# return instance;
# }
# }

[Vikas Kapoor]

Ankit Garg wrote:first of all make the constructor private. Otherwise someone would create a sub-class from it and create multiple instances. ...
[/code]

I think it would make more sense and explicit if we declare the class final.

[Vadim Vararu]

The correct solution for concurrency problem is to syncronize getInstance() method and that's all. Why to reinvent the wheel?