Re: ConcurrentModificationException in single-threaded context
Lew
> Got a weird CME when doing Map.puts or Map.gets on a private HashMap
> which gets accessed by a SINGLE thread. I also never extract iterators
> from the Map.. I only do put() and get().. yet sometimes I get
> ConcurrentModificationException. Toggling the Map between Hashtable,
> HashMap or WeakHashMap implementations makes no difference whatsoever.
>
> Black magic, or am I being dense?
<http://pscode.org/sscce.html>
--
Lew
Eric Sosman
> Got a weird CME when doing Map.puts or Map.gets on a private HashMap
> which gets accessed by a SINGLE thread. I also never extract iterators
> from the Map.. I only do put() and get().. yet sometimes I get
> ConcurrentModificationException. Toggling the Map between Hashtable,
> HashMap or WeakHashMap implementations makes no difference whatsoever.
>
> Black magic, or am I being dense?
Meaning no insult, I suspect the latter.
You say you "never extract iterators," but I bet you do without
realizing it. Note that the `for (Thing t : things)' loop is really
just shorthand for
for (Iterator<Thing> it = things.iterator(); it.hasNext(); ) {
Thing t = it.next();
...
}
so you may be using Iterators even if the string "Iterator" never
shows up in your source code.
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.
Mike Schilling
In a single thread, the behavior should be deterministic.
Eric Sosman
> 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 ...
A useful way to think about this is to imagine the Iterator
(or Enumeration) as using a "snapshot" of the collection to guide
its traversal. Change the collection, and it no longer matches
the snapshot, and the Iterator gets hopelessly lost.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Mike Schilling
> 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.
Eric Sosman
> 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.
Ah! Sorry; I had misunderstood what you meant by
"deterministic," and thought you imagined all the Iterators
could somehow take the Map modifications in stride and keep
on iterating. My apologies for mis-reading.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Mike Schilling
No worries.
Daniel Pitts
> Got a weird CME when doing Map.puts or Map.gets on a private HashMap
> which gets accessed by a SINGLE thread. I also never extract iterators
> from the Map.. I only do put() and get().. yet sometimes I get
> ConcurrentModificationException. Toggling the Map between Hashtable,
> HashMap or WeakHashMap implementations makes no difference whatsoever.
>
> Black magic, or am I being dense?
>
the exception on?
BTW, using the for-each syntax is equivalent to using iterators.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>