Page History

...

If a thread accesses helper using the getHelper() method before the initialize() method has been called, the thread will observe an uninitialized helper field. Later, if one thread calls initialize(), and another calls getHelper(), the second thread might could observe one of the following:

• the helper reference as null
• a fully-initialized Helper object with the n field set to 42
• a partially-initialized Helper object with an uninitialized n, which contains the default value 0

In particular, the JMM permits compilers to allocate memory for the new Helper object and assign it to the helper field before initializing it. In other words, the compiler can reorder the write to the helper instance field with the write that initializes the Helper object (that is, this.n = n) such so that the former occurs first. This exposes a race window during which other threads may observe a partially-initialized Helper object instance.

...

A read of a final field of an object within the thread that constructs that object is ordered with respect to the initialization of that field within the constructor by the usual happens-before rules. If the read occurs after the field is set in the constructor, it sees the value the final field is assigned; otherwise, otherwise it sees the default value.

Consequently, the reference to the helper instance should not be published before the Foo class's constructor has finished its initialization. (see See guideline TSM01-J. Do not let the (this) reference escape during object construction.).

Compliant Solution (Final Field and Thread-safe Composition)

...

The helper field is declared final to guarantee that the vector is created before any accesses take place. It can be initialized safely by invoking the synchronized initialize() method, which ensures that only one Helper object is ever added to the vector. If getHelper() is invoked before initialize(), it calls initialize() to avoid the possibility of a null-pointer de-reference by the client. The getHelper() method does not require synchronization to simply return Helper, and—because and, because the synchronized initialize() method also checks to make sure helper is empty before adding a new Helper object—there object, there is no possibility of exploiting a race condition to add a second object to the vector.

...

According to JSR-133, Section 9.2.3, "Static Final Fields"  \[[JSR-133 2004|AA. Bibliography#JSR-133 04]\]:

The rules for class initialization ensure that any thread that reads a static field will be synchronized with the static initialization of that class, which is the only place where static final fields can be set. Thus, no special rules in the JMM are needed for static final fields.

...

This compliant solution requires that helper be declared volatile and class Helper be immutable. If it were not immutable, the code would violate guideline VNA06-J. Do not assume that declaring an object reference volatile guarantees visibility of its members, and additional synchronization would be necessary. (see See the next compliant solution.) . And, if the helper field were non-volatile, it would violate guideline VNA01-J. Ensure visibility of shared references to immutable objects.

...

Because the Helper object can change state after its construction, synchronization is necessary to ensure the visibility of mutable members after initial publication. Consequently, the setN() method is synchronized to provide the visibility of the n field in this compliant solution. (see See guideline VNA06-J. Do not assume that declaring an object reference volatile guarantees visibility of its members.).

If the Helper class is not synchronized properly, declaring helper volatile in the Foo class only guarantees the visibility of the initial publication of Helper and not of subsequent state changes. Consequently, volatile references alone are inadequate for publishing objects that are not thread-safe.

...

TSM03-EX1: Classes that prevent partially initialized objects from being used may publish partially initialized objects. This may be implemented, for example, by setting a volatile boolean flag in the last statement of the initializing code and ensuring this flag was is set before allowing class methods to execute.

...

This technique ensures that, even if the reference to the Helper object instance is published before its initialization is over, the instance is unusable. The instance is unusable because every method within Helper must check the flag to determine whether the initialization has finished.

...