Synchronize to ensure that reference to immutable

Question

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 threads after the object is properly constructed.

But then at the end of the section, I read this, which simply confuses me:

Now, having said all of this, if, after a thread constructs an immutable object (that is, an object that only contains final fields), 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.

Does this means that though individual final fields (that compose an immutable object) do not have synchronization(say, visibility here) issues. But the immutable object itself when first created in a thread may not be visible (as properly created) in other threads?

If so, though we can share initialized immutable objects across threads without any thread-un-safe worries, but at the time of creation, they need 'special care' for thread safety just like for other mutables?

Answer 1

Making all the fields final will ensure they are published to other threads properly. That comment is probably referring to the following scenario:

private myField;

public void createSomething()
{
    myField = new MyImmutableClass();
}

In this case you still need proper synchronization around any access to myField, or other threads might never see the newly created object.

Answer 2

I believe author referred to the situation when immutable object is referenced by non-final field. If reference itself is final, additional synchronization is not required.
Additional consideration is that above applies only to the object fields which are initialized inside object's constructor.

Answer 3

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:

1. Start the reading thread after initialization has completed. In practice, initializing the object in the main thread prior to starting other threads accomplishes this nicely.

2. 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;
       }
   }
   

3. 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;
       }
   }
   

Answer 4

The semantics of final fields, as defined in section 17.5 of the JLS, guarantee that:

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.

In other words, it says that if a thread sees a completely initialized object, then it is guaranteed to see it's final fields correctly initialized.

However, there's no guarantee about the object being visible to a given thread. It is a different problem.

If you do not use some kind of synchronization to publish a reference of your object, then the other thread might never be able to see a reference to it.

Consider the following code:

final class A {
  private final int x;
  A(int x) { this.x = x; }
  public getX() { return x; }
}

class Main {
  static volatile A a1 = null;
  static A a2 = null;
  public static void main(String[] args) {
    new Thread(new Runnable() { void run() { try {
      while (a1 == null) Thread.sleep(50);
      System.out.println(a1.getX()); } catch (Throwable t) {}
    }}).start()
    new Thread(new Runnable() { void run() { try {
      while (a2 == null) Thread.sleep(50);
      System.out.println(a2.getX()); } catch (Throwable t) {}
    }}).start()
    a1 = new A(1); a2 = new A(1);
  }
}

Note that the a1 field is volatile. This ensures that, eventually, a write to this field will be made visible to all threads reading it some time later. The field a2 is not volatile (so, a write to this field by one thread might never get noticed by other threads).

In this code, we can be sure that thread 1 will finish executing (that is, it will see that a1 != null. However, it might happen that thread 2 will halt, as it will never see the write to the field a2, since it is not volatile.