Is Hashmap's containsKey method threadsafe if the map is initialized once, and is never modified again

Question

Can we use Hashmap's containsKey() method without synchronizing in an multi-threaded environment?

Note: Threads are only going to read the Hashmap. The map is initialized once, and is never modified again.

Answer 1

It really depends on how/when your map is accessed.
Assuming the map is initialized once, and never modified again, then methods that don't modify the internal state like containsKey() should be safe. In this case though, you should make sure your map really is immutable, and is published safely.

Now if in your particular case the state does change during the course of your program, then no, it is not safe. From the documentation:

Note that this implementation is not synchronized. If multiple threads access a hash map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally.

In this case, you should use ConcurrentHashMap, or synchronize externally.

Answer 2

You shouldn't look at a single method this way. A HashMap is not meant to be used in a multi-threaded setup.

Having said that, the one exception would be: a map that gets created once (single threaded), and afterwards is "read" only. In other words: if a map doesn't get changed anymore, then you can have as many threads reading it as you want.

From that point of view, just containsKey() calls shouldn't call a problem. The problem arises when the information that this method relies on changes over time.

Answer 3

No, it is not thread-safe for any operations. You need to synchronise all access or use something like ConcurrentHashMap.

My favourite production system troubleshooting horror story is when we found that HashMap.get went into an infinite loop locking up 100% CPU forever because of missing synchronisation. This happened because the linked lists that were used within each bucket got into an inconsistent state. The same could happen with containsKey.

You should be safe if no one modifies the HashMap after it has been initially published, but better use an implementation that guarantees this explicitly (such as ImmutableMap or, again, a ConcurrentMap).

Answer 4

No. (No it is not. Not at all. 30 characters?)

Answer 5

It's complicated, but, mostly, no.

1. The spec of HashMap makes no guarantees whatsoever. It therefore reserves the right to blast yankee doodle dandy from your speakers if you try: You're just not supposed to use it that way.

2. ... however, in practice, whilst the API of HashMap makes no guarantees, generally it works out. But, mind the horror story of @Thilo's answer.

3. ... buuut, the Java Memory Model works like this: You should consider that each thread gets an individual copy of each and every field across the entire heap of the VM. These individual copies are then synced up at indeterminate times. That means that all sorts of code simply isn't going to work right; you add an entry to the map from one thread, and if you then access that map from another you won't see it even though a lot of time has passed – that's theoretically possible. Also, internally, map uses multiple fields and presumably these fields must be consistent with each other or you'll get weird behaviours (exceptions and wrong results). The JMM makes no guarantees about consistency either. The way out of this dilemma is that the JMM offers these things called 'comes-before/comes-after' relationships which give you guarantees that changes have been synced up. Using the 'synchronized' keyword is one easy way to get such relationships going.

4. Why not use a ConcurrentHashMap which has all the bells and whistles built in and does in fact guarantee that adding an entry from thread A and then querying it via containsKey from thread B will get you a consistent answer (which might still be 'no, that key is not in the map', because perhaps thread B got there slightly before thread A or slightly after but there's no way for you to know. It won't throw any exceptions or do something really bizarre such as returning 'false' for things you added ages ago all of a sudden).

So, whilst it's complicated, the answer is basically: Don't do that; either use a synchronized guard, or, probably the better choice: ConcurrentHashMap.

Answer 6

No, Read the bold part of HashMap documentation:

Note that this implementation is not synchronized.

So you should handle it:

If multiple threads access a hash map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally.

And suggested solutions:

This is typically accomplished by synchronizing on some object that naturally encapsulates the map. If no such object exists, the map should be "wrapped" using the Collections.synchronizedMap method

Answer 7

@user7294900 is right.

If your application does not modifies the HashMap structurally which is build thread-safely and your application just invoke containsKey method, it's thread safe.

For instance, I've used HashMap like this:

@Component
public class SpringSingletonBean {

    private Map<String, String> map = new HashMap<>();

    public void doSomething() {
        //
        if (map.containsKey("aaaa")) {
            //do something
        }
    }

    @PostConstruct
    public void init() {
        // do something to initialize the map
    }

}

It works well.