Demonstrate a bug caused by a shared mutable ArrayList inside forEach of a parallel stream

• ArrayList is not thread-safe: add mutates the size field and the internal element array without locking.
• Concurrent adds interleave badly: multiple threads writing simultaneously cause lost updates, null entries, or resize races.
• Symptoms are non-deterministic: the result list is shorter than expected, contains nulls, or throws ArrayIndexOutOfBoundsException.
• Intermittent failure makes this dangerous: it may pass in tests and fail in production.
• Root cause is sharing mutable state across threads with no synchronization.

What is the bug?

The bug is calling list.parallelStream().forEach(results::add) where results is a shared ArrayList. Multiple threads call ArrayList.add simultaneously, but ArrayList is not thread-safe. The add method mutates an internal size field and an element array without any synchronization, so concurrent calls interleave and corrupt the list.

How do you demonstrate it?

package com.bank.hr;

import java.math.BigDecimal;
import java.util.*;
import java.util.stream.IntStream;

public class ParallelRaceCondition {

    public static void main(String[] args) {
        List<String> accountIds = IntStream.rangeClosed(1, 10_000)
            .mapToObj(i -> "SAV" + i)
            .toList();

        // WRONG: shared mutable ArrayList with parallel forEach
        List<String> results = new ArrayList<>();
        accountIds.parallelStream().forEach(results::add);

        System.out.println("Expected: " + accountIds.size());
        System.out.println("Actual:   " + results.size());
        System.out.println("Has nulls: " + results.contains(null));
    }
}

Expected: 10000
Actual:   9847
Has nulls: true

The actual count varies on every run. Sometimes it throws ArrayIndexOutOfBoundsException instead.

Why does this happen internally?

When two threads call ArrayList.add at the same time:

1. Both read the current size (say 5).
2. Both write their element to elementData[5].
3. Both increment size to 6.
4. Result: one element is lost, and the list has a null gap or a corrupted index.

During a resize, the race is worse: one thread copies the array while another writes to the old array, causing ArrayIndexOutOfBoundsException.

What are common mistakes?

Mistake: Trying to fix it by synchronizing the list.

// WRONG approach: wrapping in synchronized list
List<String> syncList = Collections.synchronizedList(new ArrayList<>());
accountIds.parallelStream().forEach(syncList::add);
// Works but defeats the purpose of parallelism (serializes all adds)

// CORRECT approach: use collect
List<String> correct = accountIds.parallelStream()
    .collect(java.util.stream.Collectors.toList());
// Framework manages per-thread accumulators, no shared state

How does collect solve the problem?

collect(Collectors.toList()) uses the collector's supplier-accumulator-combiner contract. In parallel:

1. Supplier creates a separate ArrayList per thread.
2. Accumulator adds elements to the thread-local list (no sharing).
3. Combiner merges the per-thread lists at the end.

No thread ever touches shared mutable state, so there is no race.

How is forEach different from collect in parallel?

| Aspect | forEach(list::add) | collect(toList()) |
|---|---|---|
| Thread safety | Not safe: shared mutable state | Safe: per-thread accumulators |
| Result | Corrupt, non-deterministic | Correct, deterministic content |
| Approach | Side-effect (mutates external state) | Functional (framework manages state) |
| Fix needed | Requires synchronization | None: designed for parallel |

What about using CopyOnWriteArrayList?

// Thread-safe but extremely slow for frequent writes
List<String> cowList = new java.util.concurrent.CopyOnWriteArrayList<>();
accountIds.parallelStream().forEach(cowList::add);
// Each add copies the entire array: O(n) per add, O(n^2) total

This is correct but defeats the purpose: collect is both correct and efficient.

What should a senior engineer know?

The correct instinct is never to synchronize a plain list for parallel stream use. Instead, stop sharing mutable state entirely and use collect, which the stream framework manages safely. Side-effecting into external collections from streams, especially parallel ones, violates the side-effect-free guideline. Naming the non-determinism as a data race on shared mutable state is the insight an interviewer listens for.

What are common interview follow-up questions?

• "How do you fix it?" Use collect(Collectors.toList()) instead of forEach(list::add).
• "Would a synchronized list work?" Yes for correctness, but it serializes all adds and kills parallel performance.
• "Why is the bug intermittent?" The race window depends on timing, data size, and JVM thread scheduling.
• "What exception can it throw?" ArrayIndexOutOfBoundsException during an internal array resize race.