Skip to content

Item 3: Enforce the singleton property with a private

March 28, 2012

Item 3: Enforce the singleton property with a private

constructor or an enum type

A singleton is simply a class that is instantiated exactly once [Gamma95, p. 127].

Singletons typically represent a system component that is intrinsically unique,

such as the window manager or file system. Making a class a singleton can

make it difficult to test its clients, as it’s impossible to substitute a mock implementation

for a singleton unless it implements an interface that serves as its type.

Before release 1.5, there were two ways to implement singletons. Both are

based on keeping the constructor private and exporting a public static member to

provide access to the sole instance. In one approach, the member is a final field:

// Singleton with public final field

public class Elvis {

public static final Elvis INSTANCE = new Elvis();

private Elvis() { … }

public void leaveTheBuilding() { … }


The private constructor is called only once, to initialize the public static final field

Elvis.INSTANCE. The lack of a public or protected constructor guarantees a

“monoelvistic” universe: exactly one Elvis instance will exist once the Elvis

class is initialized—no more, no less. Nothing that a client does can change this,

with one caveat: a privileged client can invoke the private constructor reflectively

(Item 53) with the aid of the AccessibleObject.setAccessible method. If you

need to defend against this attack, modify the constructor to make it throw an

exception if it’s asked to create a second instance.

In the second approach to implementing singletons, the public member is a

static factory method:

// Singleton with static factory

public class Elvis {

private static final Elvis INSTANCE = new Elvis();

private Elvis() { … }

public static Elvis getInstance() { return INSTANCE; }

public void leaveTheBuilding() { … }


All calls to Elvis.getInstance return the same object reference, and no other

Elvis instance will ever be created (with the same caveat mentioned above).


The main advantage of the public field approach is that the declarations make

it clear that the class is a singleton: the public static field is final, so it will always

contain the same object reference. There is no longer any performance advantage

to the public field approach: modern Java virtual machine (JVM) implementations

are almost certain to inline the call to the static factory method.

One advantage of the factory-method approach is that it gives you the flexibility

to change your mind about whether the class should be a singleton without

changing its API. The factory method returns the sole instance but could easily be

modified to return, say, a unique instance for each thread that invokes it. A second

advantage, concerning generic types, is discussed in Item 27. Often neither of

these advantages is relevant, and the final-field approach is simpler.

To make a singleton class that is implemented using either of the previous

approaches serializable (Chapter 11), it is not sufficient merely to add implements

Serializable to its declaration. To maintain the singleton guarantee, you

have to declare all instance fields transient and provide a readResolve method

(Item 77). Otherwise, each time a serialized instance is deserialized, a new

instance will be created, leading, in the case of our example, to spurious Elvis

sightings. To prevent this, add this readResolve method to the Elvis class:

// readResolve method to preserve singleton property

private Object readResolve() {

// Return the one true Elvis and let the garbage collector

// take care of the Elvis impersonator.

return INSTANCE;


As of release 1.5, there is a third approach to implementing singletons. Simply

make an enum type with one element:

// Enum singleton – the preferred approach

public enum Elvis {


public void leaveTheBuilding() { … }


This approach is functionally equivalent to the public field approach, except that it

is more concise, provides the serialization machinery for free, and provides an

ironclad guarantee against multiple instantiation, even in the face of sophisticated

serialization or reflection attacks. While this approach has yet to be widely

adopted, a single-element enum type is the best way to implement a singleton.

From → Effective Java

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: