Home  Synchronization and concurrency  wait/notify  final  volatile  synchronized keyword  Java threading  Deadlock (and avoiding it)  Java 5: ConcurrentHashMap  Atomic variables  Explicit locks  Queues  Semaphores  CountDownLatch  CyclicBarrier

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 synchronization mechanism:

  • 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.

300X300

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 current value...
  • ...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 an update.

A field of a class that you'll instantiate a large number of times

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.

But if you're creating a large number of instances of an object containing a field that needs atomic access, using a volatile field and accessing it via an AtomicReferenceFieldUpdater (or AtomicIntegerFieldUpdater or AtomicLongFieldUpdater for primitive fields) will generally be more efficient.

Avoiding messy syntax

As discussed in our section on AtomicReferenceFieldUpdater, using a voltaile variable with a field updater as opposed to one of the atomic wrapper classes allows you to perform "normal" read and writes to the variable using regular Java syntax. The disadvantage of AtomicInteger, AtomicReference etc is that every access– even if just a single read or write– must go via one of the method calls. (On the other hand, this forces you to think about what's going on and may avoid bugs of the volatileVariable++ kind.)

Article written by Neil Coffey (@BitterCoffey).

Software

 LetterMeister (word puzzle game for iPhone)
 Currency Quoter (currency converter/predictor)
 French Vocab Games for iPhone/iPad
 Vocabularium: create Spanish vocab podcasts


Java programming articles and tutorials on this site are written by Neil Coffey (@BitterCoffey). Suggestions are always welcome if you wish to suggest topics for Java tutorials or programming articles, or if you simply have a programming question that you would like to see answered on this site. Most topics will be considered. But in particular, the site aims to provide tutorials and information on topics that aren't well covered elsewhere, or on Java performance information that is poorly described or understood. Suggestions may be made via the Javamex blog (see the site's front page for details).
Copyright © Neil Coffey 2014. All rights reserved.