I was studying this to understand the behavior of final fields in the new JMM (5 onwards). This concept is clear: guaranteed visibility of initialized final fields to all t
you want to ensure that it is seen correctly by all of the other thread, you still typically need to use synchronization. There is no other way to ensure, for example, that the reference to the immutable object will be seen by the second thread.
I would be slightly leery of a text that turns typically into no other way in the space of a sentence. In fact, which is true depends on what exactly we mean by "use synchronization".
The relevant parts of the Java Language Specification are:
Two actions can be ordered by a happens-before relationship. If one action happens-before another, then the first is visible to and ordered before the second.
and
More specifically, if two actions share a happens-before relationship, they do not necessarily have to appear to have happened in that order to any code with which they do not share a happens-before relationship. Writes in one thread that are in a data race with reads in another thread may, for example, appear to occur out of order to those reads.
Happens-before can be established in a number of ways:
If we have two actions x and y, we write hb(x, y) to indicate that x happens-before y.
- If x and y are actions of the same thread and x comes before y in program order, then hb(x, y).
- There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (§12.6) for that object.
- If an action x synchronizes-with a following action y, then we also have hb(x, y).
- If hb(x, y) and hb(y, z), then hb(x, z).
where
Synchronization actions induce the synchronized-with relation on actions, defined as follows:
- An unlock action on monitor m synchronizes-with all subsequent lock actions on m (where subsequent is defined according to the synchronization order).
- A write to a volatile variable (§8.3.1.4) v synchronizes-with all subsequent reads of v by any thread (where subsequent is defined according to the synchronization order).
- An action that starts a thread synchronizes-with the first action in the thread it starts.
- The write of the default value (zero, false or null) to each variable synchronizes-with the first action in every thread. Although it may seem a little strange to write a default value to a variable before the object containing the variable is allocated, conceptually every object is created at the start of the program with its default initialized values.
- The final action in a thread T1 synchronizes-with any action in another thread T2 that detects that T1 has terminated. T2 may accomplish this by calling T1.isAlive() or T1.join().
- If thread T1 interrupts thread T2, the interrupt by T1 synchronizes-with any point where any other thread (including T2) determines that T2 has been interrupted (by having an InterruptedException thrown or by invoking Thread.interrupted or Thread.isInterrupted).
By making the fields final, you ensure their assignment happens-before the completion of the constructor. What you still need to ensure is that the completion of the constructor happens-before the object is accessed. If that access occurs in a different thread, you need to establish synchronizes-with, using any of the 6 ways shown above. Typically used are:
Declare the field that other threads use to access the object volatile. For instance:
class CacheHolder {
private static volatile Cache cache;
public static Cache instance() {
if (cache == null) {
// note that several threads may get here at the same time,
// in which case several caches will be constructed.
cache = new Cache();
}
return cache;
}
}
Do both the initial assignment and the reading of the field in a synchronized block.
class CacheHolder {
private static Cache cache;
public synchronized static Cache instance() {
if (cache == null) {
cache = new Cache();
}
return cache;
}
}