Do Your Iterators Always Fail-Fast?

The iterators of the Collection implementations of the Java runtime throw a ConcurrentModificationException[1]when they detect that another thread has modified the Collection whilea thread is iterating over it. Such iterators are generally called fail-fast iterators.

Lookingat the implementation one can see how this has been made possible. TheCollection subclass maintains an integer modCountthat is incremented on every operation that structurally modifies thecollection (like add, remove, clear). The fail-fast iterators alsocontain an integer field expectedModCount which is initialized to themodCount while the iterator is created. Later on, during everyiteration, the iterator verifies if the expectedModCount is same as themodCount ofthe collection it is iterating over. A mismatch means that thecollection has been modified during the life cycle of the iterator anda ConcurrentModificationException is thrown. Thesame happens during the collection serialization process. Themodification count prior to writing to the stream should be same as thecount after writing to the stream.

But is this behaviorguaranteed? Are these iterators always fail-fast? I used to think so,until I saw the declaration of the modCount field in the Collectionimplementations.

The modCountfield is not marked as volatile. This would mean - while a thread makesstructural changes to the collection and increments the modCount field,the other thread that performs the iteration or serialization might notsee the incremented value of the modCount field. It might end up doing acomparison with the stale modCount that is visible to it. This mightcause the fail-fast iterators to behave in a different way and failingat a later point. The field is non-volatile in Apache Harmony too.

A bug[2] in Sun Java explains this. It says the modCountwas intentionally made non-volatile. Making it volatile would haveadded contention at every collection modification operation because ofthe memory fencing that’s required.

Also the Javadoc clearly says “fail-fastbehavior cannot be guaranteed as it is, generally speaking, impossibleto make any hard guarantees in the presence of unsynchronizedconcurrent modification”.

This behavior would be the same even on the Synchronized wrapper's of these collections.