Making operations on volatile fields atomic


The expected behaviour for volatile fields is that they should behave in a multi-threaded application the same as they do in a single threaded application.  They are not forbidden to behave the same way, but they are not guaranteed to behave the same way.

The solution in Java 5.0+ is to use AtomicXxxx classes however these are relatively inefficient in terms of memory (they add a header and padding), performance (they add a references and little control over their relative positions), and syntactically they are not as clear to use.

IMHO A simple solution if for volatile fields to act as they might be expected to do, the way JVM must support in AtomicFields which is not forbidden in the current JMM (Java- Memory Model) but not guaranteed.

Why make fields volatile?

The benefit of volatile fields is that they are visible across threads and some optimisations which avoid re-reading them are disabled so you always check again the current value even if you didn’t change them.

e.g. without volatile

 Thread 2:  int a = 5;

Thread 1:  a = 6;


Thread 2: System.out.println(a); // prints 5 or 6

With volatile

 Thread 2:  volatile int a = 5;

Thread 1: a = 6;


Thread 2: System.out.println(a); // prints 6 given enough time.

Why not use volatile all the time?

Volatile read and write access is substantially slower.  When you write to a volatile field it stalls the entire CPU pipeline to ensure the data has been written to cache.  Without this, there is a risk the next read of the value sees an old value, even in the same thread (See AtomicLong.lazySet() which avoids stalling the pipeline)

The penalty can be in the order of 10x slower which you don’t want to be doing on every access.

What are the limitations of volatile?

A significant limitation is that operations on the field is not atomic, even when you might think it is.  Even worse than that is that usually, there is no difference.  I.e. it can appear to work for a long time even years and suddenly/randomly break due to an incidental change such as the version of Java used, or even where the object is loaded into memory. e.g. which programs you loaded before running the program.

e.g. updating a value

Thread 2:  volatile int a = 5;

Thread 1:  a += 1;
Thread 2:  a += 2;


Thread 2: System.out.println(a); // prints 6, 7 or 8 even given enough time.

This is an issue because the read of a and the write of a are done separately and you can get a race condition. 99%+ of the time it will behave as expect, but sometimes it won’t.

What can you do about it?

You need to use AtomicXxxx classes. These wrap volatile fields with operations which behave as expected.

Thread 2:  AtomicInteger a = new AtomicInteger(5);

Thread 1:  a.incrementAndGet();
Thread 2:  a.addAndGet(2);


Thread 2: System.out.println(a); // prints 8 given enough time.

What do I propose?

The JVM has a means to behave as expected,  the only surprising thing is you need to use a special class to do what the JMM won’t guarantee for you.  What I propose is that the JMM be changed to support the behaviour currently provided by the concurrency AtomicClasses.

In each case the single threaded behaviour is unchanged. A multi-threaded program which does not see a race condition will behave the same. The difference is that a multi-threaded program does not have to see a race condition but changing the underlying behaviour.

current methodsuggested syntaxnotes
x.getAndIncrement()x++ or x += 1
x.getAndDecrment()x– or x -= 1
x.addAndGet(y)(x += y)
x.getAndAdd(y)((x += y)-y)
x.compareAndSet(e, y)(x == e ? x = y, true : false)Need to add the comma syntax
used in other languages.

These operations could be supported for all the primitive types such as boolean, byte, short, int, long, float and double.

Additional assignment operators could be supported such as:

current methodsuggested syntaxnotes
Atomic multiplicationx *= 2;
Atomic subtractionx -= y;
Atomic divisionx /= y;
Atomic modulusx %= y;
Atomic shiftx <<= y;
Atomic shiftx >>= z;
Atomic shiftx >>>= w;
Atomic andx &= ~y;clears bits
Atomic orx |= z;sets bits
Atomic xorx ^= w;flips bits


What is the risk?

This could break code which relies on these operations occasionally failing due to race conditions.

It might not be possible to support more complex expressions in a thread safe manner.  This could lead to surprising bugs as the code can look like the works, but it doesn’t.  Never the less it will be no worse than the current state.

JEP 193 – Enhanced Volatiles

There is a JEP 193 to add this functionality to Java. An example is:

class Usage {
    volatile int count;
    int incrementCount() {
        return count.volatile.incrementAndGet();

IMHO there is a few limitations in this approach.

  • The syntax is fairly significant change.  Changing the JMM might not require many changes the the Java syntax and possibly no changes to the compiler.
  • It is a less general solution.  It can be useful to support operations like volume += quantity; where these are double types.
  • It places more burden on the developer to understand why he/she should use this instead of x++;

I am not convinced that a more cumbersome syntax makes it clearer as to what is happening. Consider this example:

 volatile int a, b;

a += b;




AtomicInteger a, b;


Which of these operations, as a line are atomic. Answer none of them, however systems with Intel TSX can make these atomic and if you are going to change the behaviour of any of these lines of code I would make the the a += b;  rather than invent a new syntax which does the same thing most of the time, but one is guaranteed and not the other.


Much of the syntactic and performance overhead of using AtomicInteger and AtomicLong could be removed if the JMM guaranteed the equivalent single threaded operations behaved as expected for multi-threaded code.

This feature could be added to earlier versions of Java by using byte code instrumentation.

Reference: Making operations on volatile fields atomic from our JCG partner Peter Lawrey at the Vanilla Java blog.
Related Whitepaper:

Bulletproof Java Code: A Practical Strategy for Developing Functional, Reliable, and Secure Java Code

Use Java? If you do, you know that Java software can be used to drive application logic of Web services or Web applications. Perhaps you use it for desktop applications? Or, embedded devices? Whatever your use of Java code, functional errors are the enemy!

To combat this enemy, your team might already perform functional testing. Even so, you're taking significant risks if you have not yet implemented a comprehensive team-wide quality management strategy. Such a strategy alleviates reliability, security, and performance problems to ensure that your code is free of functionality errors.Read this article to learn about this simple four-step strategy that is proven to make Java code more reliable, more secure, and easier to maintain.

Get it Now!  

Leave a Reply

six − = 3

Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books