2 Replies Latest reply: Apr 23, 2014 8:57 AM by rp0428 RSS

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

    Snehal Masne

      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?

        • 1. Re: How do fail-fast Iterators come to know that underlying structure is modified when the throws 'ConcurrentModificationException' is thrown?
          gimbal2

          There isn't one clear-cut answer. You'd already be able to know if the collection maintains some sort of last-changed counter which the iterator can copy and compare to. It will probably depend on the collection implementation and especially in what cases the exception SHOULD be thrown that dictates how it is "seen". As an example: in the case of a list structure it wouldn't matter if code changes the value of a node, it would only matter if the structure of the list is changed.

          • 2. Re: How do fail-fast Iterators come to know that underlying structure is modified when the throws 'ConcurrentModificationException' is thrown?
            rp0428
            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?

             

            Just check the source code for the HashMap class and you will see 'how' it does it. In particular search for 'modCount'. The private HashInterator 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 (e.g. '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. See 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.