[Java] – Understanding Volatile and a little more about Threads

So imagine the following situation:

Two threads with the same implementation running and you want both stop running if one of them inside your logic and conditions change an existing attribute boolean to false.

Easy. Just one of the threads I set the false value in the attribute. Is not it ?

No. It will not work because the second thread will never see this attribute with the value false, it will always look for the information on your local cache and it will be marked as true and no matter what you changed in main memory to false with the other thread. Thus the second thread will be running forever.

Why it happens?

If you are working with threads you need remember all threads which you implemented will be transforms in a natives threads by JVM machine. Threads, also has a local cache. In this case, then in the second thread the boolean type attribute in your local cache is still marked as true.

How then do the thread does not get the cached value? How to thread fetch the value in main memory?

You need to tell it to the JVM. You need to disable caching of this attribute, for always the thread look the current value of it. For do this, we need define this attribute as Volatile.

public volatile boolean myValue;

Is this the best way to do it?

After the release of Java 1.5 we have a new type of object implemented in the package:


See below:


So, we can implement this as follows:

private AtomicBoolean myValue;

What is the difference between volatile and AtomicBoolean?

In fact AtomicBoolean is an abstraction of this logic which will use the volatile type attribute. See the implementation of this class below:

Screen Shot 2016-06-21 at 11.39.40 AM

Why use AtomicBoolean then?

The advantage is that this type of object allows more features and makes it clearer in time to view the code. This object has methods that can help you to perform other operations.

Is there any other alternative to solve this problem?

As we have seen this is a clear problem of synchronization, instead of using the value of main memory the thread uses the value it finds in your local cache. We can force the synchronization of these attributes defining the methods as:


In this way, we are telling the JVM synchronize attributes in this method before using the value, so then it must update the value of the attribute with the value in the main memory before using it.

In the tutorial Oracle is presented as a small example would be a class using synchronized compared with AtomInteger. It is worth checking:


Above we talked about the AtomicBoolean not need to synchronize access to a variable. The class is part of the package java.util.concurrent.atomic where we can find other classes, such as AtomicInteger and AtomicLong.

You can check the documentation of the oracle:





Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s