Do I need a concurrent hash map if each thread inserts unique keys?

Question

From what I understand a concurrent hash map from Java 5 onwards gives you a thread safe hash map that does not use blocking access for iterators and updates (if a concurrency level is sufficient).

Given the following conditions:

1. Inserts only happen once (during application initialisation).
2. Each thread gets a set of keys to insert that are not shared by any other thread.
3. Updates never happen.
4. Selects only happen once the application initialisation is over.

would I be better off with simple hash maps?

My understanding is that I will probably be better off because my keys won't clash --that I can guarantee. But is it possible that the Java implementation will screw things up in the hash buckets by say assigning the same bucket to two different keys?

Answer 1

If you're inserting using multiple threads, even if the keys are different, you should definitely use ConcurrentHashMap or synchronize the inserts. Plain HashMap simply isn't safe for concurrent writes. Suppose two threads each need to expand the internal table at the same time... even though they're using different keys, that's a fundamentally problematic situation.

Now if you really really have good evidence that using a ConcurrentHashMap for the rest of your application lifetime causes a problem (and I very much doubt that it does), you could perhaps build a concurrent hash map to start with, the convert it to a HashMap (or even an immutable collection from Guava) in a single thread, making sure there's a happens-before barrier between "final map is published" and "threads read final map".

Answer 2

If you have independant keys across threads, you could consider independant Maps. If this is an option, each thread can have its own HashMap which doesn't need to be thread safe provided it is only used by one thread.