[bad_user]

The fix you're proposing is innadequate for a lot of instances.

A concurrent hashmap is only safe in regards to its own internals, however if you're operating with keys and values that are not thread-safe, then it can still deadlock on get() or other operations. This is why this model of threading is hard, because it is not composable.

Also, threadsafe data-structures have terrible performance characteristics, unless the implementation is lockfree, and lockfree implementations are hard to get right. Therefore I don't blame devs that use HashMaps, as sometimes is better to put locks in other places, or to make sure that the variables are local to a thread.

Threading is hard, lets go shopping.

[brown9-2]

Even without multithreading, mutating the value of a key (such that hashCode() changes) after putting it in the map entry won't return the same entry. This is a HashMap basic, not just something special jujitsu you need to learn with multithreading.

I think blaming someone for using a non-thread-safe data structure without sufficient explicit locking is justifiable.

[hythloday]

Just FYI, ConcurrentHashMap is indeed lockfree (although it's got a gargantuan memory footprint). Wrapping your HashMap with Collections.synchronizedMap gives you a blocking threadsafe HashMap.

[runT1ME]

ConcurrentHashMap is not lock free, it uses lock striping across multiple buckets.

[hythloday]

I stand corrected.