I read in Java Concurrency in Practice that ....

[Michael Farragher]

"Safe publication is sufficient for other threads to safely access objects that are not going to be modified after publication without additional synchronization.
The safe publication mechanisms all guarantee that the as-published state of an object is visible to all accessing threads as soon as the reference to it is visible,
and if that state is not going to be changed again, this is sufficient to ensure that any access is safe"

So if I've got

   class A{
      private int i;

   public A(int i){
      this.i = i;
   }

   public final int getI(){
      return i;
   }
}

One of the ways of safely publishing an instance of A is to store a volatile reference to it.

So if I've got

class B{
   private volatile A a;

   public B(){
      a = new A(3);
   }

   public void accessI(){
      int  i = a.getI();
   }
}

Is class B thread-safe ?

[Stephan van Hulst]

Yes, a second thread that calls accessI() will always see the value 3.

[Campbell Ritchie]

Aren't both those classes sort of immutable if you don't subclass them?

[Stephan van Hulst]

That's the point of the example Campbell. The class is thread-safe because it is immutable and published safely. If the 'a' field was not declared volatile (and also not final), B would NOT be thread-safe, even if it is immutable.

[Michael Farragher]

I guess class B could be rewritten as

class B{
   private A a;

   public A(){
      synchronized(this){
         a = new A(3);
      }
   }
   
   public void accessI(){
      synchronized(this){
         int i = a.getI();
      }
   }
}

??

[Stephan van Hulst]

Yes it could, but this would incur unnecessary overhead. The synchronized keyword is a heavier tool than the volatile keyword. Besides, you don't need to use the synchronized keyword in the constructor at all if you synchronize access to a in the accessI() method.

[Stephan van Hulst]

I know this is not the point of your question, but as a final (hehe) remark I want to say that if you have an immutable class, you NEVER have to use volatile or synchronized, because you can use final instead and it will make your code faster as well.

[Campbell Ritchie]

Is that your final word, Stephan?
When I started learning Java® I found it hard to understand that there were two separate keywords final and finally.

[Michael Farragher]

One thing that puzzles me in JCIP is when it talks about immutable objects. It says that immutable objects are immune to improper publication.

It gives this example :

public class Holder{
   private int n;

   public Holder(int n){
      this.n = n;
   }

   public void assertSanity(){
      if(n != n)
         throw new AssertionError("This statement is false")
   }
}

In another class, you've got

   public Holder holder;

   public void initialize(){
      holder = new Holder(42);
   }

It says this is publishing an object without adequate synchronization. But it says that making n in Holder final would make the class immutable and would then be immune to improper publication. But you'd still need to make the holder ref volatile - or employ anothre synchonization mechanism - so that reading threads would see the right object ?!!? In other words you'd need to publish it properly. Can someone resolve my confusion ?! Thanks

[Stephan van Hulst]

The example given by JCIP is not about the safe publication of the reference to the Holder object, but rather the Holder object itself.

A class that is immutable can not guarantee anything about references to its objects, that's the responsibility of the classes that use the immutable class.

The assertSanity() method makes an assertion about n, not about holder.