When is a singleton not a singleton?

Avoid multiple singleton instances by keeping these tips in mind

By Joshua Fox, JavaWorld.com, 01/12/01

Page 3 of 7

Implementing singletons

There are a few ways to implement singletons. Although you can get singleton-like behavior with static fields and methods [for example, java.lang.Math.sin(double)], you gain more flexibility by creating an instance. With singletons implemented as single instances instead of static class members, you can initialize the singleton lazily, creating it only when it is first used. Likewise, with a singleton implemented as single instance, you leave open the possibility of altering the class to create more instances in the future. With some implementations of the singleton, you allow writers of subclasses to override methods polymorphically, something not possible with static methods.

Most commonly, you implement a singleton in Java by having a single instance of the class as a static field. You can create that instance at class-loading time by assigning a newly created object to the static field in the field declaration, as seen in Listing 1.

Listing 1

public class MySingleton {
    private static  MySingleton _instance =
        new MySingleton();
    private MySingleton() {
        // construct object . . .
    }
    public static MySingleton getInstance() {
        return _instance;
    }
    // Remainder of class definition . . .

Alternatively, you can instantiate it lazily, on first demand, as seen in Listing 2. You keep the constructor private to prevent instantiation by outside callers.

Listing 2

public class MySingleton {
    private static  MySingleton _instance;
    private MySingleton() {
        // construct object . . .
    }
    // For lazy initialization
    public static synchronized MySingleton getInstance() {
        if (_instance==null) {
            _instance = new MySingleton();
        }
        return _instance;
    }
        // Remainder of  class definition . . .
}

Both singleton implementations do not allow convenient subclassing, since getInstance(), being static, cannot be overridden polymorphically. Other implementations prove more flexible. While I don't have the space to describe alternative implementations in detail, here are a couple of possibilities:

• If you implement a factory class with a method that returns the singleton instance, you allow yourself flexibility in the runtime class of the return value, which can be either MySingleton or a subclass thereof. You may have to make the constructor nonprivate to make that work.
• You can have a SingletonFactory class with a globally accessible map of class names or Class objects to singleton instances. Again, the runtime type of the instances can be either the type indicated by the class name or a subclass, and the constructor will not be private.

For other possible implementations, see "Implementing the Singleton Pattern in Java" in Resources. As I discuss the singleton, keep the above implementations in mind, although many of those phenomena can occur for any implementation of the singleton.