CODEWITHSUNDEEP
javathread-safety
Bogdan Balan
Bogdan Balan

Reputation: 6701

Is it necessary to declare an AtomicReference as volatile?

The same for all other atomic objects? It's easier to explain the question for an AtomicInteger. Since more then 1 thread are accessing the reference to myInt, isn't it possible that one thread sees the registered cached value, for example null, for this object, unless it is also declared volatile? If not how come?

Upvotes: 7

Views: 1784

Answers (2)

Enno Shioji
Enno Shioji

Reputation: 26882

The "atomic" objects are not immutable, so they should be thread safe only if they are published properly. For example, when you do something like this, you will need to use the volatile keyword.

volatile AtomicInteger counter = // initialize counter

int harvest(){
    AtomicInteger old = counter;
    counter = new AtomicInteger();
    return old.get();
}

If you remove the volatile from the above code, you could indeed lose some increments. According to the spec, you might also get a reference to an AtomicInteger object that is not fully constructed, and thus get undefined behavior.

So, do you need to declare your atomic object as volatile? The answer is it depends. They are only thread safe as long as they are published properly, as any other thread safe objects are (except immutable objects, which are special case). In most cases, you should make them final.

Upvotes: 3

skaffman
skaffman

Reputation: 403471

Not only is it not necessary, it's actually semantically wrong. AtomicReference holds the "real" reference within itself, and manages access to it using its own synchronization constructs. The JVM's own synchronization constructs (synchronized, volatile, etc) and not used. The AtomicReference object itself should not be treated as volatile. If anything, consider making it final.

Also consider this question - volatile can be considered to be an alternative to using AtomicReference, if all you need is get and set operations.

Upvotes: 11

Related Questions