View source for Initialization-on-demand holder idiom

In [[software engineering]], the '''initialization-on-demand holder''' ([[design pattern (computer science)|design pattern]]) idiom is a [[lazy initialization|lazy-loaded]] [[Singleton pattern|singleton]]. In all versions of Java, the idiom enables a safe, highly concurrent lazy initialization of static fields with good performance.<ref>The [[Double-checked locking|double checked locking idiom]] does not work correctly in Java versions prior to 1.5.</ref><ref>[https://stackoverflow.com/a/21605183 <code>INSTANCE</code> should be package private]</ref>

<syntaxhighlight lang="java">
public class Something {
    private Something() {}

    private static class LazyHolder {
        static final Something INSTANCE = new Something();
    }

    public static Something getInstance() {
        return LazyHolder.INSTANCE;
    }
}
</syntaxhighlight>

The implementation of the idiom relies on the initialization phase of execution within the [[Java Virtual Machine]] (JVM) as specified by the Java Language Specification (JLS).<ref>See [https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.4 12.4 of Java Language Specification] for details.</ref> When the class <code>Something</code> is loaded by the JVM, the class goes through initialization. Since the class does not have any static variables to initialize, the initialization completes trivially. The static class definition <code>LazyHolder</code> within it is ''not'' initialized until the JVM determines that <code>LazyHolder</code> must be executed. The static class <code>LazyHolder</code> is only executed when the static method <code>getInstance</code> is invoked on the class <code>Something</code>, and the first time this happens the JVM will load and initialize the <code>LazyHolder</code> class. The initialization of the <code>LazyHolder</code> class results in static variable <code>INSTANCE</code> being initialized by executing the (private) constructor for the outer class <code>Something</code>. Since the class initialization phase is guaranteed by the JLS to be sequential, i.e., non-concurrent, no further synchronization is required in the static <code>getInstance</code> method during loading and initialization. And since the initialization phase writes the static variable <code>INSTANCE</code> in a sequential operation, all subsequent concurrent invocations of the <code>getInstance</code> will return the same correctly initialized <code>INSTANCE</code> without incurring any additional synchronization overhead.

== Caveats ==
While the implementation is an efficient thread-safe "singleton" cache without synchronization overhead, and better performing than uncontended synchronization,<ref>{{cite web|title=Fastest Thread-safe Singleton in the JVM|url=http://literatejava.com/jvm/fastest-threadsafe-singleton-jvm/|work=literatejava.com}}</ref> the idiom can only be used when the construction of <code>Something</code> is guaranteed to not fail. In most JVM implementations, if construction of <code>Something</code> fails, subsequent attempts to initialize it from the same class-loader will result in a <code>NoClassDefFoundError</code> failure.

== See also ==
* [[Singleton pattern]]
* [[Double-checked locking]]
* [[Multiton pattern]]

== External links ==
* http://www.cs.umd.edu/~pugh/java/memoryModel/
* http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html
* http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

==References==
{{reflist}}

[[Category:Software design patterns]]
[[Category:Articles with example Java code]]