Scala's lazy val uses the double-checked locking pattern with the field declared volatile, (the private field thing in the example) that's why there is no issue
It doesn't matter if the field is volatile, it won't protect you in this case.
Basically when assigning a new object to a reference, the only way to know for sure that its internals are initialized before the assignment is to either work with finals or to synchronize that internal state.
if the field is volatile, you have an happen before relationship between the volatile read of thing before the synchronized block and the volatile write inside the synchronized block, so you have no way to see the object partially initialized.
It only works with the updated semantics of volatile (Java 5+), otherwise you're right.
