Singleton Design Pattern using Java

In Java the Singleton pattern will ensure that there is only one instance of a class is created in the Java Virtual Machine. It is used to provide global point of access to the object. In terms of practical use Singleton patterns are used in logging, caches, thread pools, configuration settings, device driver objects. 

Table of content

  1. Definition
  2. Advantage
  3. Structure
  4. UML Diagrams
  5. Implementation ExampleLazy initialisation
    • Eager initialisation
    • Static block initialisation
    • Thread safe singleton
    • Bill Pugh singleton
    • enum singletons
  6. Using Reflection to Destroy Singleton Patterns
  7. Preserve single instance – clone
  8. Serialisation vs deserialisation
  9. Usage of singletons
  10. FAQs


Singleton Pattern says that just “define a class that has only one instance and provides a global point of access to it”.

Singleton is categorised under creational design patterns.

In this article we are going to take a deeper look into the usage of the Singleton pattern. It is one of the most simple design pattern in terms of the modelling but on the other hand this is one of the most controversial pattern in terms of complexity of usage.


Saves memory because object is not created at each request. Only single instance is reused again and again.

This has advantages in memory management, and for Java, in garbage collection. Moreover, restricting the number of instances may be necessary or desirable for technological or business reasons–for example, we may only want a single instance of a pool of database connections.


Key termDescription
Static memberThis contains the instance of the singleton class.
Private constructorThis will prevent anybody else to instantiate the Singleton class.
Static public methodThis provides the global point of access to the Singleton object and returns the instance to the client calling class.

UML Diagrams

Class diagram to describe the simple singleton class
How Single shared resource is getting shared by multiple object
Sequence diagram: How Lock is getting acquired in Threaded environment

Implementation Example

Lazy initialization

Let us look into a singleton implementation example in Java. The below code uses Lazy initialisation process.

When this class will be called from the client side using SingletonExample.getSingletonInstance().printSingleton(); then at the first time only an instance will be created. During second time onwards for all subsequent calls we will be referring to the same object and the getSingletonInstance() method returns the same instance of the SingletonExample class which was created during the first time. You can test this by adding a print statement the following code as:

Lazy initialisation is a method to implement the Singleton pattern to create an instance in the global access method.

Early loading

please note that double check locking might not work before Java 5. In such situation, we can use early loading mechanism.

Static Block Initialization

Static block initialisation is similar to eager initialisation, except that the instance of the class is created in the static block that provides the option for exception handling.

Thread-Safe Singletons

The easier way to create a thread-safe singleton class is to make the global access method synchronized so that only one thread can execute this method at a time. The general implementation of this approach is like the following class:

The above code works absolutely fine in a single threaded environment and processes the result faster because of lazy initialization. However the above code might create some abrupt behaviour in the results in a multithreaded environment as in this situation multiple threads can possibly create multiple instance of the same SingletonExample class if they try to access the getSingletonInstance() method at the same time. Imagine a practical scenario where we have to create a log file and update it or while using a shared resource like Printer. To prevent this we must use some locking mechanism so that the second thread cannot use this getInstance()method until the first thread has completed the process.

Bill Pugh Singleton

A Bill Pugh Singleton is based on the “initialization on demand holder” idiom. This idiom uses inner classes and does not use any synchronization construct. It uses static blocks, but in a different way — and suggests using static inner classes.

We will rewrite the above Logger program using the Bill Pugh approach here.

enum singleton

Implementing Singleton in Java 5 or above version using Enum:
Enum is thread safe and implementation of Singleton through Enum ensures that your singleton will have only one instance even in a multithreaded environment. Let us see a simple implementation:

Reflection to Destroy Singleton Patterns

Reflection can be used to destroy all the above Singleton implementation approaches. Let’s see this with an example class:

When you run the above test class, you will notice that the hashcode of both the instances is not same, which destroys the Singleton pattern. Reflection is very powerful and used in a lot of frameworks.

Overcome reflection issue: To overcome issue raised by reflection, enums are used because java ensures internally that enum value is instantiated only once. 

Preserve single instance – clone

The below code is for preventing the singleton class to be cloned.Override the clone method and throw new CloneNotSupportedException()

Serialisation vs De-serialisation

Sometimes in distributed systems, we need to implement a Serialyisable interface in our Singleton class so that we can store its state in a file system and retrieve it at a later point in time. Here is a small Singleton class that also implements a Serialisable interface.

The problem with the above serialised singleton class is that whenever we deserialise it, it will create a new instance of the class. Let’s see it with a simple program.

Uses of Singleton Design Pattern


Hardware printers 

Cache: We can use the cache as a singleton object as it can have a global point of reference and for all future calls to the cache object the client application will use the in-memory object.


Hey Users, Hope you like this article. I need your input for below questions.

Question 1 : Why can’t we use a static class instead of singleton?

Question 2: Can the singleton class be subclassed?

Question 3: Can there be multiple instance of singleton using cloning?

Question 4: What is the impact if we are creating another instance of singleton using serialisation and deserialisation?

Question 5: Which other pattern works with Singleton? Example please

Question 6: Which classes in JDK uses singleton pattern?

One Comment

  1. Pingback: design pattern | java | android - Technical Jungle

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.