How does volatile make my class thread-safe?

Question

I have a class

public class X {
    private volatile int value;

    public int getValue() {
        return value;
    }

    public void setValue(int value) {
        this.value = value;
    }
}

Is it thread-safe or not? I think it does not thread-safe even if I add volatile keyword.

possible duplicate : http://stackoverflow.com/q/7805192/4121347 — dryairship, Feb 11 '16 at 13:01
Why do you think it is not thread safe? What issues can you see with multiple threads calling the methods on your class? Post a scenario whereby the outcome is incorrect. — Boris the Spider, Feb 11 '16 at 13:04
I think JVM makes some optimisations and it does not guarantee the order of line invocation. — Finkelson, Feb 11 '16 at 13:06
@Finkelson and which lines could the compiler/jit rearrange in this `class` **without changing code semantics**? — Boris the Spider, Feb 11 '16 at 13:07
@Finkelson and what could it rearrange that to, again, without changing semantics? — Boris the Spider, Feb 11 '16 at 13:10

score 2 · Accepted Answer · answered Feb 11 '16 at 13:15

The thread-safety can be expressed like "if the object of the class behaves exactly in the same way in multithreaded environment as in single-threaded environment, then it is thread-safe", or maybe instead "behaves exactly as" we could say "behaves correctly".

In your case correct behavior means that after calling setValue(N), a following getValue() returns N. In case you wouldn't use the volatile modifier, this would be true only in single-threaded environment: if you call setValue(N) on Thread1 then after you call getValue() on Thread2, then it won't necessarily return N. The problem is that Thread1 and Thread2 may be executed on separate CPU cores, and CPU cores usually don't read/write directly the shared memory: the two processors can have separate CPU caches, and the setValue(N) call may modify only the CPU-cached copy of the value member, therefore this change won't be immediately visible for the RAM. Furthermore, even if N is already available in the shared memory, the getValue() may read a cached - but obsolete - value from the second processor cache. Therefore the value change you perform on Thread1 may not be immediately visible on Thread2, so getValue() may return a deprecated value.

The volatile modifier solves it with its following 2 properties:

after writing a volatile value it won't only be stored in the CPU cache, but immediately flushed into the shared RAM
reading a volatile value will always read it from the memory, never from the CPU cache.

adhg · Answer 2 · 2016-02-16T03:40:53.047

To simply answer your question: you should use volatile when the variable will be accessed by multiple threads and you don't want/need to lock it. From the example your provided the get may present a problem in terms of 'thread safe' (see answer of erosb)

As extra: the usage of volatile is limited so I would strongly suggest you to use AtomicInteger which provides you both atomicity and volatility (AtomicInteger class stores its value field in a volatile variable).

How does volatile make my class thread-safe?

2 Answers2