Thread-safe setting of a variable (Java)?

Question

Given the following code:

public class FooBar { 

  public static volatile ConcurrentHashMap myConfigData  = new ConcurrentHashMap();      

}

public class          


        

Answer 1

You could alway use AtomicReference if you feel unsure.

Although I think in your case volatile schould be enough.

Answer 2

If by update you mean overwrite an entry inside the ConcurrentHashMap:

FooBar.myConfigData.put(somekey, somevalue);

Then it is definitely thread safe, as duffymo said.

If you want to overwrite the myConfigData variable with a new value:

FooBar.myConfigData = new ConcurrentHashMap();

It is also thread-safe, as you have correctly labelled the variable as volatile. The volatile keyword means that multiple threads can access the same variable safely and atomically.

EDIT: The Question is not wether ConcurrentHashMap is threadsafe (it is according to javadoc) but rather the Setting of the ConcurrentHashMap itself in the myConfigData Member variable. This variable might be read and written "at once" by several threads so the question is, if the setting is atomic or not. I think this can be generalized, is the Setting of a Java Reference variable atomic or not.

(I also made it volatile. This is a different issue and has nothing to do with atomicity (my question) but rather "visibility in other threads" and the happens before relationship).

Actually 'volatile' is for atomicity, nothing affects visibility, a public variable will always be visible to any thread.

Answer 3

Replacing references is safe. See Java language Specification:

When a thread uses the value of a variable, the value it obtains is in fact a value stored into the variable by that thread or by some other thread. This is true even if the program does not contain code for proper synchronization. For example, if two threads store references to different objects into the same reference value, the variable will subsequently contain a reference to one object or the other, not a reference to some other object or a corrupted reference value. (There is a special exception for long and double values; see §17.4.)

Answer 4

ConcurrentHashMp is:

A hash table supporting full concurrency of retrievals and adjustable expected concurrency for updates. This class obeys the same functional specification as Hashtable, and includes versions of methods corresponding to each method of Hashtable. However, even though all operations are thread-safe, retrieval operations do not entail locking, and there is not any support for locking the entire table in a way that prevents all access. This class is fully interoperable with Hashtable in programs that rely on its thread safety but not on its synchronization details.

The javadocs say that it's thread safe.

Seems like a lot of work and CPU cycles to set configuration. Is it truly this dynamic? Or do you change once a month and just need a service bounce when you do?

Answer 5

volatile guarantees atomicity, visibility and acts as a 'memory barrier' (google for it, if you want to know what that means) - at least since Java 5. Therefore it does exactly what you want.