I am learning about the volatile but got confused with the synchronized blocks. I think that we can achieve the same results with the use of synchronized if we don't use volatile. Please correct me if I am wrong.
Why do we need volatile if same thing can be achieved using synchronized blocks/methods? Is there any such special scenario where synchronized block/method is insufficent?
First, obtaining a mutually exclusive lock is not cheap. Given enough threads, and given enough coordination between the threads, it actually starts to be noticeable. Or from a famous quote, "a billion here, a billion there, pretty soon, you're talking real money"...
So, if all you need is to coordinate a single value, via a setter and getter, why should you need to grab a mutually exclusive lock for that?
Second, Java also provides the tools to do lock-free algorithms. Of course, for the most part, with lock free algorithms, the coordination tend to be done via "optimistic locking", meaning no lock is used, but a mechanism is provided to undo any collision that may happen.
Anyway, if you are interesting in implementing such an algorithm, take a look at the atomic classes. They may look simple, but they are the building blocks to achieve really complex lock free code. And of course, under the covers, they depend on volatile variables.
So, can we achieve the same thing using synchronized instead of volatile? Using volatile is a performance improvement technique over synchronized blocks?
Regarding volatiles, I read that if one thread reads & writes and all other threads only read, then it will work fine but in case more than one thread write a volatile variable, then it may lead to race conditions. Is that true? If yes, then can't we have race conditions if two threads read the volatile at same time and then first thread writes new value to memory; in that case, won't the 2nd thread be dealing with stale value?
Vaibhav Gargs wrote:. . . Using volatile is a performance improvement technique over synchronized blocks? . . .
Don't think about performance; think about the quality of the code. If you can maintain good code simply with volatile, all well and good, but as you suggest volatile on its cannot cannot always sort out race conditions.