volatile : Java Glossary

volatile

The volatile keyword is used on variables that may be modified simultaneously by other threads. This warns the compiler to fetch them fresh each time, rather than caching them in registers. This also inhibits certain optimisations that assume no other thread will change the values unexpectedly. Since other threads cannot see local variables, there is never any need to mark local variables volatile. You need synchronized to coordinate changes to variables from different threads, but often volatile will do just to look at them.

Just What Does volatile Guarantee?

The main thing volatile does is suppress the compiler/Hotspot from caching the value of the variable in registers. Every time its value changes, the generated code immediately flushes the value to RAM (Random Access Memory) where other threads can see it.
For references and all primitives (except sometimes long), two threads will always see a complete value, never one half-way modified by another thread. The official term for such an intact atomic value is a consistent value.
Prior to Java version 1.5, volatile did not guarantee the atomicity of a 64-bit long load or store. A second thread could view the value when only 32 bits of the new value had been stored, getting half the old value and half the new. The hardware of the day could not efficiently implement 64-bit atomicity. Starting with Java version 1.5, atomicity of volatile longs is guaranteed, on 64-bit hardware, 32-bit hardware and even hardware that requires software dodges to ensure atomicity. If the CPU (Central Processing Unit) has no hardware support for 64-bit atomicity, the JVM (Java Virtual Machine) can pull it off by redirecting an atomic 32-bit pointer to a freshly stored 64-bit value. The problem is 32-bit hardware has to store a long in two 32-bit pieces, and you can thus access a half-stored non-volatile long.
For example, the semantics of volatile are not strong enough to make the increment operation (x++) atomic, unless you can guarantee that the variable is written only from a single thread.
Java Concurrency in Practice
Atomicity of ++ on volatile variables (or non-volatile for that matter) is not guaranteed. volatile x ++ is treated as load x, add 1, store x. A second thread doing x ++ could interleave, causing x to be incremented only once.
The visibility effects of volatile variables extend beyond the value of the volatile variable itself. When thread A writes to a volatile variable and subsequently thread B reads that same variable, the values of all variables that were visible to A prior to writing to the volatile variable become visible to B after reading the volatile variable.

Learning More

What volatile does is subtle, tying into the rest of the memory model, so there isn’t a simple way to isolate it in this short explanation — but the memory model section in the JLS (Java Language Specification) explains it well. Now that you have read this overview to give you the general idea of what volatile does, you need to read the JLS to understand the fine points.

Oracle’s Miscellaneous documentation on volatile fields

Oracle’s Miscellaneous documentation on Threads and Locks

atomic
DeveloperWorks on volatile
synchronized
thread
thread safe code
transient

	You can get the freshest copy of this page from:	or possibly from your local J: drive (Java virtual drive/mindprod.com website mirror)
	http://mindprod.com/jgloss/volatile.html	J:\mindprod\jgloss\volatile.html
	Please email your feedback for publication, letters to the editor, errors, omissions, typos, formatting errors, ambiguities, unclear wording, broken/redirected link reports, suggestions to improve this page or comments to Roedy Green : . If you want your message, your name or email kept confidential, not considered for public posting, please explicitly specify that. Unless you state otherwise, I will treat your message as a letter to the editor that I may or may not publish in the feedback section. After that, it will be too late to retract it. If you disagree with something I said, please quote it and cite the web page where you found it, tell me why you think it is wrong, and, if possible, provide some supporting evidence. Threatening to kill me or spouting obscenities has yet to persuade me to change my mind.
	Canadian Mind Products
	mindprod.com IP:[65.110.21.43]
view Blog	Your face IP:[38.107.179.212]
Feedback	You are visitor number 255,866.