Do I need volatile for variables of reference types, too?

Question

We often use volatile to ensure that a condition variable can be visible to every Thread.

I see the volatile fields are all primitive type in code so far.

Does object field has this problem? For example:

class a {

   public String str;

   public List list;

}

If there are some threads which will access str and list, must I add 'volatile'?

I guess each access to Object will get directly from Heap, and the Object will not be cached like primitive type.

Is that right?

Answer 1

You have to distinguish between the object reference and the actual object.

• For the reference your field modifier is relevant. When you change the reference to a different object (i.e. reference a different String) the change might not be noticed by a different Thread. If you want to enforce visibility you have to use final or volatile.

• The actual object on the heap is not affected by the field modifier. Instead how you see each field of this object is determined by its own field modifier according to the same rules (is it volatile or final? If not, visibility for concurrent Threads is not enforced)

So the answer is: Yes, you have to add volatile or final. Stylistically it would be much better to make the field final, though. It has the same effect Thread-wise but is a stronger statement, too: This field cannot be changed - which is the reason why it can be cached heedlessly by the JVM. And for the same reason it comes with a little performance benefit compared to volatile, Java needs not care whether the field is changes again and does not need to add overhead.