Use of Volatile keyword

[ragi singh]

hi ,

Can anyone explain the volatile keyword and it's use (in real life).

[Hebert Coelho]

Hello ragi.

I never seen volatile in use, but i found this link. It might help you.

http://www.javamex.com/tutorials/synchronization_volatile.shtml

[Shanky Sohar]

See below code.

Volatile means each Thread Access the variable will have its own private copy which is same as original one.
But if the Thread is going to change that private copy,then original one will not get reflected.

see below code.

public class Test1 {
   volatile int i=0,j=0;
   public void add1()
           {
	        i++;
	        j++;
	  }
   public void printing(){
	   System.out.println("i=="+i+ "j=="+j);
   }

	public static void main(String[] args) {
		Test1 t1=new Test1();
		Test1 t2=new Test1();
		t1.add1();//for t1 ,i=1,j=1
		t2.printing();//for t2 value of i and j is still,i=0,j=0
		t1.printing();//prints the value of i and j for t1,i.e i=1,j=1
		t2.add1();////for t2 value of i and j is changed to i=1;j=1
		t2.printing();//prints the value of i and j for t2i=1;j=1
	}

}

[Shanky Sohar]

same thing can be achieved through synchronization also

[Dieter Quickfend]

That's not correct, IIRC. Volatile means the variable's value will never be cached thread-locally, but all reads and writes will go straight to main-memory, and the variable acts as though it is synchronized on its reference (though it isn't really, it cannot block and it can be null). What it does mean is, for example, when you start setting an integer using the actual variable, and just while you're setting that variable, some other thread tries to set that variable to another value, your operation will run first, it is atomic. If it hadn't been volatile, something could sneak in.

Basically, getting it is atomic, setting it is atomic. They are each atomic, but not together; however, there is a way to do that since Java 5.

an example of volatile in regards to caching:

 
public class StoppableTask extends Thread {
  private volatile boolean pleaseStop;

  public void run() {
    while (!pleaseStop) {
      // do some stuff...
    }
  }

  public void tellMeToStop() {
    pleaseStop = true;
  }
}
   

If the variable were not declared volatile (and without other synchronization), then it would be legal for the thread running the loop to cache the value of the variable at the start of the loop and never read it again. If you don't like infinite loops, this is undesirable.

* volatile is not necessary– or in fact possible– for fields that are immutable (declared final);
* volatile is not necessary for variables that are accessed by only one thread (though of course you have to make a correct decision that they are only accessed by one thread!);
* volatile is not suitable for complex operations where you need to prevent access to a variable for the duration of the operation: in such cases, you should use object synchronization or one of Java 5's explicit lock classes added.

When should you use volatile? For instance variables that are constantly changed by more than one thread.

source: http://www.javamex.com/tutorials/synchronization_volatile.shtml

[Shanky Sohar]

The explaination provide by me is after studying through JLS Third Edition.

[Dieter Quickfend]

JLS Third Edition states: http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.3.1.4

Which is quite different from what you said, I think.

Also, in your example, a volatile variable would not be necessary, because there is only one thread running, so there will be no concurrent access.

[Shanky Sohar]

Thanks Dieter Quickfend for clearing it.now i understand that

[Shanky Sohar]

below link is also useful
Volatile keyword

[Vinoth Kumar Kannan]

Keep in mind - volatile is not an equivalent to synchronized! Synchronized uses locks & is capable of blocking a thread, but volatile does not have the ability to block - so you are not really thread-safe when you use it. As Dieter said, it just writes/reads from the main memory rather than the cached copy. Simple.
You can use volatile on even primitives, but synchronized cannot be.

[Vinoth Kumar Kannan]

Vinoth Kumar Kannan wrote:...you are not really thread-safe when you use it...

Sorry about that info guys...I was wrong!
I took a bit deeper dive into volatile/synchronization and here is what I got..
Only in the Old JMM(Java Memory Model) reads/writes of volatile variables were allowed to be reordered with other non-volatile reads/writes - so not much reliable, but with the new JMM each read/write to a volatile field is like "half" a synchronization -- a read of a volatile has the same memory semantics as a monitor acquire, and a write of a volatile has the same semantics as a monitor release.

As a result of making volatile more "heavyweight," the performance cost of using volatile has been brought closer to the performance cost of synchronization in some cases, but the performance cost is still quite low on most platforms.

source=http://www.ibm.com/developerworks/library/j-jtp03304/

[Jaikiran Pai]

This has been discussed many times before. Here are some of those discussions:

https://coderanch.com/t/385237/java/java/Volatile-Modifiers#1682610
https://coderanch.com/t/497771/java/java/volatile-variables

[Vinoth Kumar Kannan]

Thanks, Jaikiran Pai.
Actually, I said something I wasn't really sure of. Mine seemed to be the last post(no one opposing/correcting thereafter..), and when I read more on volatile & synchronization, I realized I was wrong and did a small update, so that folks in future who see this wrong post should not take it as something right - that being my intention actually.

[Jaikiran Pai]

Vinoth Kumar Kannan wrote:
Actually, I said something I wasn't really sure of. Mine seemed to be the last post(no one opposing/correcting thereafter..), and when I read more on volatile & synchronization, I realized I was wrong and did a small update, so that folks in future who see this wrong post should not take it as something right - that being my intention actually.

No problem