A singleton is a design pattern that should restrict instantiation of a class to one single object. Normally a singleton contains a static getInstance() method that returns this instance.

The classic version of a singleton: lazy initialization

The modifier private of the standard constructor prevents instantiation from outside the class here. The getInstance() method creates the static instance on its first call:

1
2
3
4
5
6
7
8
9
10
11
12
13

public class SingletonClassic {
  private static SingletonClassic instance = null;
 
  private SingletonClassic() {
  }
 
  public static SingletonClassic getInstance() {
    if (instance == null) {
      instance = new SingletonClassic();
    }
    return instance;
  }
}

This version of a singleton can lead to problems on multithreading-environments if getInstance() is called by two (or more) threads simultaneously at the time the static instance is not already there. In this case it is possible that two different instances are being created and returned. A simple solution would be to add the synchronized modifier to the getInstance() method:

1
2
3
4
5
6
7
8

[...]
  public static synchronized SingletonClassic getInstance() {
    if (instance == null) {
      instance = new SingletonClassic();
    }
    return instance;
  }
[...]

But this solution is not really nice because getInstance() only has to be synchronized at the time creating its instance. The cost of synchronized parts on multithreading-environments can be much higher (threads waiting for other threads to release the lock), so often these parts are slower executed.

Singleton using double-checked locking idiom

To solve the problem from above, it is possible to implement a singleton using the double-checked locking idiom that should restrict the part which has to run synchronized. This will only work with Java 5 and newer versions (change of volatile modifier, explained here).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class SingletonDoubleCheckedLocking {
  private static volatile SingletonDoubleCheckedLocking instance = null;
 
  private SingletonDoubleCheckedLocking() {
  }
 
  public static SingletonDoubleCheckedLocking getInstance() {
    if (instance == null) {
      synchronized (SingletonDoubleCheckedLocking.class) {
        if (instance == null) {
          instance = new SingletonDoubleCheckedLocking();
        }
      }
    }
    return instance;
  }
}

Singleton with eager initialization

If creating an instance inside the singleton class is always needed, this is a solution that easily gets around the synchronizing-problems. The instance is created when the class is used. The final modifier ensures that it is not replaced or redefined.

1
2
3
4
5
6
7
8
9
10

public class SingletonEagerInit {
  private static final SingletonEagerInit INSTANCE = new SingletonEagerInit();
 
  private SingletonEagerInit() {
  }
 
  public static SingletonEagerInit getInstance() {
    return INSTANCE;
  }
}

Singleton using initialization-on-demand holder idiom

If it is a problem that the instance is automatically created at the time the class is being accessed like in the example above (perhaps in case of high cost or huge amount of resources necessary), here is the solution:

1
2
3
4
5
6
7
8
9
10
11
12
13

public class SingletonWithHolder {
 
  private static class LazyHolder {
    private static final SingletonWithHolder INSTANCE = new SingletonWithHolder();
  }
 
  private SingletonWithHolder() {
  }
 
  public static SingletonWithHolder getInstance() {
    return LazyHolder.INSTANCE;
  }
}

This solution is as lazy as possible, creating the instance only if getInstance() is called.

Singleton using enum

Probably the most recommended version of implementing a singleton using a Java version that supports it is using enums.

1
2
3
4
5
6
7

public enum Singleton {
  INSTANCE;
 
  public void execute() {
    [...]
  }
}

The singleton can be used like this:

Singleton.INSTANCE.execute();