[concurrency-interest] synchronized constructors

David Holmes davidcholmes at aapt.net.au
Fri Dec 16 20:52:06 EST 2011

Zhong Yu writes:
> If the reference is unsafely published, another thread can get the
> reference early; it then calls an instance method which may obtain the
> lock before the creation thread can obtain the lock for the
> constructor. Therefore the other thread can observe the blank state.
> As Ruslan corrected me, no partial state can be observed though.

The only way this can happen, if you synchronize the whole constructor body,
is if a super class constructor does the unsafe publishing. But in that case
there is no such thing as safe-publishing because the object can escape
before the subclass constructor does any initialization.

To summarize a long and garbled thread. If the constructor body is
synchronized, there is no accessible state and all methods are synchronized,
then no external user of the class can publish a reference in a way that is
unsafe. If the constructor does the publishing within the synchronized
block, it is still safe. Only if the superclass does it can it possibly be

Also to address an other point: lock elision is allowed (eg using escape
analysis) but the memory synchronization effects must remain (you can lose
enforced mutual exclusion [as you don't need it], but not happens-before

Constructors can't be synchronized simply because back in 1995 no one
realized there could be a need for it. It can be mostly worked around by
using a synchronized block. But you can't synchronize the invocation of the
super constructor.

End of story :)


More information about the Concurrency-interest mailing list