The singleton design pattern is designed to restrict instantiation of a class to one (or a few) objects. This is useful when exactly one object is needed to coordinate actions across the system. Sometimes it is generalized to systems that operate more efficiently when only one or a few objects exist. It is also considered an Anti-pattern since it is often used as a politically correct term for global variable, and hence frowned upon. Before designing a class as a singleton, it is wise to consider whether it would be enough to design a normal class and just use one instance.
The singleton pattern is implemented by creating a class with a method that creates a new instance of the object if one does not exist. If an instance already exists, it simply returns a reference to that object. To make sure that the object cannot be instantiated any other way, the constructor is made either private or protected. Note the distinction between a simple static instance of a class and a singleton. Although a singleton can be implemented as a static instance, it can also be lazily constructed, requiring no memory or resources until needed.
The singleton pattern must be carefully constructed in multi-threaded applications. If two threads are to execute the creation method at the same time when a singleton does not yet exist, they both must check for an instance of the singleton and then only one should create the new one.
The classic solution to this problem is to use mutual exclusion on the class that indicates that the object is being instantiated.
A correct threadsafe Java programming language lazy-loaded solution known as the "Initialization On Demand Holder" idiom suggested by Bill Pugh follows:
public class Singleton { // Private constructor suppresses generation of a (public) default constructor private Singleton() {} public static Singleton getInstance() { return SingletonHolder.instance; } private static class SingletonHolder { private static Singleton instance = new Singleton(); } }
An incorrect lazy-loaded example follows. It is left here to demonstrate a common error in Java. It is based on the Q&A link found below, modified for multi-threading, however, it is still vulnerable to the double-checked locking anti-pattern, also found below:
public class Singleton { private static Singleton INSTANCE = null; // Private constructor suppresses private Singleton() {} //synchronized creator to defend against multi-threading issues //another if check here to avoid multiple instantiation private synchronized static void createInstance() { if (INSTANCE == null) { INSTANCE = new Singleton(); } } public static Singleton getInstance() { if (INSTANCE == null) createInstance(); return INSTANCE; } }
A possible C++ solution (also known as Meyers singleton) where the singleton is a static local object (note: this solution is not thread-safe and is designed to give an idea of how singletons work rather than a solution usable in large-scale software project).
template<typename T> class Singleton { public: static T& Instance() { static T theSingleInstance; //assumes T has a default constructor return theSingleInstance; } };
class OnlyOne : public Singleton<OnlyOne> { //..rest of interface defined here };
In a prototype-based programming language, where objects but not classes are used, a "singleton" simply refers to an object without copies or that is not used as the prototype for any other object.
See also
External links
- A Pattern Enforcing Compiler™ that enforces the Singleton pattern amongst other patterns
- Description from the Portland Pattern Repository
- Description by Vince Huston
- Implementing the Singleton Pattern in C#
- Implementing the Inheritable Singleton Pattern in PHP5
- Singleton Pattern and Thread Safety
- Article "Double-checked locking and the Singleton pattern" by Peter Haggar
- Article "Use your singletons wisely" by J. B. Rainsberger
- Article "Simply Singleton" by David Geary