Home  Synchronization and concurrency  ConcurrentHashMap  Atomic variables

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. Declaring a variable as volatile 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. Unlike synchronized blocks:

• 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;
• a volatile variable that is an object reference may be null (because you're effectively synchronizing on the reference, not the actual object).

As of Java 5, volatile variables have an additional property: thread-local copies of variables are also synchronized with main memory when the variable is accessed, as would be the case when entering and leaving a synchronized block. In other words, they pretty much do have the semantics of a synchronized block, although the lack of an actual lock object means they're generally a more "lightweight" operation. Some authors have described volatile as a "means of avoiding synchronization"¹. But if you include memory synchronization, then as of Java 5 this definition isn't quite true.

The volatile property is most often used to implement a "stop request" flag allowing one thread to signal to another to finish:

public class StoppableTask extends Thread {
  private volatile boolean pleaseStop;

  public void run() {
    while (!pleaseStop) {
      // do some stuff...
    }
  }

  public void tellMeToStop() {
    pleaseStop = true;
  }
}

If the variable were not declared volatile (and without other synchronization), then it would be legal for the thread running the loop to cache the value of the variable at the start of the loop and never read it again. If you don't like infinite loops, this is undesirable.

A danger of volatile variables is that they can misleadingly make a non-atomic operation look atomic. For example:

volatile int i;
...
i += 5;

Although it may look it, the operation i += 5 is not atomic. It is more the equivalent to:

// Note that we can't literally synchronize on an int primitive!
int temp;
synchronized (i) {
  temp = i;
}
temp += 5;
synchronized (i) {
  i = temp;
}

So another thread could sneak in the middle of the overall operation of i += 5.

When should I use the volatile keyword?

The glib answer is generally "very rarely". The boolean flag for telling a thread to stop, as exemplified above, is probably the most typical use. In general, volatile variables may be useful where:

• On each access, you are only reading or writing a single variable (such as the "stop thread" flag.) If, as an atomic operation, you need to refer to more than one variable, then volatile variables generally won't do. (An exception to this is that from Java 5 onwards the synchronization piggybacking technique works with volatile variables: "on the back of" access to a volatile variable, you can assume that the local copy of another, non-synchronized, variable will have been synchronized with main memory, provided there is no other way to access that variable.)
• You have an access pattern where you read-update-save (such as incrementing an integer) but you don't care if occasionally the update is overridden by another concurrent update. For example, if you're counting the number of accesses to a web page or counting the number of times a database connection has been used, you probably don't care if you miss the occasional increment. (Conversely, if you do care, then a volatile variable is not as suitable choice.)

On the next page, we continue our discussion by looking at relying on the synchronization in the class loader.

Notes:
1. Cf the description in Chapter 5 of Oaks, S. & Wong, H. (2004), Java Threads, 3rd ed.