[concurrency-interest] ConcurrentHashMap entrySet Iterator remove issue?

Doug Lea dl at cs.oswego.edu
Sat Feb 6 15:54:38 EST 2016

On 02/05/2016 09:05 PM, Martin Buchholz wrote:
> It's not entirely clear whether entrySet().iterator().remove() should
> remove the entry for the current key or only if still mapped to the
> old value.  But acting like the latter seems better for users - I
> agree with Mike.  The existence of map.remove(K, V) gives an
> expectation that iterator().remove() works likewise.

As others have mentioned, iterator.remove is underspecified, so
either behavior is allowed. In general it is a bad idea to use
it in a concurrent program if you care about outcome -- instead use
the version of map.remove that you need/want.

> The counter-arguments against switching now are:
> - it is a small added implementation burden for the iterator to keep
> track of the old value, that will almost never be used.
> - users can just call remove(K, V) - they have the old v in hand, that
> the map has already forgotten.
> - status quo wins whenever there's doubt!
> But the behavior should be documented.

Or perhaps the uncertainty of effect should be documented in
the ConcurrentMap interface, since the issue occurs with
all ConcurrentMaps?


More information about the Concurrency-interest mailing list