How do fail-fast Iterators come to know that underlying structure is modified when the throws 'ConcurrentModificationException' is thrown?

Question

Fail-fast Iterators fail as soon as they realized that structure of Collection has been changed since iteration has begun. Structural changes means adding, removing or updating any element from collection while one thread is Iterating over that collection.

But how does it come to know the change ?

Answer 1

Just checked the source code for the HashMap class. In particular search for 'modCount'. The private HashIterator class, for example, keeps a count of the number of times an instance has been modified (except using the 'remove' method) since the instance was created.

For the 'nextEntry' method the count is checked to see if it has changed and may throw that exception. The 'remove' method also checks the count but, if successful, resets the count to the new value. It does this so that you can use the 'remove' method to remove an entry WITHOUT getting the exception.

Other methods (eg 'clear') will increment the 'modCount'. As the above code excerpt shows that will cause the exception to be raised the next call of 'nextEntry'.

There are NO guarantees that the exception will be thrown.

The API:

http://docs.oracle.com/javase/7/docs/api/java/util/ConcurrentModificationException.html

Note that fail-fast behavior cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast operations throw ConcurrentModificationException on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: ConcurrentModificationException should be used only to detect bugs.