Suppose you have an application that uses the Singleton Design pattern for one of it’s classes. But, the problem is that the singleton is expensive to create, because a resource intensive database access is necessary to create the singleton. What can you do to possibly add some efficiency to the process of creating a singleton?

This question is part 2 in our series of design interview questions. It will help if you read part 1 first, since we refer to some of the code that’s used in part 1.

So, the question here is what can you do to help a situation in which a Singleton is expensive to create.

The Singleton design pattern says that there can only be one instance of the class to which the pattern is applied. But, the Singleton design pattern does not say anything at all about when exactly that instance must be created.

Create the instance right before it is needed

Let’s use the Logging class example that we went through in part 1 – you can just assume that creating the singleton for the Logging class is very resource intensive.
So, instead of creating an instance of the Logging class when the class is loaded, we will just create the instance right before that instance is actually needed.




This means that we will need to change the getSingleton() method to initialize the instance of the Logging class, but only if that instance has not been initialized already. So, the new getSingleton() method would now look like this – where singletonInstance represents the instance of the singleton of course:

public static Logging getSingleton() {
/*Create the singleton instance only if it's
  null, which means no one else has created it
  already
*/
             if( singletonInstance  == null ){
                 singletonInstance  = new Logging();
             }

             return singletonInstance;
         }

Just for reference, this is what the getSingleton() method looked like before – note that the singletonInstance is not being initialized:

public static Logging getSingleton() 
{ 
  return singletonInstance; 
}

And the singleton itself will be changed to look like this:

/* note that it is no longer final and it initially points to null
   the old version looked like this - because it was initialized
   without anyone actually calling the getSingleton method :
   private static final Logging singletonInstance = new Logging();
*/
private static Logging singletonInstance = null; 

Note that the method used to retrieve the Singleton instance will now check to see if the “instance” member variable is null. If it is null that of course means that the singleton has not yet been created, so it will then actually create the instance. This will of course only happen the first time the getInstance method is called. But if instance is not null, the instance will simply be returned.

This technique is known as lazy loading

So, we want to repeat that the key thing to understand here is that the method has been changed to check if an instance already exists. If it does exist, it just returns that instance. If it doesn’t exist, then it just creates a new instance and returns that one. The whole point of this is to save resources by instantiating the Singleton only when it’s actually needed. This technique is commonly known as lazy loading, or deferred initialization, because of the fact that the singleton instance is created only once it’s needed – hence it’s “lazy” or “deferred”.

Hiring? Job Hunting? Post a JOB or your RESUME on our JOB BOARD >>

Subscribe to our newsletter for more free interview questions.

  • Manisha Nandal

    Added thread safe code in last design pattern section in comments

  • Sofiane Cherchalli

    Be aware this implementation of singleton is not thread safe. If several threads call getSingleton method the first time, they would all see that the singletonInstance static variable is null, and hence would proceed to create a new instance of the Logging class, which would lead to disastrous results…

    You need to synchronize access to the getSingleton method:

    public synchronized static Logging getSingleton() { … }

    Another alternative is to use the lazy initialization holder class idiom which is thread safe too.

  • Sadiq

    easy and detailed explanation.. Thanks