Re: ConcurrentModificationException in single-threaded context
Eric Sosman wrote:
Mike Schilling wrote:
Eric Sosman wrote:
[...]
From your description, I suspect `things' is either the
keySet()
or entrySet() of the Map. If the "..." code executes put() on the
Map (or modifies the Map in any other way), the Iterator will
throw[*]
ConcurrentModificationException at the next hasNext() call.
[*] "Will very probably throw," really. See the Javadoc.
In a single thread, the behavior should be deterministic.
If you're sure, file an RFE. ;-)
To support it, exhibit concrete implementations that "work"
in all single-threaded situations, *including* those where forty-
two independent Iterators at forty-two independent positions are
simultaneously traversing the same HashMap.keySet() at the moment
when a new key/value pair is inserted and causes a re-hash ...
Repeat the exercise for all other collection classes ...
It's very simple: all 42 will throw CMEs when next accessed. The
implementation is quite simple. The underlying map has a "number of
modifications" counter that it increments whenever it's modified, e.g.
when a new key is added. Each iterator makes a copy of that number
when it's created. Whenever the iterator is accessed and its
modification count doesn't match the map's, it throws a CME. In a
single-threaded environment, this works perfectly. The weasel-wording
in the Javadoc about "will probably throw" is to cover multi-threaded
cases; since the accesses to the two modification counts are not
synchronized, it's possible that a change to them made in one thread
won't yet be visible in another.