Java ' s Volatile Keyword

Turn from

Http://tutorials.jenkov.com/java-concurrency/volatile.html

The Java volatile keyword is used to mark a Java variable as "being stored in main memory". More precisely this means, that every read of a volatile variable would be is read from the computer's main memory, and not fr Om the CPU cache, and that every write to a volatile variable'll is written to main memory, and not just to the CPU Cach E.

Actually, since Java 5 the volatile keyword guarantees more than just that volatile variables is written to and read from MA In memory. I'll explain that in the following sections.

Java volatile Guarantees Variable Visibility

The Java volatile keyword guarantees visibility of changes to variables across threads. This could sound a bit abstract and so let me elaborate.

In a multithreaded application where the threads operate on Non-volatile variables, each thread could copy variables from MA In memory to a CPU cache while working to them, for performance reasons. If your computer contains more than one CPU, each thread could run on a different CPU. That's means, that's the thread may copy the variables into the CPU cache of different CPUs. This diagram illustrates such a situation:

With non-volatile variables There is no guarantees about when the Java Vsan (JVM) reads data from main memory Into the CPU caches, or writes data from the CPU caches to main memory. Let me explain, what problems, can cause with an example:

Imagine a situation in which, or more threads has access to a shared object which contains a counter variable declared Like this:

public class Sharedobject {public    int counter = 0;}

Thread 1 could read a shared  counter  variable with the value 0 to its CPU Cache, increment it to 1 and isn't write the changed value back into main memory. Thread 2 could then read the same  counter variable from main memory where the value of the variable is St Ill 0, into its own CPU cache. Thread 2 could then also increment the counter to 1, and also not write it back to main memory. Thread 1 and Thread 2 is now practically out of sync. The real value of the shared  counter  variable should had been 2, but each of the threads had the V Alue 1 for the variable in their CPU caches, and in main memory the value is still 0. It is a mess! Even if the threads eventually write their value for the shared counter  variable back to main memory, the Value would be wrong.

By declaring the shared counter variable the volatile JVM guarantees that every read the variable would always be read from M Ain memory, and that all writes to the variable would always be written back to main memory. Here's how the volatile declaration looks:

public class Sharedobject {    volatile int counter = 0;}

In some cases simply declaring a variable volatile is enough to assure that multiple threads accessing the variable SE E the latest written value. I'll get back to which cases volatile is sufficient later.

In the situation with the threads reading and writing the same variable, simply declaring the variable volatile are not Enough. Thread 1 May read the counter value 0 to a CPU register in CPU 1. At the same time, or right after, Thread 2 May read the counter value 0 to a CPU register in CPU 2. Both threads has the read the value directly from main memory. Now both variables increase the value and writes the value of back to main memory. They both increment their register version counter of to 1, and both write the value 1 back to main memory. The value should has been 2 after the increments.

The problem with multiple threads that does not see the latest value of a variable because that value have not yet been Writt En back to main memory by another thread, is called a "visibility" problem. The updates of one thread is not visible to other threads.

Since Java 5 The volatile keyword guarantees more than just the reading and writing of a variable from and to main memory.

and "visibility" problem have been solved.

Java ' s Volatile Keyword