What is the best solution for Singleton Pattern?

Question

If using INSTANCE holder class to implement Singleton Pattern, the compiler will generate another class file named classname$1.class. You can find the question by this link: here . So my question is what is the solution for Singleton Pattern? double check?

Answer 1

You can use simple enumeration.

public enum Singleton {
    INSTANCE;
}

You can access the INSTANCE simply as Singleton.INSTANCE rather than calling a getInstance() method. And by default , creation of Enum instance is thread safe.

Answer 2

You seem to be asking how this singleton code is implementing thread-safe initialization:

public final class Test {
     static final class TestHolder {
         private static final Test INSTANCE = new Test();
     }     

     private Test() {}

     public static Test getInstance() {
         return TestHolder.INSTANCE;
     }
}

The solution's thread-safeness is guaranteed because:

• static initialization is performed in a thread-safe fashion, and
• once initialized, a final variable can be used without further synchronization.

It is not doing double-checked locking.

Note that this particular pattern is thread-safe AND lazy initialized. If you want thread-safe singleton with non-lazy initialization then:

public final class Test {
     private static final Test INSTANCE = new Test();

     private Test() {}

     public static Test getInstance() {
         return INSTANCE;
     }
}

The "enum as singleton" approach is also acceptable ... despite what Engineer Dollery says.

Lazy initialization using double-checked locking can be implemented correctly from Java 5 onwards (if you do it right using a volatile), but in Java 1.4.x and earlier the idiom is broken.

Answer 3

I would go with enum after jdk 1.5. Check htis link for details : http://javarevisited.blogspot.in/2012/07/why-enum-singleton-are-better-in-java.html

1. Double check locking is not advised , it doesn't give performance.
2. The solution in the link you mentioned is an efficient solution using static inner class, as it doesn't use synchronize and uses lazy loading but enum is easiest to implement along with performance.

Below article explains why double check locking can be a bad choice[as Thomas pointed out, that Double check locking issue mentioned in beow article was fixed with Java 1.5] : http://www.ibm.com/developerworks/java/library/j-dcl/index.html

Answer 4

Depending on your deployment architecture it can become very difficult to implement a singleton in Java. When you're talking about singletons you also have to talk about their scope/context. Because few people understand this singletons have often been called evil and are considered anti-patterns.

If you're deploying to a single jvm, outside an application server, then the idiomatic approach is to implement a private final static instance of the class within itself and expose this through a suitably named method (getInstance() is common), and make the constructor of the class private. This is a singleton constrained to a single classloader and a single jvm.

However, this situation is incredibly uncommon.

In all other situations, you have to consider the classloader problem and the problem of having your code deployed to multiple jvms/servers. In a typical Java EE application container each war is usually loaded using its own classloader. If each war relies on a jar containing a singleton, they will each get their own copy of that singleton. This could be ok, if the singleton is for, say, a DB connection and you're allowed lots of them. But, if the singleton is supposed to protect access to a limited resource, then this isn't going to work well because you'll have one class capable of accessing that resource per webapp. The scope of your singleton here is container-scope.

It gets worse in full enterprise deployments, with clusters and live failover. In this environment you have many copies of your software running simultaneously. It's hard to imagine a java only singleton working at this scope -- the enterprise scope. At this level you need to figure out what the single source of truth is for singleton creation, or execution (if it's ok to have multiple instances but only one of them can be processing requests at a time), and all the singletons you create of the same type must defer to the single source of truth -- an enterprise semaphore.