التكرار وConcurrentModificationException

Written Explanation

What for-each really does

For a collection, for (String s : list) is shorthand for asking the collection for an iterator, an object that walks the elements, and repeating hasNext() and next() until there is nothing left.

Iterator<String> it = list.iterator();
while (it.hasNext()) {
    String s = it.next();
    // your loop body
}

The iterator remembers where it is. If the collection changes behind its back, its memory is wrong.

Why removing inside for-each fails

ArrayList (like most collections in java.util) has fail-fast iterators. The documentation says that if the list is structurally modified after the iterator is created, in any way except through the iterator's own remove or add, the iterator throws a ConcurrentModificationException. "Structurally modified" means the size changed: add or remove. Replacing an element with set is not a structural change.

The name is misleading. The documentation says the exception does not always mean another thread was involved. Here there is only one thread, and the loop itself modified the list it was iterating over.

List<Integer> nums = new ArrayList<>(List.of(4, -1, 7, -3, 5));
for (Integer n : nums) {
    if (n < 0) nums.remove(n);   // modifies the list the loop is using
}

The first removal succeeds, and the loop's next call to next() notices the change and throws. The real trace on JDK 21 begins Exception in thread "main" java.util.ConcurrentModificationException and points at the for line, not at the remove line. That is worth remembering when you debug: the crash is reported where the loop continues, not where the damage was done.

The silent version

The exception is raised on a best-effort basis; the documentation says it should be used only to detect bugs and never be relied upon for correctness. A well-known consequence: removing the second-to-last element does not throw, because after the removal hasNext() already says "no more" and next() is never called to check. Example: remove "b" from [a, b, c] inside a for-each and you get [a, c] with no error. Remove "a" from the same list and it crashes. Same bug, different luck. Never conclude "it works" because one test did not throw.

Fix 1: the Iterator and it.remove()

Use the iterator explicitly, and remove through the iterator:

Iterator<Integer> it = nums.iterator();
while (it.hasNext()) {
    int n = it.next();
    if (n < 0) it.remove();
}

it.remove() removes the element most recently returned by next() and keeps the iterator's bookkeeping correct. Call next() first, then remove() at most once per next().

Fix 2: removeIf

Collection has a method removeIf that takes a condition and removes every matching element in one call:

nums.removeIf(n -> n < 0);

The part n -> n < 0 is a lambda expression: a tiny piece of code passed as a value, read as "for each n, test n < 0". Lambdas are taught properly in BEG-035; here, treat it as a preview and copy the pattern. removeIf works on lists, sets, and queues. By the documentation, its default implementation iterates and calls Iterator.remove, so it is the iterator fix with less typing. It also fails with UnsupportedOperationException on an unmodifiable collection such as List.of(...) when there is a match to remove, and the exception is the same one from Lesson 2.

Fix 3: build a new collection

Often the simplest, clearest option is to leave the original alone and collect what you keep:

List<Integer> kept = new ArrayList<>();
for (int n : nums) {
    if (n >= 0) kept.add(n);
}

This costs a little memory but is easy to read and also works when the source is unmodifiable. It is a good default when the original should not change.

Fix 4 (lists only): loop backwards by index

If you loop with an index from the end towards 0, removals only shift elements you have already visited:

for (int i = nums.size() - 1; i >= 0; i--) {
    if (nums.get(i) < 0) nums.remove(i);
}

It works, but it is easy to get wrong with List<Integer> (the remove(int) versus remove(Object) trap from Lesson 2), so prefer the iterator or removeIf. A forward index loop is the other broken pattern: removing at index i shifts the next element into i, and the loop then skips it.

Maps and sets

Sets work exactly like lists: use an iterator or removeIf. For a Map, loop over a view and remove through its iterator, or use removeIf on a view:

Iterator<Map.Entry<String, Integer>> it = stock.entrySet().iterator();
while (it.hasNext()) {
    if (it.next().getValue() == 0) it.remove();
}
// or: stock.values().removeIf(v -> v == 0);

Changing a map's size (put of a new key, or remove) while iterating over keySet() or entrySet() also throws ConcurrentModificationException. Changing the value of an existing key with put is not a structural change, so it is fine inside the loop. Removal through the view or its iterator writes through to the map, because views are backed by it.