Java Fail-fast vs Fail-safe Iterator

When a Java collection is modified while an iterator is scanning it, two completely different things can happen depending on the collection: either the iterator immediately throws ConcurrentModificationException — that is fail-fast behaviour — or it continues silently without any error — that is fail-safe behaviour. Which one fires, and why, depends entirely on the collection you are using and how it implements its iterator.

Getting this wrong in production causes two classes of bugs: unexpected exceptions that crash a thread mid-traversal, or silent data inconsistencies where the iterator processes stale or incomplete data. Both are real bugs. Understanding the distinction lets you choose the right collection for the access pattern before the bug appears.

What Are Fail-fast and Fail-safe Iterators?

Fail-fast iterator: An iterator that throws ConcurrentModificationException immediately when it detects that the collection was structurally modified outside the iterator during an active traversal. It detects this via an internal modCount counter. The goal is to surface the bug as early as possible — a structural modification during iteration almost always means the code has a logic error.

Fail-safe iterator: An iterator that does not throw on structural modification. It either works on a frozen snapshot of the collection taken at iterator creation time, or uses a weakly consistent traversal strategy that tolerates concurrent changes. The goal is uninterrupted traversal even in the presence of concurrent modification.

The diagram below shows both types side by side.

FAIL-FAST (ArrayList, HashMap, HashSet, TreeMap, TreeSet...)

  Thread or same code:               Iterator:
  list.add("new element")            next() call
           |                              |
  modCount++ (now 42)           check: modCount == expectedModCount?
           |                              |
  (list state changed)           42 != 41  ← MISMATCH
                                           |
                              throw ConcurrentModificationException


FAIL-SAFE — CopyOnWriteArrayList:

  Thread A: list.add("X")         Thread B: iterator running
            |                              |
  copy array → new array           iterates original snapshot
  swap reference                   never sees "X"
            |                              |
  (no CME — thread B has snapshot)  completes safely


FAIL-SAFE — ConcurrentHashMap:

  Thread A: map.put("key", val)   Thread B: iterator running
            |                              |
  updates one bucket                may or may not see "key"
            |                              |
  (no CME — weakly consistent)      completes safely

The key distinction is not about thread safety per se — a single thread can trigger CME in fail-fast collections by calling list.add() inside a for-each loop. The thread count is irrelevant. What matters is whether the collection was structurally modified while an iterator was active.

Which Collections Use Which Behaviour

FAIL-FAST COLLECTIONS (throw ConcurrentModificationException):
  java.util package — all standard collections:
  ArrayList, LinkedList, Vector, Stack
  HashSet, LinkedHashSet, TreeSet
  HashMap, LinkedHashMap, TreeMap, Hashtable
  ArrayDeque, PriorityQueue

FAIL-SAFE COLLECTIONS (no ConcurrentModificationException):
  java.util.concurrent package — concurrent collections:
  CopyOnWriteArrayList     → full array snapshot at iterator creation
  CopyOnWriteArraySet      → backed by CopyOnWriteArrayList, same behaviour
  ConcurrentHashMap        → weakly consistent — may miss recent puts/removes
  ConcurrentLinkedQueue    → weakly consistent
  ConcurrentSkipListMap    → weakly consistent
  ConcurrentSkipListSet    → weakly consistent

  Also fail-safe:
  Collections.unmodifiableXxx() wrappers — CME not possible because
  structural modification throws UnsupportedOperationException first

How the Fail-fast Mechanism Works Internally

Every standard Java collection maintains an int modCount field. This counter starts at 0 and increments on every structural modification — every add(), remove(), clear(), set() that changes the collection's size or structure.

ARRAYLIST'S modCount TRACKING:

  ArrayList internal fields:
    Object[] elementData    — the backing array
    int      size           — number of live elements
    int      modCount       — starts at 0, increments on structural change

  Actions that increment modCount:
    add(E)              → modCount++
    add(int, E)         → modCount++
    remove(int)         → modCount++
    remove(Object)      → modCount++
    clear()             → modCount++
    sort()              → modCount++
    removeIf()          → modCount++ per removal (handled internally)

  Actions that do NOT increment modCount:
    get(int)            — read-only, no structural change
    set(int, E)         — replaces, size unchanged, no structural change
    contains(Object)    — read-only
    size()              — read-only

  Iterator creation (iterator()):
    int cursor          = 0
    int lastRet         = -1
    int expectedModCount = list.modCount   ← snapshot taken HERE

  Every next() call:
    if (modCount != expectedModCount)
        throw new ConcurrentModificationException()
    ...proceed with element access

The snapshot is taken once at iterator creation. Between creation and exhaustion, if any structural change increments modCount, the mismatch is detected on the next next() call and CME fires.

Core Examples — Fail-fast in Action

Triggering ConcurrentModificationException

The most common CME pattern appears in fresher code: modifying a list inside a for-each loop. The for-each compiles to an iterator, and the direct list.remove() increments modCount without updating the iterator's expectedModCount.

Output:
=== Triggering CME (wrong approach) ===
  Processing: ORD-001
  Processing: ORD-002
  CME thrown at next next() after modCount change

List state after CME: [ORD-001, ORD-003, ORD-004]

=== CME after external add() ===
  CME fired: external add() invalidated the iterator

Safe Removal — The Correct Patterns

Three patterns fix the CME issue, each appropriate for a different situation.

Output:
Pattern 1 (iterator.remove): [DELIVERED, CANCELLED]
Pattern 2 (removeIf)       : [DELIVERED, CANCELLED]
Pattern 3 (collect + replace): [DELIVERED, CANCELLED]

How Fail-safe Works — CopyOnWriteArrayList

CopyOnWriteArrayList takes a fundamentally different approach. Every write operation — add(), remove(), set() — copies the entire backing array, performs the modification on the copy, and atomically swaps the reference. The iterator holds a reference to the array at the time it was created. Any subsequent writes create a new array and have no effect on the iterator's snapshot.

CopyOnWriteArrayList INTERNAL STRUCTURE:

  Write path (add, remove, set):
    1. Lock acquired (ReentrantLock)
    2. Copy current array to newArray
    3. Modify newArray
    4. Atomically set array = newArray (volatile write)
    5. Lock released

  Iterator creation:
    Iterator snapshot = current array reference (volatile read)
    — iterator will always see THIS array, never a newer one

  Read path (iterator next()):
    No lock — reads from snapshot array directly
    Never checks modCount — it does not exist
    Never throws CME — snapshot is immutable from iterator's view

  CONSEQUENCE:
    Iterators are completely isolated from writes.
    A thread calling add() gets a new array.
    The iterator's array is untouched.
    Iteration cost: O(1) per element, no locks.
    Write cost: O(n) — full array copy every time.

Output:
=== Fail-safe: no CME when list changes during iteration ===
Listeners in snapshot (iterator sees 3, not 4):
  EmailNotifier
  SMSNotifier
  PushNotifier

Current list (has 4 after add):
  EmailNotifier
  SMSNotifier
  PushNotifier
  SlackNotifier

=== Snapshot isolation — iterator sees original state ===
  user-priya
  user-rohan
  user-ananya
Live list: [user-priya, user-ananya, user-karan]

How Fail-safe Works — ConcurrentHashMap

ConcurrentHashMap takes a different approach to fail-safe than CopyOnWriteArrayList. It does not snapshot the entire map — instead, it uses weakly consistent iteration. The iterator is allowed to reflect some, all, or none of the concurrent modifications that happen after it is created.

ConcurrentHashMap ITERATOR — WEAKLY CONSISTENT:

  Properties:
  - Never throws ConcurrentModificationException
  - No modCount field — structural modifications are not tracked
  - May see modifications made after iterator creation, or may not
  - Guarantees: will traverse every entry that existed at creation
    and may or may not traverse entries added after creation

  Contrast with CopyOnWriteArrayList:
    COWAL: always sees exactly the state at iterator creation
    CHM:   may see a mix of old and new state

  Why weakly consistent?
    CHM splits the map into many segments/buckets.
    Each bucket can be locked independently.
    The iterator scans bucket by bucket.
    Buckets scanned before a write: see old state.
    Buckets scanned after the write: see new state.
    No global snapshot needed — efficient for large maps.

Output:
=== ConcurrentHashMap — no CME on structural modification ===
  Laptop = 45
  Mouse = 120
  Keyboard = 80
  Monitor = 25

Final map: {Laptop=45, Mouse=120, Keyboard=80, Monitor=25, Webcam=60}

Word counts: {spring=2, java=3, hibernate=1}

Fail-fast vs Fail-safe — Direct Comparison

Real-World Example — Razorpay Webhook Event Dispatcher

A webhook event dispatcher handles incoming payment events. Multiple threads register and deregister listeners, while the dispatcher thread continuously iterates registered listeners to deliver events. With a fail-fast ArrayList, deregistering a listener during dispatch throws CME and crashes the dispatch loop. CopyOnWriteArrayList solves this correctly — writes create a new array and the in-progress dispatch completes on the stable snapshot.

Output:
=== Registering listeners ===
  Registered listener. Total: 1
  Registered listener. Total: 2
  Registered listener. Total: 3

=== First dispatch (3 listeners) ===
  Dispatching [PAYMENT_SUCCESS] to 3 listeners (snapshot):
    EMAIL   : PAYMENT_SUCCESS — txn_id=TXN-9821, amount=1299.00
    SMS     : PAYMENT_SUCCESS — txn_id=TXN-9821, amount=1299.00
    DASHBOARD: PAYMENT_SUCCESS — txn_id=TXN-9821, amount=1299.00

=== Deregistering SMS listener ===
  Deregistered listener. Total: 2

=== Second dispatch (2 listeners in live list) ===
  Dispatching [PAYMENT_FAILED] to 2 listeners (snapshot):
    EMAIL   : PAYMENT_FAILED — txn_id=TXN-9822, reason=INSUFFICIENT_FUNDS
    DASHBOARD: PAYMENT_FAILED — txn_id=TXN-9822, reason=INSUFFICIENT_FUNDS

Final listener count: 2

Performance Considerations

When write cost matters: CopyOnWriteArrayList copies the entire array on every write. For a list of 100,000 elements that changes frequently, this creates heavy GC pressure. Use it only for read-heavy, write-rare scenarios — event listener registries, configuration snapshots, observer lists.

When consistency matters: ConcurrentHashMap is weakly consistent — an iterator that starts before a put() may or may not see the new entry. For use cases that require a consistent snapshot, copy the map: new HashMap<>(concurrentHashMap) and iterate the copy.

Best Practices

Use fail-fast collections for all single-threaded code. ArrayList, HashMap, and HashSet are faster than their concurrent counterparts because they have no locking or copying overhead. Their fail-fast behaviour is a safety net — it surfaces the code-level mistake of modifying a collection during iteration immediately, rather than letting a silent data inconsistency propagate.

Use CopyOnWriteArrayList only for read-heavy, write-rare lists. The right scenario is: many threads read and iterate frequently, writes happen infrequently (registering or deregistering a listener, loading a configuration at startup). The O(n) copy cost is acceptable when writes are rare. For write-heavy concurrent lists, use Collections.synchronizedList(new ArrayList<>()) or a ConcurrentLinkedDeque instead.

Use ConcurrentHashMap as the default concurrent map. For any Map accessed from multiple threads, ConcurrentHashMap is the correct default. It is significantly faster than Collections.synchronizedMap() under concurrent load because it locks at bucket granularity rather than on the entire map. The weakly consistent iterator is acceptable for most use cases — if a strict snapshot is needed, copy the map before iterating.

Never catch CME and continue. ConcurrentModificationException is a signal that the code has a structural bug — a collection is being modified during iteration in a way that violates the iteration contract. Wrapping the iteration in a try-catch and catching CME to continue is a code smell. Fix the root cause: use removeIf(), iterator.remove(), or the right concurrent collection.

Common Mistakes

Mistake 1 — Catching CME and Continuing Silently

Mistake 2 — Using CopyOnWriteArrayList for Frequently Written Lists

Mistake 3 — Assuming ConcurrentHashMap Iterator Sees All Recent Changes

Mistake 4 — Expecting Fail-fast to Guarantee Thread Safety

Interview Questions

Q1. What is the difference between fail-fast and fail-safe iterators in Java?

A fail-fast iterator throws ConcurrentModificationException immediately when it detects a structural modification to the collection outside the iterator during traversal. It achieves this by tracking a modCount counter — the collection increments modCount on every structural change, and the iterator snapshots it at creation. On every next() call, the iterator checks whether modCount still matches. A fail-safe iterator does not throw — it either works on a snapshot of the collection at creation time (CopyOnWriteArrayList) or uses weakly consistent traversal (ConcurrentHashMap). Fail-fast collections are in java.util; fail-safe ones are in java.util.concurrent.

Q2. What exactly is modCount and which classes use it?

modCount is an int field maintained by most java.util collection classes — ArrayList, LinkedList, HashMap, HashSet, TreeMap, TreeSet, ArrayDeque, and others. It starts at 0 and increments on every structural modification: every add(), remove(), clear(), and similar operations that change the collection's size or structure. set() on a List does not increment modCount because it does not change structure. Iterator classes snapshot modCount as expectedModCount at creation time and compare on every next() call. If they differ, ConcurrentModificationException is thrown.

Q3. Does ConcurrentModificationException always mean a multi-threading problem?

No — and this is a common misconception. Despite the name, ConcurrentModificationException fires whenever a collection is structurally modified while an iterator is active, even in completely single-threaded code. The most common cause is calling list.remove(element) inside a for-each loop on the same list — one thread, one loop, no concurrent threads. The word "concurrent" means simultaneous modification and traversal, not multi-threaded execution. Multi-threaded structural modification is one scenario; the single-thread for-each mistake is a more common one.

Q4. How does CopyOnWriteArrayList achieve fail-safe iteration?

Every write operation on CopyOnWriteArrayList — add(), remove(), set(), clear() — acquires a ReentrantLock, creates a full copy of the backing array, applies the modification to the copy, then atomically swaps the internal array reference to the new copy via a volatile write. The iterator stores a reference to the array at the time it was created — this reference never changes for the iterator's lifetime. Any subsequent writes create new arrays, leaving the iterator's snapshot untouched. The iterator never checks modCount and never throws CME. The tradeoff is that every write is O(n).

Q5. When would you choose ConcurrentHashMap over Collections.synchronizedMap()?

Collections.synchronizedMap() wraps a HashMap with a single mutex — every method acquires the same lock, so only one thread executes any operation at a time. ConcurrentHashMap uses fine-grained locking at the bucket level — multiple threads can read without any lock, and writers lock only the specific bucket being modified. For high-concurrency workloads with many concurrent reads, ConcurrentHashMap is significantly faster. synchronizedMap() is simpler and appropriate for low-concurrency scenarios where simplicity outweighs the performance difference. ConcurrentHashMap also provides atomic operations like putIfAbsent() and computeIfAbsent() that are genuinely atomic — synchronizedMap() methods are individually atomic but not composable.

Q6. What is the correct way to remove elements from a collection during iteration?

Three approaches in order of preference: (1) collection.removeIf(predicate) — the cleanest Java 8+ approach, handles modCount bookkeeping internally, works with any Collection, and expresses intent clearly. (2) Explicit iterator.remove() — call it.next() first, then it.remove() — the iterator updates expectedModCount after the removal, keeping it in sync. (3) Collect indices or values to remove, finish the iteration, then perform removals in a separate pass. Never call list.remove() or list.add() directly inside a for-each loop on the same collection.

FAQs

Does fail-fast mean the iterator is thread-safe?

No. Fail-fast means the iterator detects a structural modification and throws an exception — it does not prevent the modification from happening. In multi-threaded code, two threads can simultaneously corrupt the backing array before the iterator even gets to check modCount. CME is best-effort detection in single-threaded code. For actual thread safety, use collections from java.util.concurrent.

Can a CopyOnWriteArrayList iterator see elements added during iteration?

No. The iterator holds a reference to the array snapshot taken at creation time. Elements added after creation go into a new array, which the iterator never sees. This is by design — the snapshot guarantee makes iteration predictable. If you need to process newly added elements, create a new iterator after the additions are complete.

What is the difference between weakly consistent and strongly consistent iteration on ConcurrentHashMap?

Weakly consistent means the iterator reflects the state of the map at some point between its creation and the current moment — it may or may not see puts and removes made after the iterator was created, but it will not miss entries that existed at creation time and were not removed. Strongly consistent would require a global snapshot lock that blocks all writers during iteration. ConcurrentHashMap trades strong consistency for throughput — no global lock means iteration and modification happen concurrently at full speed.

Is removeIf fail-safe or fail-fast?

removeIf() is internally fail-fast for standard collections like ArrayList and HashSet — it uses the iterator mechanism and handles modCount bookkeeping correctly, so calling removeIf() from one thread while another thread modifies the same collection can still throw CME or produce incorrect results. removeIf() is safe within a single thread. For multi-threaded scenarios, use CopyOnWriteArrayList.removeIf() or ConcurrentHashMap.entrySet().removeIf(), which handle concurrent access correctly.

What happens if CME fires mid-loop — is the collection in a valid state?

The collection itself is in a valid structural state after CME — the modification that caused the CME was completed successfully (the add() or remove() that triggered it actually happened). What is invalid is the iterator's view — it can no longer be used safely. The collection can be iterated again with a fresh iterator. The concern is that the modification may have been partial from the business logic perspective — for example, half the elements may have been processed before CME fired.

Is it safe to iterate a HashMap from two different threads at the same time?

No — even read-only iteration on a HashMap from two threads is not safe if any thread is writing to it concurrently. A write in progress can leave the internal bucket array in a partially updated state, causing the reading thread to see corrupted data or throw NullPointerException. For multi-threaded use, use ConcurrentHashMap whose iteration is designed for concurrent access. For truly read-only use after a build phase, wrap with Collections.unmodifiableMap() — writes are then blocked by UnsupportedOperationException.

Summary

Fail-fast and fail-safe describe two opposite philosophies in how Java collection iterators handle structural modification during traversal. Fail-fast — the default for all java.util collections — uses a modCount counter to detect structural changes and throws ConcurrentModificationException immediately. This is a bug-detection mechanism, not a thread-safety guarantee. Fail-safe — used by CopyOnWriteArrayList and the concurrent collections in java.util.concurrent — allows traversal to continue either via snapshot isolation or weakly consistent traversal.

The practical rules: fix CME at the root by using removeIf() or iterator.remove() rather than catching the exception; use CopyOnWriteArrayList for event listener registries and other read-heavy lists that change rarely; use ConcurrentHashMap as the default concurrent map. The choice of fail-fast vs fail-safe is ultimately the choice of collection class — it is not a setting you configure, it is a property of the implementation.

For interviews: know that CME can fire in single-threaded code, explain the modCount mechanism precisely, distinguish CopyOnWriteArrayList's snapshot isolation from ConcurrentHashMap's weakly consistent iteration, and always demonstrate fixing CME at the root rather than catching it.

What to Read Next