Java Singleton Design Pattern : Questions

Question

I had an interview recently and he asked me about Singleton Design Patterns about how are they implemented and I told him that using static variables and static methods we can i

Answer 1

Query 1:

Different ways of creating Singleton

1. Normal Singleton : static initialization
2. ENUM
3. Lazy Singleton : Double locking Singleton & : Initialization-on-demand_holder_idiom singleton

Have a look at below code:

public final class Singleton{
    private static final Singleton instance = new Singleton();

    public static Singleton getInstance(){
        return instance; 
    }
    public enum EnumSingleton {
        INSTANCE;   
    }   
    public static void main(String args[]){
        System.out.println("Singleton:"+Singleton.getInstance());
        System.out.println("Enum.."+EnumSingleton.INSTANCE);
        System.out.println("Lazy.."+LazySingleton.getInstance());
    }
}
final class LazySingleton {
    private LazySingleton() {}
    public static LazySingleton getInstance() {
        return LazyHolder.INSTANCE;
    }
    private static class LazyHolder {
        private static final LazySingleton INSTANCE = new LazySingleton();
    }
}

Related SE questions:

What is an efficient way to implement a singleton pattern in Java?

Query 2:

One Singleton instance is created per ClassLoader. If you want to avoid creation of Singleton object during Serializaiton, override below method and return same instance.

private Object readResolve()  { 
    return instance; 
}

Query 3:

To achieve a cluster level Singleton among multiple servers, store this Singleton object in a distributed caches like Terracotta, Coherence etc.

Answer 2

a static field can have multiple occurrences in one JVM - by using difference class loaders, the same class can be loaded and initialized multiple times, but each lives in isolation and JVM treat the result loaded classes as completely different classes.

I don't think a Java programmer should care, unless he's writing some frameworks. "One per VM" is a good enough answer. People often talk that way while strictly speaking they are saying "one per classloader".

Can we have one singleton per cluster? Well that's a game of concepts. I would not appreciate an interviewer word it that way.

Answer 3

Singleton is commonly implemented by having a static instance object (private SingletonType SingletonType.instance) that is lazily instantiated via a static SingletonType SingletonType.getInstance() method. There are many pitfalls to using singletons, so many, in fact, that many consider singleton to be a design anti-pattern. Given the questions about Spring, the interviewer probably was looking for an understanding not only of singletons but also their pitfalls as well as a workaround for these pitfalls known as dependency injection. You may find the video on the Google Guice page particularly helpful in understanding the pitfalls of singletons and how DI addresses this.

Answer 4

I disagree with @irreputable.

The scope of a Singleton is its node in the Classloader tree. Its containing classloader, and any child classloaders can see the Singleton.

It's important to understand this concept of scope, especially in the application servers which have intricate Classloader hierarchies.

For example, if you have a library in a jar file on the system classpath of an app server, and that library uses a Singleton, that Singleton is going to (likely) be the same for every "app" deployed in to the app server. That may or may not be a good thing (depends on the library).

Classloaders are, IMHO, one of the most important concepts in Java and the JVM, and Singletons play right in to that, so I think it is important for a Java programmer to "care".

Answer 5

Singleton is a creational design pattern.

Intents of Singleton Design Pattern :

• Ensure a class has only one instance, and provide a global point of access to it.
• Encapsulated "just-in-time initialization" or "initialization on first use".

I'm showing three types of implementation here.

1. Just in time initialization (Allocates memory during the first run, even if you don't use it)

   class Foo{
   
       // Initialized in first run
       private static Foo INSTANCE = new Foo();
   
       /**
       * Private constructor prevents instantiation from outside
       */
       private Foo() {}
   
       public static Foo getInstance(){
           return INSTANCE;
       }
   
   }
   

2. Initialization on first use (or Lazy initialization)

   class Bar{
   
       private static Bar instance;
   
       /**
       * Private constructor prevents instantiation from outside
       */
       private Bar() {}
   
       public static Bar getInstance(){
   
           if (instance == null){
               // initialized in first call of getInstance()
               instance = new Bar();
           }
   
           return instance;
       }
   }
   

3. This is another style of Lazy initialization but the advantage is, this solution is thread-safe without requiring special language constructs (i.e. volatile or synchronized). Read More at SourceMaking.com

   class Blaa{
   
       /**
        * Private constructor prevents instantiation from outside
        */
       private Blaa() {}
   
       /**
        * BlaaHolder is loaded on the first execution of Blaa.getInstance()
        * or the first access to SingletonHolder.INSTANCE, not before.
        */
       private static class BlaaHolder{
           public static Blaa INSTANCE = new Blaa();
       }
   
       public static Blaa getInstance(){
           return BlaaHolder.INSTANCE;
       }
   
   }