Cfrgtkky

Currently I can't understand when we should use volatile to declare variable.

I have do some study and searched some materials about it for a long time and know that when a field is declared volatile, the compiler and runtime are put on notice that this variable is shared and that operations on it should not be reordered with other memory operations.

However, I still can't understand in what scenario we should use it. I mean can someone provide any example code which can prove that using "volatile" brings benefit or solve problems compare to without using it?

Here is an example of why volatile is necessary. If you remove the keyword volatile, thread 1 may never terminate. (When I tested on Java 1.6 Hotspot on Linux, this was indeed the case - your results may vary as the JVM is not obliged to do any caching of variables not marked volatile.)

public class ThreadTest {

  volatile boolean running = true;



  public void test() {

    new Thread(new Runnable() {

      public void run() {

        int counter = 0;

        while (running) {

          counter++;

        }

        System.out.println("Thread 1 finished. Counted up to " + counter);

      }

    }).start();

    new Thread(new Runnable() {

      public void run() {

        // Sleep for a bit so that thread 1 has a chance to start

        try {

          Thread.sleep(100);

        } catch (InterruptedException ignored) { 

         // catch block

        }

        System.out.println("Thread 2 finishing");

        running = false;

      }

    }).start();

  }



  public static void main(String args) {

    new ThreadTest().test();

  }

}

The following is a canonical example of the necessity of volatile (in this case for the str variable. Without it, hotspot lifts the access outside the loop (while (str == null)) and run() never terminates. This will happen on most -server JVMs.

public class DelayWrite implements Runnable {

  private String str;

  void setStr(String str) {this.str = str;}



  public void run() {

    while (str == null);

    System.out.println(str);

  }



  public static void main(String args) {

    DelayWrite delay = new DelayWrite();

    new Thread(delay).start();

    Thread.sleep(1000);

    delay.setStr("Hello world!!");

  }

}

Eric, I have read your comments and one in particular strikes me

In fact, I can understand the usage of volatile on the concept
level. But for practice, I can't think
up the code which has concurrency
problems without using volatile

The obvious problem you can have are compiler reorderings, for example the more famous hoisting as mentioned by Simon Nickerson. But let's assume that there will be no reorderings, that comment can be a valid one.

Another issue that volatile resolves are with 64 bit variables (long, double). If you write to a long or a double, it is treated as two separate 32 bit stores. What can happen with a concurrent write is the high 32 of one thread gets written to high 32 bits of the register while another thread writes the low 32 bit. You can then have a long that is neither one or the other.

Also, if you look at the memory section of the JLS you will observe it to be a relaxed memory model.

That means writes may not become visible (can be sitting in a store buffer) for a while. This can lead to stale reads. Now you may say that seems unlikely, and it is, but your program is incorrect and has potential to fail.

If you have an int that you are incrementing for the lifetime of an application and you know (or at least think) the int wont overflow then you don't upgrade it to a long, but it is still possible it can. In the case of a memory visibility issue, if you think it shouldn't effect you, you should know that it still can and can cause errors in your concurrent application that are extremely difficult to identify. Correctness is the reason to use volatile.

The volatile keyword is pretty complex and you need to understand what it does and does not do well before you use it. I recommend reading this language specification section which explains it very well.

They highlight this example:

class Test {

    static volatile int i = 0, j = 0;

    static void one() { i++; j++; }

    static void two() {

        System.out.println("i=" + i + " j=" + j);

    }

}

What this means is that during one() j is never greater than i. However, another Thread running two() might print out a value of j that is much larger than i because let's say two() is running and fetches the value of i. Then one() runs 1000 times. Then the Thread running two finally gets scheduled again and picks up j which is now much larger than the value of i. I think this example perfectly demonstrates the difference between volatile and synchronized - the updates to i and j are volatile which means that the order that they happen in is consistent with the source code. However the two updates happen separately and not atomically so callers may see values that look (to that caller) to be inconsistent.

In a nutshell: Be very careful with volatile!