> 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 acc

> 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. See http://jeremymanson.blogspot.com/2008/05/double-checked-locking.html http://jeremymanson.blogspot.com/2008/05/double-checked-lock... and http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html 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 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).