A Singleton is a quite simple concept, that can be implemented this way:

public class MySingleton {
  private static MySingleton instance = null;
  /** Private constructor. */
  private MySingleton() {
    // initialization...
  }
  public static MySingleton getInstance() {
    if (instance == null) {
      instance = new MySingleton();
    }
    return instance;
  }
  // other methods
}

But what about multiple threads call getInstance() simultaneously? The last one to complete
the constructor execution overwrites the instance field’s value: this is the instance that
will be given to the next callee, while the other instances were actually initialized but are
not referenced and will be garbage collected sooner or later. Depending on the constructor’s
and methods’ stuff, there could be other collateral damage, than the only initial memory
waste.

A possible solution is to initialize the field at declaration time (or to use a static
constructor): the instance will be created by Java on the first assess to that class.

public class MySingleton {
  private static final MySingleton INSTANCE = new MySingleton();
  /** Private constructor. */
  private MySingleton() {
    // initialization...
  }
  public static MySingleton getInstance() {
    return INSTANCE;
  }
  // other methods
}

Otherwise you could synchronize getInstance():

public class MySingleton {
  private static MySingleton instance = null;
  /** Private constructor. */
  private MySingleton() {
    // initialization...
  }
  public static synchronized MySingleton getInstance() {
    if (instance == null) {
      instance = new MySingleton();
    }
    return instance;
  }
  // other methods
}

This solution is correct but degrades the performance, because every getInstance() invocation
(and they could be a lot!) are slowed down by the synchronization checks: an exaggerated
countermeasure to avoid a race condition that can happen only at the very first uses of the
singleton!

The following solution is my favourite: while it only incurs in a double check when the
instance is still unassigned, it avoids the synchronization overhead for the next getInstance
() calls.

public class MySingleton {
  private static volatile MySingleton instance = null;
  /** Private constructor. */
  private MySingleton() {
    // initialization...
  }
  public static MySingleton getInstance() {
    if (instance == null) {
      synchronized (MySingleton.class) {
        if (instance == null) {
          instance = new MySingleton();
        }
      }
    }
    return instance;
  }
  // other methods
}

The first if is needed to see whether is is “worth” entering the synchronized block, whilst
the if-null-then-new statement must be executed atomically to avoid multiple instantiations.
When the race condition happens, multiple threads could enter the synchronized block, but the
first one only will create the singleton and the next ones will find a not-null instance
instead (even if instance was null two rows before).

You should note that Java 5 and the volatile modifier are needed: otherwise it doesn’t work,
as demonstrated by this technical article, made by more skilled than me people. I must thank
FindBugs, that has allowed me to discover the volatile “trick” and the web page with the info:
without that modifier, this initialization is marked with a “yellow bug”, because of a
“possible doublecheck” :

This method may contain an instance of double-checked locking.
This idiom is not correct according to the semantics of the Java memory model.
Annunci