What Are Fail-Fast and Fail-Safe Iterators?

A fail-fast iterator checks the collection for concurrent modification as it goes. When you obtain an iterator, it records the collection's modification count. Every call to next compares the current count with the recorded one, and if they differ it throws ConcurrentModificationException rather than letting you continue iterating over a structure that has shifted underneath you.

The exception is thrown on the next call, not by the modification itself. So the modification succeeds, and then the iterator notices on the following step and gives up. The collection is left in a partially modified state, which is one reason this pattern is so awkward to debug.

A fail-safe iterator does not fail at all. It either works on a snapshot of the collection taken when the iterator was created, or it tolerates concurrent modification without throwing. The classic snapshot approach is the CopyOnWriteArrayList, whose iterator reads from an immutable copy, so it never sees later changes and never throws.

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.CopyOnWriteArrayList;

public class Main {
    public static void main(String[] args) {
        List<String> list = new ArrayList<>(List.of("a", "b", "c"));
        try {
            for (String s : list) {
                if (s.equals("a")) {
                    list.add("d");    // structural modification during iteration
                }
            }
        } catch (java.util.ConcurrentModificationException e) {
            System.out.println("fail-fast: ConcurrentModificationException");
        }

        // A copy-on-write list iterates over a snapshot.
        CopyOnWriteArrayList<String> safe = new CopyOnWriteArrayList<>(List.of("a", "b", "c"));
        for (String s : safe) {
            if (s.equals("a")) {
                safe.add("d");
            }
        }
        System.out.println("fail-safe: " + safe);
    }
}

The output shows both behaviours. The ArrayList iteration throws on the second pass through the loop. The CopyOnWriteArrayList completes normally and the new element is present in the list afterwards, even though the iteration never saw it — the iterator was working from a snapshot taken before the addition.

Two clarifications. Fail-fast is not a safety guarantee; it is a bug detector, and it is best-effort. The check catches modifications made through the same collection object, but it will not detect a modification made through a different reference to the same underlying data, and it will not fire if the modification does not change the modification count. And fail-safe does not mean thread-safe: the CopyOnWriteArrayList itself is thread safe, but a plain ArrayList with an iterator is still not.

The concurrent collections in java.util.concurrent never throw ConcurrentModificationException. ConcurrentHashMap and ConcurrentLinkedQueue return iterators that are weakly consistent: they reflect some state of the collection at or since the point the iterator was created, they never throw, and they may or may not show a concurrent update. CopyOnWriteArrayList and CopyOnWriteArraySet return iterators over an immutable snapshot, so they are perfectly consistent with the state at the moment the iterator was made, but they never see later changes.

Fail-fast is the better default for ordinary code because it turns a silent, hard-to-diagnose bug into a loud failure. When the exception fires, you know immediately that you modified a collection during iteration. Without it, the typical symptom is that some elements were skipped or processed twice, and the bug surfaces as wrong output rather than as an error — which can be many hours away from the cause.

The trade-off is performance. The fail-fast check is a cheap integer comparison per next call, but it does mean the collection has to maintain a modification counter, which adds a small cost to every write. The CopyOnWriteArrayList goes much further: every write copies the entire backing array, so it is only appropriate for collections that are read far more often than they are written — an event listener list, a configuration set that changes rarely.

The practical guidance for interviews: use the ordinary collections and remove elements through the iterator, the removeIf method, or by copying to a new collection. Reach for a concurrent collection when multiple threads really are involved, and treat its iterator semantics as a feature rather than a compromise.