Why is volatile used in double checked locking
As quoted by @irreputable, volatile is not expensive. Even if it is expensive, consistency should be given priority over performance.
There is one more clean elegant way for Lazy Singletons.
public final class Singleton {
private Singleton() {}
public static Singleton getInstance() {
return LazyHolder.INSTANCE;
}
private static class LazyHolder {
private static final Singleton INSTANCE = new Singleton();
}
}
Source article : Initialization-on-demand_holder_idiom from wikipedia
In software engineering, the Initialization on Demand Holder (design pattern) idiom is a lazy-loaded singleton. In all versions of Java, the idiom enables a safe, highly concurrent lazy initialization with good performance
Since the class does not have any static
variables to initialize, the initialization completes trivially.
The static class definition LazyHolder
within it is not initialized until the JVM determines that LazyHolder must be executed.
The static class LazyHolder
is only executed when the static method getInstance
is invoked on the class Singleton, and the first time this happens the JVM will load and initialize the LazyHolder
class.
This solution is thread-safe without requiring special language constructs (i.e. volatile
or synchronized
).
Well, there's no double-checked locking for performance. It is a broken pattern.
Leaving emotions aside, volatile
is here because without it by the time second thread passes instance == null
, first thread might not construct new Singleton()
yet: no one promises that creation of the object happens-before assignment to instance
for any thread but the one actually creating the object.
volatile
in turn establishes happens-before relation between reads and writes, and fixes the broken pattern.
If you are looking for performance, use holder inner static class instead.
A good resource for understanding why volatile
is needed comes from the JCIP book. Wikipedia has a decent explanation of that material as well.
The real problem is that Thread A
may assign a memory space for instance
before it is finished constructing instance
. Thread B
will see that assignment and try to use it. This results in Thread B
failing because it is using a partially constructed version of instance
.
Declaring the variable as volatile
guarantees that all accesses to it actually read its current value from memory.
Without volatile
, the compiler may optimize away the memory accesses to the variable (such as keeping its value in a register), so only the first use of the variable reads the actual memory location holding the variable. This is a problem if the variable is modified by another thread between the first and second access; the first thread has only a copy of the first (pre-modified) value, so the second if
statement tests a stale copy of the variable's value.