Software Development

Using the Singleton pattern in Java

Peter Mikhalenko describes how Singleton works, explains when you should use it, and cautions you to watch out for potential pitfalls you may encounter when using Singleton.

The Java Singleton pattern belongs to the family of design patterns that governs the instantiation process. A Singleton is an object that cannot be instantiated. This design pattern suggests that at any time there can only be one instance of a Singleton (object) created by the JVM. You implement the pattern by creating a class with a method that creates a new instance of the class if one does not exist. If an instance of the class exists, it simply returns a reference to that object.

How the Singleton pattern works

Here's a typical example of Singleton:

public class Singleton {

       private final static Singleton INSTANCE = new Singleton();

 

   // Private constructor suppresses generation of

   // a (public) default constructor

   private Singleton() {}

 

   public static Singleton getInstance() {

     return INSTANCE;

   }

}

The classic Singleton does not use direct instantiation of a static variable with declaration -- it instantiates a static instance variable in the constructor without checking to see if it already exists:

public class ClassicSingleton {

   private static ClassicSingleton INSTANCE = null;

   private ClassicSingleton() {

      // Exists only to defeat instantiation.

   }

   public static ClassicSingleton getInstance() {

      if(INSTANCE == null) {

         INSTANCE = new ClassicSingleton();

      }

      return INSTANCE;

   }

}

The Singleton class's default constructor is made private, which prevents the direct instantiation of the object by other classes using the new keyword. A static modifier is applied to the instance method that returns the Singleton object; it makes this a class level method that can be accessed without creating an object.

When you need Singleton

Singletons are truly useful when you need only one instance of a class, and it is undesirable to have more than one instance of a class.

When designing a system, you usually want to control how an object is used and prevent users (including yourself) from making copies of it or creating new instances. For example, you can use it to create a connection pool. It's not wise to create a new connection every time a program needs to write something to a database; instead, a connection or a set of connections that are already a pool can be instantiated using the Singleton pattern.

The Singleton pattern is often used in conjunction with the factory method pattern to create a systemwide resource whose specific type is not known to the code that uses it. An example of using these two patterns together is the Abstract Windowing Toolkit (AWT). In GUI applications, you often need only one instance of a graphical element per application instance, like the Print dialog box or the OK button.

Watch out for potential problems

Although the Singleton design pattern is one of the simplest design patterns, it presents a number of pitfalls.

Construct in multi-threaded applications

You must carefully construct the Singleton pattern in multi-threaded applications. If two threads are to execute the creation method at the same time when a Singleton does not exist, both must check for an instance of the Singleton, but only one thread should create the new object. The classic solution to this problem is to use mutual exclusion on the class that indicates that the object is being instantiated. This is a thread-safe version of a Singleton:

public class Singleton

{

  // Private constructor suppresses generation

  //  of a (public) default constructor

  private Singleton() {}

 

  private static class SingletonHolder

  {

    private final static Singleton INSTANCE = new Singleton();

  }

 

  public static Singleton getInstance()

  {

    return SingletonHolder.INSTANCE;

  }

}

For an alternative solution, you can add the synchronized keyword to the getInstance() method declaration:

   public static synchronized Singleton getInstance()
Think ahead about cloning prevention

You can still create a copy of the Singleton object by cloning it using the Object's clone() method. To forbid this, you need to override the Object's clone method, which throws a CloneNotSupportedException exception:

      public Object clone() throws CloneNotSupportedException {

        throw new CloneNotSupportedException();

      }
Consider making the singleton class final

You may want to make the Singleton class final to avoid sub classing of Singletons that may cause other problems.

Remember about garbage collection

Depending on your implementation, your Singleton class and all of its data might be garbage collected. This is why you must ensure that there must be a live reference to the Singleton class when the application is running.

Conclusion

The Singleton pattern is widely used and has proved its usability in designing software. Although the pattern is not specific to Java, it has become a classic in Java programming. Despite its simplicity, remember the limitations of the Singleton pattern that I describe in this article.

Peter V. Mikhalenko is a Sun certified professional who works for Deutsche Bank as a business consultant.

---------------------------------------------------------------------------------------

Get Java tips in your inbox Delivered each Thursday, our free Java newsletter provides insight and hands-on tips you need to unlock the full potential of this programming language. Automatically subscribe today!
10 comments
javabuddy
javabuddy

Hi , There could be another solution if Singleton is written in JAVA by using Enum way as explained in book "Effective Java". public enum Singleton { INSTANCE; } Thanks Javin Why String is immutable in Java

alexdmiller
alexdmiller

This article seems woefully incomplete when talking about multi-threaded access to Singletons in Java. See this for a more thorough discussion. You may also be interested in this discussion of why you should avoid using Singleton in the first place.

Eric.Jablow
Eric.Jablow

If you need to make the class Serializable, you need to add a readResolve() method to the class: public Object readResolve() { return getInstance(); } Otherwise, deserialization will construct a new instance of the class and use it. The pre-enum style of type-safe enumerations has the same problem.

robin.sharma117
robin.sharma117

Although it has valid uses, i think Singleton is one pattern that has been consistently (ab)used, especially in Java code. It's too easy to make a class a Singleton and end up with code that's very tightly coupled, is difficult to unit-test as it's difficult to mock, and makes a lot of assumptions about the calling code. Have a look at this: http://www.ibm.com/developerworks/webservices/library/co-single.html

Justin James
Justin James

... that's a lot of work! In VB.Net, you just mark a class or method with "Shared" and you are done. I understand why, Java gives you much more control doing it the way you describe, but you would think that since it is such a common pattern, they would have made it a bit easier. J.Ja

dmitry.digi
dmitry.digi

In my opinion, every article about singleton should start with warning "try avoid using it" with suggestions to overcome the problem. Any time we had singleton we discovered a number of bugs, and once we got the requirement to support more than one instance, re-factoring was a nightmare. One simple rule to remember - one instance of object doesn't mean singleton pattern.

tecchy
tecchy

...that amount of work is necessary in VB.NET too... VB's 'Shared' is analogous to java or c#'s 'static'. Marking a class Shared or static makes it non-instantiable, like a module, not a Singleton. The pattern for Singleton classes is exactly the same in VB.NET as it is in Java as it is in C# as it is in C++, etc... (save for the thread-safe stuff). No language has direct support for this pattern, because it IS so easy to implement with standard language constructs.

peter_econ
peter_econ

Well I don't think that making common patterns a part of language is really a good idea. Better is to give more flexibility to developer. That's what all these Java patterns are about.

Justin James
Justin James

I am truly sorry, I goofed big time! I was not really paying best attention, and thought that was all to prevent instantiation! My deepest apologies! J.Ja

alaniane
alaniane

If you want maximum flexibility then program in Assembly. You can design the classes the way you want them. Adding common patterns to programming languages helps to speed up development. Personally, I think a programming language needs to be adapted to a specific field rather than making every language capable of doing the same thing. The idea that Cobol was written for business apps and Fortran for scientific/engineering apps allows a programmer to choose his design tool.

Editor's Picks