Fail-fast vs fail-safe iterators

For this lesson, we'll focus on how modCount and expectedModCount work, why fail-fast is best-effort rather than a thread-safety guarantee, and what people really mean by "fail-safe". We'll cover CopyOnWriteArrayList here because it is the common checklist item, but its deeper concurrency design belongs in the Concurrency module. Interviewers ask this because the phrase sounds simple, then the edge cases reveal whether you know the mechanism.

01Picture it first: a museum alarm, a photo and a live camera

Think of a fail-fast iterator as a museum guard checking whether the room's seal number still matches the number on their clipboard. If another guard moves a painting, the seal changes and the next check trips an alarm. The alarm is helpful, but it is not the lock on the door.

Snapshot iteration is different: you walk around with a photo taken at 10:00. If the room changes at 10:01, your photo does not change. Weakly consistent iteration is closer to a live camera feed: you may see some changes as they happen, but the system avoids corrupt traversal and does not promise a perfect instant-in-time view.

Fig. 1

A fail-fast iterator compares expectedModCount with modCount on next, while a snapshot iterator reads an old array and a weakly consistent iterator traverses a concurrent structure that may show updates

Notice the shape. Fail-fast is about detecting illegal structural change in ordinary collections. Snapshot and weakly consistent iterators are about letting iteration continue under a different contract.

02Fail-fast under the hood: modCount and expectedModCount

Most general-purpose mutable collections in java.util keep a structural modification counter. ArrayList inherits modCount from AbstractList; HashMap has its own. Adding, removing, clearing or resizing changes the shape of the collection, so the counter increments. Replacing an existing value, such as list.set(i, value) or map.put(existingKey, newValue), usually does not change the structure.

List<String> orders = new ArrayList<>(List.of("new", "paid", "shipped"));

for (String status : orders) {                 // creates an Iterator
    if (status.equals("paid")) {
        orders.add("audited");                // structural change outside the iterator
    }
}

The loop usually throws ConcurrentModificationException on the next iterator operation after add. There is only one thread here. ConcurrentModificationException is named after concurrent modification of the collection and iterator, not necessarily concurrent execution by two threads.

Conceptually, the iterator looks like this:

final class ArrayListIterator<E> implements Iterator<E> {
    private int cursor;
    private int expectedModCount = list.modCount;

    public E next() {
        if (list.modCount != expectedModCount) {
            throw new ConcurrentModificationException();
        }
        return list.elementData[cursor++];
    }

    public void remove() {
        list.remove(--cursor);
        expectedModCount = list.modCount;      // iterator performed the change
    }
}