The main reason that nulls aren't allowed in ConcurrentMaps
(ConcurrentHashMaps, ConcurrentSkipListMaps) is that ambiguities that
may be just barely tolerable in non-concurrent maps can't be
accommodated. The main one is that if
Normally you would solve that by synchronizing, but with a concurrent map that of course won't work. Hence the signature for
map.get(key)
returns null
, you
can't detect whether the key explicitly maps to null
vs the key isn't
mapped. In a non-concurrent map, you can check this via
map.contains(key)
, but in a concurrent one, the map might have changed
between calls.if (m.containsKey(k)) {
return m.get(k);
} else {
throw new KeyNotPresentException();
}
Since m
is a concurrent map, key k may be deleted between the containsKey
and get
calls, causing this snippet to return a null that was never in the table, rather than the desired KeyNotPresentException
.Normally you would solve that by synchronizing, but with a concurrent map that of course won't work. Hence the signature for
get
had to change, and the only way to do that in a backwards-compatible
way was to prevent the user inserting null values in the first place,
and continue using that as a placeholder for "key not found".
0 comments:
Post a Comment