Double Checked Locking Pattern
The Double-Checked Locking pattern used in the class loader testing example is used to lazily initialize the properties. Although there are some side notes with regard to the pattern. First and foremost, it only works for Java 1.5 and up, because of the Java memory model. Most developers shouldn't be worried with it. Quite frankly, the class loader testing example is not the most realistic example of an application for the pattern. Realistically, the best application for it is the lazy initialization of a true singleton instance, of which there are just very few.
Some might argue that applying the Double-Checked Locking pattern is harmful. Specifically because it does require a working knowledge of threading, one that too many developers lack these days. When looking at the Java ecosystem and the work that is done by many developers, many thread related issues are well hidden. Even when solving Integration problems, frameworks tend to abstract most if not all problem away. Personally, I consider the pattern to be benign in the right hands. Thus, providing a working example of what it may look like, if anything, should be educational to the inherent risks of threaded applications.
The pattern itself looks approximately as follows. We assume that there is an algorithm Q() with a predicate p() such that:
assert !p();
Q();
assert p();
It should be approximately this:
if (!p()) {
synchronized (this) {
if (!p()) {
Q();
}
}
}
assert p();