It’s been a long time since Jdk 1.5 came along (it has now even passed it’s general support lifecycle) and brought many good changes. Infact, I heart all of them. One of the mature enterprise aspects of using Java as a platform is the promise of backward compatibility. The biggest example is choosing type-erasure for generic types (and keeping same Collections package too ;) rather than going for old-school reification and breaking the promise. From this point of view, the biggest achievement was the introduction of a clean and consistent memory model (JSR 133). Before that, almost all concurrency code written in Java was at the mercy of chance and was thus broken.

Among the older times, to create a lazy singleton, some people came up with a pattern called “Double check locking”. It went like this:

public class Foo {
  private Helper helper = null;
  public Helper getHelper() {
    if (helper == null)
      synchronized(this) {
        if (helper == null)
          helper = new Helper();
      }
    return helper;
  }
}

It would let you get rid of ‘synchronize’ing the complete method block and would lazily create the singleton instance. But the simple problem was… it was actually broken for any optimizing VM or shared-memory multiprocessor system. Why because an optimizing JVM is free to do out-of-order writes.

You could still create a singleton (for JVM) instance simply this way:

public class Foo {
  public static Foo instance = new Foo();
  private Foo() {}
}

But for a bean-scoped singleton (means singleton but only for a particular object) you couldn’t choose this way and all you were left with was the same broken DCL pattern.

Fast forward to the time when JSR 133 (a Java memory model standard) was being considered and ‘volatile’ keyword was finally gonna get some work to do :) So, now if you use ‘volatile’ modifier for the ‘Helper’ instance variable, it’ll cause the famous ‘happens-before’ relation to come into play and won’t let the JVM optimization to step on your shoes. You can safely use the old DCL pattern with ‘volatile’ keyword like this:

public class Foo {
  private volatile Helper helper = null;
  public Helper getHelper() {
    if (helper == null)
      synchronized(this) {
        if (helper == null)
          helper = new Helper();
      }
    return helper;
    }
  }

Still if this looks ugly to you, don’t feel bad because the JSR 133 also brought the thread-safety guarantee for the class loader and enabled the “Initialization on demand holder” pattern (one of my favorites) to come into existence to serve the cause of singleton.

public class Foo {
  private Foo() {}
  public static Foo getInstance() {
    return FooHolder.instance;
  }
  private static class FooHolder {
    private static Foo instance = new Foo();
  }
}

And here you go. A lazy and clean pattern to create a JVM-scoped singleton instance.
Never forget that you still have to resort to the, now-fixed, DCL pattern to create a bean-scoped singleton. But at least it’s not broken when you use it on a standard JDK 1.5+ JVM.

I hope this blog post busts a famous myth “DCL is broken”. It only _was_ back in the dark days of pre-jdk1.5 which was quite ages ago. Long since, it’s been working correctly, although you now have a cleaner way called IODH pattern.

P.S: I din’t touch on the aspect of utilizing an enum to create a robust Singleton (as mentioned in Effective Java) since this post was primarily a myth buster on DCL pattern. Let that be the topic of some other post.

Update 1: I think I forgot to mention that ‘volatile’ by no means guarantees atomicity. It’s also a common myth. For more details, read this.