> A classic case where this sort of problem bit Java in the ass
I'm not sure what you mean by "bit Java in the ass". Perhaps pre-Java 5 (or pre JSR133 more accurately) the reason this was broken was poorly defined. In modern Java it's quite clear that the Java memory model implies that the double-checked-locking idiom doesn't work.
> 'm not sure if this was ever fixed / improved enough to allow the programmer to make this work.
I don't know what the value of "making it work" would be. Uncontended access to a volatile is very cheap (see http://brooker.co.za/blog/2012/09/10/volatile.html for some timings on x86), and in very performance sensitive code you'll probably not want to do lazy allocation anyways.
The well defined and well-understood memory model in modern Java is one of the real strengths of the language (and platform).
I'm not sure what you mean by "bit Java in the ass". Perhaps pre-Java 5 (or pre JSR133 more accurately) the reason this was broken was poorly defined. In modern Java it's quite clear that the Java memory model implies that the double-checked-locking idiom doesn't work.
See http://jeremymanson.blogspot.com/2008/05/double-checked-lock... and http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLo... for more information. Making the variable volatile fixes it.
> 'm not sure if this was ever fixed / improved enough to allow the programmer to make this work.
I don't know what the value of "making it work" would be. Uncontended access to a volatile is very cheap (see http://brooker.co.za/blog/2012/09/10/volatile.html for some timings on x86), and in very performance sensitive code you'll probably not want to do lazy allocation anyways.
The well defined and well-understood memory model in modern Java is one of the real strengths of the language (and platform).