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?
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
orvolatile
.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
orfinal
? If not, visibility for concurrent Threads is not enforced)So the answer is: Yes, you have to add
volatile
orfinal
. 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 tovolatile
, Java needs not care whether the field is changes again and does not need to add overhead.You add
volatile keyword
to tell the compiler that its bound tochange
. so that all threads re-confirm that theirlocal cached copy
is same as that of original one, if there are changes it updates it. and you find it usually with Primitives because usually primitive values are incremented or decremented etc by different threads. but Object, especially List will never change since its just a reference to the Object. if you are assigning different objects to the same variable, at run-time then you may do..