Question

Goetz’s Java Concurrency in Practice, page 41, mentions how this reference can escape during construction. A “don’t do this” example:

public class ThisEscape {
    public ThisEscape(EventSource source) {
        source.registerListener(
            new EventListener() {
                public void onEvent(Event e) {
                    doSomething(e);
                }
            });
    }
}

Here this is “escaping” via the fact that doSomething(e) refers to the enclosing ThisEscape instance. The situation can be fixed by using static factory methods (first construct the plain object, then register the listener) instead of public constructors (doing all the work). The book goes on:

Publishing an object from within its constructor can publish an incompletely constructed object. This is true even if the publication is the last statement in the constructor. If the this reference escapes during construction, the object is considered not properly constructed.

I don’t quite get this. If the publication is the last statement in the constructor, hasn’t all the constructing work been done before that? How come is this not valid by then? Apparently there’s some voodoo going on after that, but what?

Answer 1

The end of a constructor is a special place in terms of concurrency, with respect to final fields. From section 17.5 of the Java Language Specification:

An object is considered to be
completely initialized when its
constructor finishes. A thread that
can only see a reference to an object
after that object has been completely
initialized is guaranteed to see the
correctly initialized values for that
object’s final fields.

The usage model for final fields is a
simple one. Set the final fields for
an object in that object’s
constructor. Do not write a reference
to the object being constructed in a
place where another thread can see it
before the object’s constructor is
finished. If this is followed, then
when the object is seen by another
thread, that thread will always see
the correctly constructed version of
that object’s final fields. It will
also see versions of any object or
array referenced by those final fields
that are at least as up-to-date as the
final fields are.

In other words, your listener could end up seeing final fields with their default values if it examines the object in another thread. This wouldn’t happen if listener registration happened after the constructor has completed.

In terms of what’s going on, I suspect there’s an implicit memory barrier at the very end of a constructor, making sure that all threads “see” the new data; without that memory barrier having been applied, there could be problems.