What happens to these concurrent lists when we say we are iterating the 3rd item on the list but another thread concurrently modifies to insert an item at index 1 so this is before the current element. How does the list behave now?

Anyway, reading over the comments, I decided to answer Dimitris’ comment about this almost never happening in real code.

I recently worked on a web application (an inhouse content management app) that stored some seldom-changing globally accessible data in a static ArrayList, to avoid having to read it from the db for everyone. This data was mutable, and anyone using the app could delete instances from the db … the delete (or add or modify) operations would also update the ArrayList.

The number of users was low (maybe 10 at a time, max) and it was unlikely that two would be working on the same operations at the same time, but we did get the occasional CME (a couple of times a month?), resulting in error pages shown to the user, due to this very problem.

Of course, it was a design problem due to the original developer not thinking about concurrent programming.

I understand that it would be difficult to support meaningfully (single-threaded) modification in an ArrayList or others, but for example LinkedList’s iterator is just a pity that behaves like this (it could cope perfectly well with in-thread modifications).

Arbitrary non-thread-safe classes trying to protect as from unsynchronized access (in ‘some’ cases, if we are lucky) is just absurd. Just imagine this approach being taken in any non-thread-safe class. I think Josh’s call was the wrong one in this case, and the exception should have been more honest: it would be better to have something like “ModificationWhileIteratingNotSupportedException” instead of “ConcurrentModificationException”, and just in those collections that indeed couldn’t support this.