ConcurrentModificationException explained

For this lesson, we'll focus on why CME happens, the famous "remove the second-to-last element and no exception" quirk, the correct removal patterns for lists and maps, and the less obvious sources: HashMap.computeIfAbsent, subList views and real multithreaded races. We covered the iterator families and modCount mechanism in Fail-fast vs fail-safe iterators; here we'll use that mechanism to fix code.

01Picture it first: the iterator has a bookmark

Think of an iterator as reading a printed checklist with a bookmark. The list object on the wall has a revision number. If someone edits the wall list while you are reading from your printed checklist, your next check may notice that the revision number changed and stop.

The odd part is that the iterator does not check on every possible method. For ArrayList, hasNext() checks whether the cursor has reached the current size; next() checks for concurrent modification. That split is what creates the second-to-last removal puzzle.

Fig. 1

Removing the second-to-last element from an ArrayList during for-each leaves cursor equal to the new size, so hasNext returns false and next never checks modCount

Notice the lesson from the diagram: CME is detection, not a formal proof. If the check is not reached, the exception is not thrown.

02The classic bug: removing inside for-each

A for-each loop over an Iterable is syntactic sugar for an Iterator. That matters because the iterator owns its expectedModCount, while list.remove(...) modifies the list directly.

List<String> statuses = new ArrayList<>(List.of("NEW", "PAID", "CANCELLED"));

for (String status : statuses) {
    if (status.equals("PAID")) {
        statuses.remove(status);               // structural change outside iterator
    }
}

This usually throws ConcurrentModificationException. The loop's iterator expected the list's original modCount; statuses.remove(status) increments the list's modCount; the next iterator check sees the mismatch.

The smallest legal change is to use the iterator's own remove() method:

List<String> statuses = new ArrayList<>(List.of("NEW", "PAID", "CANCELLED"));

for (Iterator<String> it = statuses.iterator(); it.hasNext(); ) {
    String status = it.next();
    if (status.equals("PAID")) {
        it.remove();                           // iterator performs and records the change
    }
}

System.out.println(statuses);                  // [NEW, CANCELLED]

Notice three things:

• Iterator.remove() removes the last element returned by next().
• You may call it once per next() call. Calling it twice in a row throws IllegalStateException.
• It keeps the iterator's expected modification count aligned with the collection.

This is the fix to say first in an interview because it shows you understand the mechanism. In day-to-day code, removeIf is often clearer.

03The second-to-last removal quirk

Now for the puzzle that separates memorised rules from mechanism. Removing inside for-each does not always throw. In an ArrayList, if you remove the second-to-last element, the iterator can stop without calling next() again, so the modification check never runs.

List<String> one = new ArrayList<>(List.of("a", "b", "c"));
for (String s : one) {
    if (s.equals("b")) {
        one.remove(s);
    }
}
System.out.println(one);                       // [a, c], no exception

List<String> two = new ArrayList<>(List.of("a", "b", "c"));
for (String s : two) {
    if (s.equals("a")) {
        two.remove(s);
    }
}
System.out.println(two);                       // usually not reached: CME

In the first loop, the iterator has returned b, so its cursor is 2. Removing b shrinks the list size from 3 to 2. The next hasNext() asks cursor != size, which is 2 != 2, so it returns false. next() is not called again, and the modCount check in next() never runs.

In the second loop, after removing a, the cursor is 1 and the new size is 2. hasNext() returns true, then next() checks modCount and throws. This is why I avoid saying "will always throw" in interviews. The better sentence is: it is illegal for the iterator contract and fail-fast detects it on a best-effort basis.