The volatile keyword in Java
It's probably fair to say that on the whole, the volatile keyword in Java is poorly documented,
poorly understood, and rarely used. To make matters worse, its formal definition actually changed
as of Java 5. On this and the following pages, we will cut through this mess and look at what the Java
volatile keyword does and when it is used. We will also compare it to other mechanisms available
in Java which perform similar functions but under subtly different other circumstances.
What is the Java volatile keyword?
Essentially, volatile is used to indicate that a variable's value will
be modified by different threads.
Declaring a volatile Java variable means:
- The value of this variable will never be cached thread-locally: all reads and writes
will go straight to "main memory";
- Access to the variable acts as though it is enclosed in a synchronized block,
synchronized on itself.
We say "acts as though" in the second point, because to the programmer at least
(and probably in most JVM implementations) there is no actual lock object involved.
Here is how synchronized and volatile compare:
Download PDF summary of this information
|Type of variable||Object||Object or primitive|
|All cached variables synchronized on access?||Yes||From Java 5 onwards|
|When synchronization happens||When you explicitly enter/exit a synchronized block||Whenever a volatile variable is accessed.|
Difference between synchronized and volatile
|Can be used to combined several operations into an atomic operation?||Yes||Pre-Java 5, no. Atomic get-set of volatiles possible in Java 5.|
In other words, the main differences between synchronized and
- a primitive variable may be declared volatile (whereas you can't
synchronize on a primitive with synchronized);
- an access to a volatile variable never has the potential to block:
we're only ever doing a simple read or write, so unlike a synchronized block we will never hold on to any lock;
- because accessing a volatile variable never holds a lock, it is not suitable
for cases where we want to read-update-write as an atomic operation
(unless we're prepared to "miss an update");
- a volatile variable that is an object reference may be null (because you're
effectively synchronizing on the reference, not the actual object).
Attempting to synchronize on a null object will throw a NullPointerException.