Thread-safe setting of a variable (Java)?

Question

Given the following code:

public class FooBar { 

  public static volatile ConcurrentHashMap myConfigData  = new ConcurrentHashMap();      

}

public class UpdaterThread implements Runnable { 

  public void run() {
    //Query the Data from the DB and Update the FooBar config Data
    FooBar.myConfigData = ConfigDataDAO.getLatestConfigFromDB();
  }

}

The Thread-Class will update the myConfigData Membervariable regularly (via an Executor every 5 minutes). Is the setting of of myConfigData in the "external" Thread threadsafe (atomic), or do I have to synchronize every Read and Write operation to the myConfigData Variable?

EDIT: The question is not whether 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 whether the setting is atomic or not. I think this can be generalized to "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.)

Answer 1

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 2

volatile保证原子性，可见性并充当“内存障碍”（google for it，如果你想知道这意味着什么） - 至少从Java 5开始。因此它完全符合你的要求。

Answer 3

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 4

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 5

You could alway use AtomicReference if you feel unsure.

Although I think in your case volatile schould be enough.