Question

In Java Concurrency In Practice, the following example is given to illustrate how to create an immutable class:

http://www.javaconcurrencyinpractice.com/listings/ThreeStooges.java

This class has: private final Set<String> stooges = new HashSet<String>(); which is initialized in its Constructor:

public ThreeStooges() {
    stooges.add("Moe");
    stooges.add("Larry");
    stooges.add("Curly");
}

and has a method

public boolean isStooge(String name) {
    return stooges.contains(name);
}

to see if a name is one of the three stooges.

But when I do this: ThreeStooges ts = new ThreeStooges(), is it guaranteed that the object will be properly constructed (i.e. the state of stooges correctly initialized) before its reference is set into ts?

In other words, if I publish this object, is it possible that some thread will see it as incorrectly initialized (i.e. it will see stooges as empty when accessed through isStooge())?

My understanding is that an immutable object will be properly constructed and correctly visible when it’s published – (because it uses final instance variables). Is my understanding correct? If yes, is this class still immutable?

EDIT: it seems from the comments I saw that it’s difficult to believe an object can be seen by other threads before its Constructor completes. Here’s a link on that: http://jeremymanson.blogspot.in/2008/05/double-checked-locking.html

Answer 1

A whole heap of wrong answers here 🙁

The initialization safety guarantees for final fields in the Java Memory Model are surprisingly strong. Not only do they guarantee that writes to final fields in the constructor are visible to any thread which obtains a shared reference to the object (even if that reference is obtained via a data race), but they guarantee that any writes in the constructor through that reference are visible to reads through that reference. The only caveat is that the reference to the object under construction not escape during construction. Of course, if the class were to mutate the object after construction, or offer a way for clients to get at the object reference to the HashSet, all bets are off.

The purpose of this guarantee is to prevent the need for tricky reasoning about the state of immutable (in this case, effectively immutable) objects. IF the field is final AND there are no writes to the referred-to- object’s state other than those in the constructor, you’re done.

If this makes your head hurt, don’t worry. If you (a) make the reference field private and final and (b) do not modify the state of the referred-to object outside the constructor and (c) do not provide any access that would let a client do the same (e.g., no mutative methods, no getter that exposes the field, etc), you’re done.