HashMap: safe for multithreaded access for multiple readers and one single writer?

Question

I'm reading the docs for java.util.HashMap, and it says:

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

What does "it" mean? "it" could be interpreted to mean the thread that modifies the map, or it could mean the map itself.

Both the "safe for multiple threads reading" and "safe only on single thread when there is a writer" cases are no brainers (at least to me), which makes me believe that calling the "multiple readers and single writer" case speciffically in the documentation means the statement should be interpreted as "safe to have multiple threads reading and a single thread writing", rather than the no brainer "lock everything when you have a writer".

More so, the hashtable implementation in .Net is (unambiguously) documented as:

Hashtable is thread safe for use by multiple reader threads and a single writing thread

(the .Net classes are not thread safe by default), so there must be something to the "multiple reader threads and one single writer thread" case.

Answer 1

The internal elements are in an indeterminate state when a thread "modifies the map structurally" so reads could be affected. Thus the requirement to use some method external to the map to synchronize both reads and writes.

Perhaps the writers of the .Net library were more careful to keep their internal structure in a determinate state during updates.

Answer 2

The map itself. HashMap is not thread safe.

Look at ConcurrentHashMap, it is a thread-safe map.

You also can manage it by yourself. The code maybe looks like below

class SomeClass {

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

    public synchronized void put(Object key, Object value) {
        map.put(key, value);
    }

    public synchronized Object get(Object key) {
        return map.get(key);
    }
}

More safer, return the copy of the value object to avoid unexpected behaviors.

public synchronized ValueType get(Object key) {
    return map.get(key).clone(); // assume that the ValueType implements Cloneable
    // of course, you can return a copy in many ways you like
}

This will only allow the put method to modify the map. And all the operations will be thread-safe.