如果在迭代时修改集合而不抛出 ConcurrentModificationException 会发生什么

Question

As all known We can't modify a non-thread-safe collection while iterating it since it will throw a ConcurrentModificationException

But what I want to know is that what will happen if it would not throw a Exception and let the iteration and modification happened concurrently.

For example, remove an element from a HashMap while iterating it.

1. Remove. Since remove operation would not change the length of the underlying table in the HashMap, I think that's not an issue to the iteration.

2. Put. Maybe problem only occurs when the Put triggers resize() since the underlying table will be shuffled.

Is my analysis correct?

Answer 1

Short answer: no, your analysis is not correct.

If you remove something from a collection while you're iterating over it (without using the iterator), the iterator doesn't have a good way to keep track of where it is. Use a simpler example: List. Say the iterator is at index 10, and you remove index 5. That removal shifts all of the indices. Now you call next() on the iterator, and you.. what? Go to index 11? Stay at index 10? The iterator has no way to know.

Similarly, if you add something to a collection while you're iterating over it (without using the iterator), the iterator doesn't know if that was added before or after the current index, so the next() function is broken.

This doesn't even get into data structures where the iterator order depends on what's in the collection, but the issues are similar to the ones I listed above.

Answer 2

But what I want to know is that what will happen if it would not throw a Exception and let the iteration and modification happened concurrently.

This is hypothetical because the respective (non-concurrent) collections don't work that way. If we hypothesize that they did allow "concurrent" modification, then we still cannot answer without making assumptions about how iteration would then be implemented. Finally, assuming that we just removed the fast-fail tests, then the behaviour will be collection specific.

Looking at your analysis for the HashMap case, you have to consider the internal state of the iterator object. I haven't looked at any specific implementation code, but a typical HashMap iterator will have an index for a hash chain in the main hash array, and a pointer to a node within the hash chain:

• A Map.remove won't change the hashmap size, so the chain index won't be invalidated. However, if the wrong entry was removed, we could find that the iterator's node pointer could refer to a node that is no longer in the chain. This could cause the iteration to return deleted map entries.

• You are correct that a Map.put that triggered a resize could cause the entries to be redistributed. This could cause some entries to be skipped, and others to be returned twice.

Answer 3

Usually the traditional collection classes in java.util package uses an int variable ( modCount ) to keep track of modifications (additions and deletions).

When we ask for an Iterator from these collection classes then a object of Iterator which is returned is provided with the existing modification count variable as its expected modification count.

Upon invoking the next() method the Iterator object checks the current modification count variable value against its expected modification count value.

In case of a mismatch it fails fast by throwing ConcurrentModificationException present in java.util package, its a RuntimeException .

Do not get confused between the size of the collection object (as in your question Map) and the total buckets available. Moreover its not about the size, one addition increases the value of the modification count flag and also a deletion increases its value.