How to write a Singleton in proper manner?

Question

Today in my interview one interviewer asked me to write a Singleton class. And i gave my answer as

public class Singleton {      private static Singleton ref;      private Singleton() {     }      public static Singleton getInstance() {         if (ref == null) {             ref = new Singleton();         }         return ref;     } } 

suddenly he told me this is old way of writing the class. Can any one please help me why he told like that.

Answer 1

The first thing which comes to my mind when creating a singleton is enum. I generally use enum to implement singleton:

enum Singleton {     INSTANCE; } 

One benefit you get with using enum is with Serialization.

With singleton class, you would have to make sure that serialization and deserialization doesn't create a new instance by implementing the readResolve() method, while this is not the case with enum.

Using class you should create the singleton like this:

public final class Singleton implements Serializable {     // For lazy-laoding (if only you want)     private static class SingletonHolder {         private static final Singleton INSTANCE = new Singleton();     }      private Singleton() {         if (SingletonHolder.INSTANCE != null) {             // throw Some Exception         }     }      public static Singleton getInstance() {         return SingletonHolder.INSTANCE;     }      // To avoid deserialization create new instance     @SuppressWarnings("unused")     private Singleton readResolve() {         return SingletonHolder.INSTANCE;     } } 

Answer 2

Latest Standard Solutions:

• Core java with Managed Beans / CDI

  @ApplicationScoped public class MySingleton { ... } 

• EJB Lite (JEE6)

  @Singleton public class MySingleton { ... } 

Prior Recommendation (from 'Effective Java 2'):

• Use an enum, with a single bogus enumeration constant e.g. INSTANCE. Data fields and methods can be either static or non-static (instance) - the two behave equivalently, since there's only one instance

• Advantages:

  • Yep, it's a singleton. Impossible to create more than one instance by any mechanism (within any given class loader on any JVM).
  • Singleton initialization is thread safe.

• Disadvantages (compared with above Standard Solutions):

  • The definition is a little obtuse - the 'enum' outer shell could misdirect inexperienced code maintainers. It's a small hack, not the original intention of enum.
  • The implementation leaks through the abstraction. It violates the Uniform Access Principle
    • It doesn't work via injection - the client must know it is a singleton & code against the precise enum instance
    • The client must use Singleton.INSTANCE.someMethod()
    • The client can't (simply) code against an interface
    • The client's impacted by design changes between singleton to/from multi-instance objects
  • Extends an ancestor class (Enum), preventing inheritance from other classes
  • Serialization & deserialization just transfer the enum constant name without state - good for technically ensuring there's only one instance, but a null operation with regards to data. In the (rare) event one wanted to share/synchronise singleton state across JVMs/class loaders, replication via serialization couldn't be used.