long/double are not atomic in Java

So I have been reading a lot of texts lately. Java Concurrency in Practice was probably one of the best book written for concurrent programming in Java. Though this book is written prior to Java 7, but it is still valid and did an excellent job explaining all the fundamentals.

While reading, I came across a paragraph entitled “Nonatomic 64-bit operations“. I actually never knew that in java 64-bit long and double values to be treated as two 32-bit values.  That means, a 64 bit write operation is basically performed as two separate 32-bit operations. This behavior can result in indeterminate values being read in code and that lacks atomicity.

According to the Java Language Specification (JSL-17.7)

For the purposes of the Java programming language memory model, a single write to a non-volatile long or double value is treated as two separate writes: one to each 32-bit half. This can result in a situation where a thread sees the first 32 bits of a 64-bit value from one write, and the second 32 bits from another write.

Writes and reads of volatile long and double values are always atomic.
Writes to and reads of references are always atomic, regardless of whether they are implemented as 32-bit or 64-bit values.
Some implementations may find it convenient to divide a single write action on a 64-bit long or double value into two write actions on adjacent 32-bit values. For efficiency’s sake, this behavior is implementation-specific; an implementation of the Java Virtual Machine is free to perform writes to long and double values atomically or in two parts.
Implementations of the Java Virtual Machine are encouraged to avoid splitting 64-bit values where possible. Programmers are encouraged to declare shared 64-bit values as volatile or synchronize their programs correctly to avoid possible complications.

So point is, in java, long and double aren’t’ thread safe. When multiple threads are going to access a long or a double value without synchronization, it can cause problems. To ensure atomic/thread safety, it is essential to use volatile to ensure changes made by one thread are visible to other threads. And that’s how we can ensure the read/write is atomic and thread safe.

However, If all reads and writes of 64-bit long and double values occur within a synchronized block, the atomicity of the read/write is guaranteed.


  • double and long in java aren’t’ thread safe.
  • Add volatile keyword before them to make sure atomic read/write, thread safety.

example –

private volatile long i = 0;


1 Comment

  1. “Volatile” != “thread safe”, even though both concepts have thread-related concerns. These phrases have specific definitions, and it’s important not to confuse them.

    Volatile is about ensuring a piece of data can’t have different/inconsistent values due to having multiple cached copies (as each thread that might access the value could have its own thread-local cached copy). Volatile ensures the value will be written to, and read from, its “real” non-cached memory location. And in the case of doubles/longs, it also guarantees that you can’t read/write those values in an inconsistent state (i.e. having only 32 of its 64 bits copied, for CPU architectures that take 2 separate steps to copy 64 bit values). Basically, volatile is only concerned with data atomicity.

    “Thread safe” has a different definition. Thread safety is about preventing multiple threads from having un-coordinated read/write access to a single piece of data. If a thread needs to perform some logic like “if (x > 0) { x– };”, notice that this single statement involves TWO separate accesses to x. For “thread safety”, you must synchronize x over this entire statement, otherwise, other threads may mutate x between the “if (x>0)” check and the “x–” mutation, which could cause x to dip below 0, which this code is clearly trying to prevent.

    “Volatile” in no way provides “thread safety”.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s