Volatile and thread-safety

Question

In the following code,

public class Mainly {
    private Map<Integer, String> map = new HashMap<Integer, String>();
    private volatile int index = 0;

    public void set(Integer key, String value) {
        map.put(key, value);         // (1)
        index ++;                    // (2)
    }

    public String get(Integer key) {
        int i = index;               // (3)
        return map.get(key);         // (4)
    }
}

if (1) happened-before (4) ，does it mean that the get method will always read the newest value?

Answer 1

Nice question, In single threaded application you will not be able to recognize the working of volatile variable, now let's see how volatile works.

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

Imagine a situation in which two or more threads have access to a shared object which contains a counter variable declared like this:

public class SharedObject {

public int counter = 0;

}

Imagine too, that only Thread 1 increments the counter variable, but both Thread 1 and Thread 2 may read the counter variable from time to time.

If the counter variable is not declared volatile there is no guarantee about when the value of the counter variable is written from the CPU cache back to main memory. This means, that the counter variable value in the CPU cache may not be the same as in main memory.

The problem with threads not seeing the latest value of a variable because it has not yet been written back to main memory by another thread, is called a "visibility" problem. The updates of one thread are not visible to other threads.

By declaring the counter variable volatile all writes to the counter variable will be written back to main memory immediately. Also, all reads of the counter variable will be read directly from main memory. Here is how the volatile declaration of the counter variable looks:

public class SharedObject {

public volatile int counter = 0;

}

Declaring a variable volatile thus guarantees the visibility for other threads of writes to that variable.

The more detailed explanation of volatile keyword is available here : http://tutorials.jenkov.com/java-concurrency/volatile.html

Let me know if you still have some confusions with volatile.

Accept the answer by clicking the check symbol if you got my point.

Happy coding!! folk

Answer 2

It seems you're trying to make your read/write operations thread safe.

You're doing it the wrong way, first off all is your Mainly class used as a singleton ?

If yes, your set and get methods should be synchronized, for example :

public synchronized void set(Integer key, String value) {
    map.put(key, value);
    index ++;
}

public synchronized String get(Integer key) {
    int i = index;
    return map.get(key);
}

This way, if your fields are properly encapsulated, all threads will see the same value of map and index at the same time.

The use of volatile keyword is unnecessary here because a prefix/postfix increment/decrement is not atomic in Java. In your case, it is not enough to ensure synchronization.

Answer 3

I have a global Map,only one thread update it,and several threads read value in map.Can I read the newest value in the map in that way?

A ConcurrentHashMap might be what you are looking for. From the API:

Retrievals reflect the results of the most recently completed update operations holding upon their onset.

But there would still be no guarantee that an update that was initiated prior to a read will have completed. Your return might be a bit stale, but at least it would be guaranteed to have been the most recent valid value, not some mangled in-process-of-being-modified state.

In answer to the original question, no, the use of volatile on the index variable doesn't help here. Others have already given good explanations of this. Two main options are to use thread-restriction on the reads as well as the write, or use synchronization.