How Java’s Enhanced for Loop Works with Collections

A deep dive into Iterable, Iterator, fail-fast behavior, ConcurrentModificationException, and the exact cases where removing elements inside a for-each loop silently corrupts your data.

1. The starting point: Collection extends Iterable

When I first studied Java Collections, I noticed a small but meaningful inheritance relationship:

public interface Collection<E> extends Iterable<E> {
    // ...
}

At first glance, this looks like a trivial detail. But this single line is the reason the enhanced for loop works with every collection in the framework — List, Set, Queue, Deque, and so on.

To understand why, we need to look at what Iterable actually promises.

2. What Iterable and Iterator actually promise

Iterable exposes one abstract method:

public interface Iterable<T> {
    Iterator<T> iterator();
}

That's it. Iterable says: "I can give you an Iterator that walks through my elements."

Iterator is the walker itself:

public interface Iterator<E> {
    boolean hasNext();
    E next();

    default void remove() {
        throw new UnsupportedOperationException();
    }

    default void forEachRemaining(Consumer<? super E> action) {
        /* ... */
    }
}

A few important details:

• next() throws NoSuchElementException if there are no more elements.
• remove() is a default method (since Java 8) that throws UnsupportedOperationException unless the iterator overrides it.
• remove() must be called after next(), and only once per next() call — otherwise it throws IllegalStateException.

So the contract is small but strict. The enhanced for loop is built on top of it.

3. How the enhanced for loop is desugared for Iterable

The Java Language Specification (§14.14.2) defines the enhanced for loop over an Iterable as equivalent to:

for (Iterator<T> it = iterable.iterator(); it.hasNext(); ) {
    T element = it.next();
    // loop body
}

So when you write:

List<String> names = List.of("Ali", "Ahmed", "Sabeer");

for (String name : names) {
    System.out.println(name);
}

The compiler translates it to:

for (Iterator<String> it = names.iterator(); it.hasNext(); ) {
    String name = it.next();
    System.out.println(name);
}

The loop does not touch the collection directly. It only talks to the Iterator. That single fact is what causes every problem we're about to discuss.

4. The one exception: arrays

The desugaring above applies to Iterable. Arrays are handled differently. The JLS specifies that for arrays:

int[] numbers = {1, 2, 3};

for (int n : numbers) {
    System.out.println(n);
}

is translated to an indexed loop:

for (int i = 0; i < numbers.length; i++) {
    int n = numbers[i];
    System.out.println(n);
}

No Iterator. No Iterator.remove(). So when someone claims "the for-each loop always uses an iterator," that's only true for Iterable — not for arrays. Keep this distinction in mind: the rest of this article is about Iterable (and therefore about every Collection).

5. Why the loop cannot safely modify the collection

Now consider the natural next step — removing an element during iteration:

List<String> names = new ArrayList<>(
    List.of("Ali", "Ahmed", "Sabeer")
);

for (String name : names) {
    if (name.equals("Ali")) {
        names.remove(name);
    }
}

This looks harmless. But it produces:

Exception in thread "main" java.util.ConcurrentModificationException

The name is misleading. This is not about multiple threads. It happens on a single thread because the loop's Iterator and the list disagree about the state of the collection.

The Iterator keeps its own small piece of state — its position in the list. The list keeps its own state — its size and its internal array. When you call names.remove(...) directly, you modify the list without telling the iterator. The iterator then tries to keep walking based on stale assumptions. Java detects this mismatch and refuses to continue.

To understand exactly how the detection works, we need to look at fail-fast iterators.

6. Fail-fast iterators: modCount and expectedModCount

ArrayList (and most collections in java.util) does not just track its contents — it tracks how many times it has been structurally modified. That count is a field called modCount, inherited from AbstractList.

Each Iterator captures that count at the moment it is created:

private class Itr implements Iterator<E> {
    int cursor;                        // next index to return
    int lastRet = -1;                  // index of last returned element
    int expectedModCount = modCount;   // snapshot of modCount at creation

    public boolean hasNext() {
        return cursor != size;
    }

    public E next() {
        checkForComodification();
        int i = cursor;
        if (i >= size) throw new NoSuchElementException();
        cursor = i + 1;
        return (E) elementData[lastRet = i];
    }

    final void checkForComodification() {
        if (modCount != expectedModCount)
            throw new ConcurrentModificationException();
    }
}

The idea is simple:

• modCount — the collection's current "version number," incremented whenever the collection is structurally modified (elements added or removed).
• expectedModCount — the iterator's snapshot of that version, taken when the iterator was created.
• On every next(), the iterator checks: has the collection changed behind my back? If yes, it throws ConcurrentModificationException.

This is called fail-fast: the iterator fails quickly and loudly rather than returning garbage data or producing non-deterministic behavior later.

7. The subtlety: hasNext() does not check modCount

Look closely at ArrayList.Itr above. hasNext() only does:

return cursor != size;

There is no checkForComodification() call inside hasNext(). Only next() performs that check.

This is critical. It means that a direct structural modification during iteration does not always throw. Whether you get an exception or silent misbehavior depends entirely on whether the loop ends up calling next() again after the modification.

That single detail explains all three behaviors we'll see next: exception, clean exit, and silent skip.

8. Walkthrough: what happens if you remove the first, middle, or last element?

Let's trace the exact code paths with three cases. In every example:

List<String> names = new ArrayList<>(
    List.of("Ali", "Ahmed", "Sabeer")
);

// size = 3, elements at indices 0, 1, 2

The iterator starts with cursor = 0, expectedModCount = m.

Case A — Remove the first element ("Ali")

for (String name : names) {
    if (name.equals("Ali")) names.remove(name);
}

Case B — Remove the middle element ("Ahmed")

for (String name : names) {
    if (name.equals("Ahmed")) names.remove(name);
}

Case C — Remove the last element ("Sabeer")

for (String name : names) {
    if (name.equals("Sabeer")) names.remove(name);
}

Summary of the three cases

Both outcomes are bugs. One throws. One quietly produces wrong results. Neither is acceptable. The only safe way to remove during iteration is through the iterator itself or through APIs that use the iterator correctly.

9. What "structural modification" actually means

Only structural changes invalidate an iterator. On ArrayList:

• ✅ Structural: add, addAll, remove, removeAll, retainAll, clear, removeIf.
• ❌ Not structural: set(index, value), get, contains, size.

So this is fine:

for (String name : names) {
    // Replace, not add/remove
    // (assume we have an index or a reference we care about)
    // e.g., list.set(0, "X");
}

set does not touch modCount, so the iterator's snapshot remains valid.

On HashMap, structural changes are put with a new key, or remove of an existing key. Replacing the value of an existing key is not structural.

10. Concurrent collections: Java has two collection packages

Up to this point, every behavior we've discussed — fail-fast iterators, modCount, expectedModCount, ConcurrentModificationException — belongs to one package: java.util. That is the package that contains ArrayList, HashMap, HashSet, and most of the collections you use day to day.

But Java does not have just one collection framework. It has two.

These two packages were designed with different goals:

• java.util prioritizes speed in single-threaded code. Fail-fast iteration is cheap because it only compares two integers (modCount and expectedModCount).
• java.util.concurrent prioritizes safe concurrent access. The trade-off is that iteration does not reflect a single fixed snapshot — it reflects whatever state the collection happens to be in as you walk through it.

When someone says "modifying a collection during iteration throws ConcurrentModificationException," they are really saying "modifying a fail-fast collection in java.util during iteration throws ConcurrentModificationException." The rule does not extend to java.util.concurrent.

10.1 The java.util behavior: fail-fast iterators

Example: ArrayList.

The iterator keeps a snapshot of the list's modCount (its version number). Every time next() is called, it compares that snapshot with the current modCount. If they differ, it throws ConcurrentModificationException.

List<String> names = new ArrayList<>(
    List.of("Ali", "Ahmed", "Sabeer")
);


for (String name : names) {
    if (name.equals("Ali")) {
        names.remove(name);   // ← ConcurrentModificationException
    }
}

11. Safe ways to remove elements during iteration

There are exactly two patterns you should use. Both are safe. Both have their own edge cases.

11.1 Use Iterator.remove() explicitly

List<String> names = new ArrayList<>(
    List.of("Ali", "Ahmed", "Sabeer")
);

Iterator<String> it = names.iterator();

while (it.hasNext()) {
    String name = it.next();
    if (name.equals("Ahmed")) {
        it.remove();
    }
}

Why this works: ArrayList.Itr.remove() does two things that the naive list.remove(...) does not.

public void remove() {
    if (lastRet < 0)
        throw new IllegalStateException();

    checkForComodification();

    try {
        ArrayList.this.remove(lastRet);
        cursor = lastRet;          // <-- keep cursor aligned
        lastRet = -1;
        expectedModCount = modCount; // <-- resync the version
    } catch (IndexOutOfBoundsException ex) {
        throw new ConcurrentModificationException();
    }
}

The iterator updates its own cursor and refreshes its expectedModCount after the removal. The iterator stays in sync with the list. No exception, no skipped element.

11.2 Use removeIf() for simple conditions

names.removeIf(name -> name.equals("Ahmed"));
names.removeIf(name -> name.startsWith("A"));

removeIf is cleaner and expresses intent. Internally, ArrayList.removeIf is optimized: it scans once, builds a bitmap of the elements to delete, then compacts the array in a single pass. It does not use the public Iterator at all for ArrayList. For LinkedList it uses the iterator's remove(). Either way, it is safe.

11.3 Pitfalls of both approaches

Both Iterator.remove() and removeIf() can throw UnsupportedOperationException on collections that don't support removal. Common cases:

• List.of(...) — immutable.
• Arrays.asList(array) — fixed-size (can set, cannot add/remove).
• Collections.unmodifiableList(...) — read-only view.
• Collections.emptyList() — no elements, no removal.

So "use removeIf" is correct advice — but only when the collection actually supports removal.

Iterator.remove() also throws IllegalStateException if you call it:

• before the first next(), or
• twice in a row without an intervening next().

That's because remove() removes the last returned element — there has to be one, and it has to be fresh.

12. The mental model

Chain the pieces together in your head:

Collection
    │  extends
    ▼
Iterable ── iterator() ──► Iterator
                              │
                              │ used by
                              ▼
                         Enhanced for loop

And when you modify a fail-fast collection during iteration:

Iterator's expectedModCount  ≠  Collection's modCount
                    │
                    ▼
       fail-fast check on next()
                    │
         ┌───────────┴───────────┐
         ▼                       ▼
   throws CME               loop ends early / skips elements
      (bug)                       (also a bug)

So when you write:

for (String name : names) {
    // ...
}

Think: "Java is running an iterator behind the scenes."

And when you need to modify the collection during iteration:

• Simple conditional removal → removeIf(...)
• Removal with side effects or complex conditions → explicit Iterator + it.remove()
• Direct structural modification during a for-each over a fail-fast collection → ❌ never

13. Key takeaways

1. Collection extends Iterable. That's why the enhanced for loop works with collections.
2. For Iterable, the enhanced for loop is desugared into an iterator loop. For arrays, it is desugared into an indexed loop — no iterator.
3. Fail-fast iterators use modCount / expectedModCount. Only next() checks it; hasNext() does not.
4. Direct modification can throw or silently skip. Both are bugs. Which one you get depends on the position of the removed element relative to the iterator's cursor and the list's new size.
5. Structural modification ≠ every modification. set() is fine during iteration; add/remove are not.
6. ConcurrentModificationException is best-effort. It is not guaranteed for all collections. java.util.concurrent iterators are weakly consistent and never throw it.
7. The two safe ways to remove are Iterator.remove() and removeIf(). Both can throw UnsupportedOperationException on immutable or fixed-size collections.
8. Iterator.remove() must be called at most once per next(), or it throws IllegalStateException.

The enhanced for loop is not magic. It is a thin, elegant veneer over Iterator. Once you see the iterator underneath, every behavior — including the confusing ones like ConcurrentModificationException — becomes predictable.