A question about concurrency and static getter methods

Question

Hello
I have a class with some static methods. they just return a reference and doesnt apply any changes.
something like this:
public class FieldMapper {
        private static Map<Class,Map<String,String>> fieldMap = new HashMap<Class,Map<String,String>>();
        public static getFields(Class clazz){
              return fieldMap.get(clazz);
}my question is, let's consider many users connect to my server and each has its own session, now assume one user want to use FieldMapper.getFields(User.class) and another is going to call FieldMapper.getFields(Employee.class) at same time or a bit milli seconds after, and this method is not synchronized, is there any conflict in calling the method? would this method return wrong reference to the first invocation?
in genereal, may the concurrency make problem on reading resources? or just on changing resources?
Thank you very much in advance.

Answer 1

To publish an object safely, both the reference to the object and the object's state must be made visible to other threads at the same time. A properly constructed object can be safely published by:
Initializing an object reference from a static initializer;
Storing a reference to it into a volatile field or AtomicReference;
Storing a reference to it into a final field of a properly constructed object; or
Storing a reference to it into a field that is properly guarded by a lock. The internal synchronization in thread-safe collections means that placing an object in a thread-safe collection, such as a Vector or synchronizedList, fulfills the last of these requirements. If thread A places object X in a thread-safe collection and thread B subsequently retrieves it, B is guaranteed to see the state of X as A left it, even though the application code that hands X off in this manner has no explicit synchronization.
Now in the case you have specified you are using HashMap. Which is not designed to be threadsafe as opposed to HashTable or concurrentHashMap. In such a case I would advise against using this. The concurrency problem is caused by race conditions on mutable objects, whether it is reading or writing. If it is mutable, it is susceptible to race conditions. IMHO
&spades;