After going through a couple job interviews, I quickly realized that there are many differing “opinions” (yes even among seasoned Java programmers) about the best way to initialize a singleton class. For the record, there are really only two fundamental ways of initializing a singleton properly in java: eager or lazy. Then there is a neat trick to try to get the best of both worlds so that makes a total of three. Depending on the person you talk to, one of these methods may be preferred over the others but all three listed below are thread safe.

Eager Initialization

In eager initialization, the singleton is instantiated when the programs starts whether or not it gets used. The problem with this approach is that valuable resources are allocated whether or not they ever get used. If the singleton has a large memory footprint, this may not be a good choice.

Example 1. Eager Initialization

public class Singleton {

    // Eager initialization happens here.
    static private Singleton instance = new Singleton();

    // Prevent instantiation by public.
    private Singleton() {
    }

    public static Singleton getInstance() {
        return instance;
    }
}

Eager initialization relies on the fact that the JVM will initialize the class members upon loading the class. And the class is loaded when it is first referenced.

Lazy Initialization

On the other end of the spectrum, we have lazy initialization which the object only get instantiated on the first time the getInstance() method is called. This has the advantage of not allocating the resources unless it is actually needed.

The problem with this approach is that the getInstance() method needs to be synchronized. Therefore there is a performance hit when acquiring the singleton.

Example 2. Lazy Initialization

public class Singleton {

    static private Singleton instance = null;

    // Prevent instantiation by public.
    private Singleton() {
    }

    synchronized public static Singleton getInstance() {
        if (instance == null) {
            // Lazy initialization happens here
            // on the first call to this method.
            instance = new Singleton();
        }
        return instance;
    }
}

Do not try to circumvent the synchronized method by using a DCL (double check locking) mechanism as it does not work with the java memory model. Read more about that by following the resources links below.

Initialize-on-demand holder class idiom

There is one final way to get the best of both worlds and that is to use “Initialize-on-demand holder class” idiom which can be found in “Effective Java” by Joshua Bloch. This method relies on the JVM only intializing the class members upon first reference to the class. In this case, we have a inner class that is only referenced within the getInstance() method. This means SingletonHolder will get initialized on the first call to getInstance().

Example 3. Initialize-on-demand

public class Singleton {

    // Prevent instantiation by public.
    private Singleton() {
    }

    public static Singleton getInstance() {
        return SingletonHolder.instance;
    } 

    /**
     * Singleton implementation helper.
     */
    private static class SingletonHolder {
        // This gets initialized on first reference
        // to SingletonHolder.
        static final Singleton instance = new Singleton();
    }
}

Now the singleton object will not get allocated until it is used and we did not need to incur the overhead of a synchronized method call.

Happy programming,
Chiao

References and Resources

• Fixing the Java Memory Model, Part 2
• Double-checked locking: Clever, but broken
• Revisiting Singleton Pattern