@swhittaker is right. See in his first link, the authors of the declaration (Joshua Bloch, Doug Lea...). They're recognized by the Java community as Gurus, and they tell us the double check pattern is dangerous. Delete the page or put it in a new section called "antipatterns".

Thanks for pointing this out. The articles seem credible and we should follow their advice. This affects Double Checked Locking pattern and one example of Singleton.

We don't have antipatterns section so the correct action would be to delete those examples. I will accept PR that does it.

I think it would be a shame to simply remove the examples. As it is a known pattern, and now established anti-pattern, I think it still belongs here, preserved in a new anti-pattern section as suggested by @pbougrier, with an explanation as to why it is not recommended for use.

At the least, a Consequences header could be added to the pattern description (as done in singleton) with the reasons to not use it included, along with an explanation of the circumstances under which the pattern is valid.

Yes, I guess we could do that (explain it should not be used) and add antipattern tag to http://java-design-patterns.com/patterns/ page.

Guys, did you read the articles to the end? The Double Checked Locking was considered to be broken before JMM of java 1.5. In 1.5 they changed the semantics of volatile. If you make your "singleton" (or whatever you are double-checking) volatile it works fine.
I would suggest updating the description with notes on using volatile and required version of java.
I could do that, if you don't mind.

@Auffahrend please note that the links also state that unless all the fields in the resource being protected are themselves immutable (final) then those fields also need to be declared volatile.

To my mind, even if this works, having this restriction imposed on the fields of a class just to provide lazy loading when constructing it is untenable as it introduces maintenance and performance implications to that class for little gain.

This isn't a case of "if we can" and more a case of "if we should".

@swhittaker well, in case of "if we should" clearly describing pros and cons and requirements of pattern's implementation becomes even more important.
Also please note, that is not just lazy loading when this pattern is usable. We use it in cache engine of web service, double checking presence of a cached value. It prevents concurrent web requests of duplicating DB requests or perform duplicate calculations.

Ok, so with a bit more research I've found this stackoverflow post where the accepted answer has an example for how to safely use DCL when in use for lazy loading. It seems like this may no longer be an anti-pattern (but the way in which it is often incorrectly implemented is and is worth a mention).

The entry should be updated to note that there are better alternatives to DCL when working with a static resource, and to include the previously mentioned points around final fields / volatile fields.

This is a good resource with multiple working and non-working examples of initialisation including DCL.

However this is all to do with constructing an object, I've not seen a safe example of DCL where the value can be changed again after being set the first time (as in caching).