Question

I want to avoid locking on read if possible. But this “feels” like double-checked locking, even though no partially initialized members are involved.

Is this a good construct?

private final Map<String, Stuff> stash = new HashMap<String, Stuff>();

public Stuff getStuff(String name) {

    if (stash.containsKey(name))
        return stash.get(name);

    synchronized(stash) {
        if (stash.containsKey(name)) {
            return stash.get(name);
        }
        else {
            Stuff stuff = StuffFactory.create(name);
            stash.put(name, stuff);
            return stuff;
        }
    }
}

Answer 1

No, this construct is not thread-safe.

Assume that thread writer is putting something into the map, and the map, being too small, must be resized. This is done inside the synchronized block, so you may think you are fine.

During the resizing, nothing in the map is guaranteed.

Now, at the very same time, assume that a thread reader calls getStuff for an existing element. This thread may access the map directly, since it doesn’t hit the synchronized block for the first call to containsKey and get. It will find the map at an undefined state, and although it only reads, it accesses data whose contents is undefined. Among probable results are:

• getStuff returns null when it shouldn’t.
• getStuff returns the intended Stuff.
• getStuff returns some internal object that is used by the HashMap implementation during resizing.
• getStuff returns some other Stuff, unrelated to the name.
• getStuff gets caught in an infinite loop.

This is just the obvious case that should be easy to understand. So no, don’t take shortcuts when there are well-designed classes like ConcurrentHashMap or Guava’s MapMaker.

By the way: Calling containsKey first and then get with the same key is rather inefficient. Just call get, save the result and compare it to null. You will save one searching operation in the map.