When to use volatile?
On the previous pages, we've looked at the definition of volatile
and seen some of the additional atomic access to volatile variables
provided by Java 5. We've also seen that volatile variables share some features (in particular the
memory synchronization behaviour) of synchronized access to an object.
So when should you use volatile?
First, the easy cases where you basically don't need volatile or any other
- volatile is not necessary– or in fact possible–
for fields that are immutable (declared final);
- volatile is not necessary for variables that are accessed
by only one thread (though of course you have to make a correct
decision that they are only accessed by one thread!);
- volatile is not suitable for complex operations
where you need to prevent access to a variable for the duration of the operation:
in such cases, you should use object synchronization
or one of Java 5's explicit lock classes added.
Now some typical uses.
A "simple flag" accessed by multiple threads
The most typical case is where:
- you write a variable, such as a flag, in one thread;
- you check that variable in another thread;
- crucially, the value to write doesn't depend on the
- ...or, you don't care about "missing an update".
We looked at the example of a volatile flag to control a loop.
The last point above outlaws cases such as x++ or x += 7,
because this actually involves
reading the current value, incrementing it, then setting the new value. A common bug with volatile is to assume that x++ is atomic.
For cases where you need this functionality, consider AtomicInteger
or related classes.
Now, under some circumstances, you could make the decision to perform
concurrent x++ operations anyway and "take the risk" that occasionally you'll miss
In general, where you need atomic access to a "one-off" variable or one created
a fairly small number of times, then the Java 5 atomic classes
(primarily AtomicInteger) are your answer.