Thread safe Hash Map?

问题:

I am writing an application which will return a HashMap to user. User will get reference to this MAP. On the backend, I will be running some threads which will update the Map.

What I have done so far?

---

I have made all the backend threads so share a common channel to update the MAP. So at backend I am sure that concurrent write operation will not be an issue.

---

Issues I am having

---

1. If user tries to update the MAP and simultaneously MAP is being updated at backend --> Concurrent write operation problem.
2. If use tries to read something from MAP and simultaneously MAP is being updated at backend --> concurrent READ and WRITE Operation problem.

Untill now I have not face any such issue, but i m afraid that i may face in future. Please give sugesstions.

I am using ConcurrentHashMap<String, String>.

回答1:

You are on the right track using ConcurrentHashMap. For each point:

1. Check out the methods putIfAbsent and replace both are threadsafe and combine checking current state of hashmap and updating it into one atomic operation.
2. The get method is not synchronized internally but will return the most recent value for the specified key available to it (check the ConcurrentHashMap class Javadoc for discussion).

The benefit of ConcurrentHashMap over something like Collections.synchronizedMap is the combined methods like putIfAbsent which provide traditional Map get and put logic in an internally synchronized way. Use these methods and do not try to provide your own custom synchronization over ConcurrentHashMap as it will not work. The java.util.concurrent collections are internally synchronized and other threads will not respond to attempts at synchronizing the object (e.g. synchronize(myConcurrentHashMap){} will not block other threads).

回答2:

Side Note:

You might want to look into the lock free hash table implementation by Cliff Click, it's part of the Highly Scalable Java library

(Here's a Google Talk by Cliff Click about this lock free hash.)

回答3:

ConcurrentHashMap was designed and implemented to avoid any issues with the scenarios you describe. You have nothing to worry about.

A hash table supporting full concurrency of retrievals and adjustable expected concurrency for updates.updates.

javadoc of ConcurrentHashMap