Java 8 Stream处理List时，如何避免ConcurrentModificationException？

Question

在使用 Java 8 Stream 处理 List 时，若在流操作（如 `forEach`、`peek`）中**直接修改原集合**（例如 `list.removeIf(...)` 之外的 `list.remove()` 或 `list.add()`），极易触发 `ConcurrentModificationException`。这是因为 Stream 的底层 Spliterator 默认基于 fail-fast 机制校验结构性修改——即使单线程环境下，只要迭代过程中 List 被非迭代器方式修改，就会抛出该异常。常见误用包括：在 `stream().forEach(e -> list.remove(e))` 或 `parallelStream().peek(list::add)` 中变更原列表。值得注意的是，`removeIf()`、`replaceAll()` 等 List 自带的批量操作是安全的，但它们不属于 Stream 操作；而 `Collectors.toList()` 等终端操作仅生成新集合，不修改原列表。因此核心原则是：**Stream 应视为只读视图，所有结构性修改必须在流外独立进行，或通过收集为新集合后整体替换**。如何在保持函数式风格的同时安全实现“过滤并更新原列表”？这是开发者常遇到的典型矛盾点。

Answer 1

```html

一、现象层：典型错误代码与异常复现

以下是最常被复制粘贴却隐含致命风险的“伪函数式”写法：

List<String> list = new ArrayList<>(Arrays.asList("a", "b", "c", "d"));
list.stream().forEach(s -> {
    if (s.equals("b")) list.remove(s); // ⚠️ ConcurrentModificationException!
});

运行时抛出：java.util.ConcurrentModificationException，堆栈指向 Spliterators$IteratorSpliterator.forEachRemaining。根本原因在于：ArrayList 的 Spliterator 继承自 AbstractList 的 fail-fast 机制，其 expectedModCount 在构造时冻结，任何非迭代器路径的 modCount 变更（如 list.remove()）都会触发校验失败。

二、机制层：Stream 与 List 结构性一致性校验原理

Java 8 Stream 并非简单封装 for-each，其底层依赖 Spliterator 提供分片与遍历能力。以 ArrayList.spliterator() 为例：

• 构造时缓存当前 modCount 到 expectedModCount
• 每次 tryAdvance() 前调用 checkForComodification()
• 该方法严格比对 modCount != expectedModCount → 立即抛异常

注意：此机制不区分线程上下文，单线程下同样生效——这是设计使然，旨在暴露逻辑矛盾而非仅解决并发问题。

三、对比层：安全 vs 危险操作矩阵

操作类型	是否在 Stream 中调用	是否修改原 List	是否安全	说明
list.removeIf(Predicate)	否（流外）	是	✅ 安全	内部使用 Iterator.remove()，同步更新 expectedModCount
stream().filter(...).collect(toList())	是	否	✅ 安全	纯函数式，生成新列表
stream().peek(list::add)	是	是	❌ 危险	破坏 Spliterator 一致性，必抛 CME
list.replaceAll(UnaryOperator)	否	是	✅ 安全	原子批量替换，不触发结构性变更检测

四、范式层：四大安全演进路径

1. 收集后整体替换：保持函数式语义，牺牲原引用但语义清晰
   list = list.stream().filter(e -> !e.startsWith("tmp")).collect(Collectors.toCollection(ArrayList::new));
2. 流外委托删除：利用 removeIf + 函数式谓词
   list.removeIf(e -> e.length() == 1 && e.matches("[aeiou]"));
3. 索引式批量更新：结合 IntStream.range 与 set()
IntStream.range(0, list.size()).filter(i -> condition(list.get(i))).forEach(i -> list.set(i, transform(list.get(i))));
4. 不可变中间态建模：引入 Record 或 ImmutableList（如 Guava）避免副作用

五、架构层：面向演化的函数式重构策略

当业务要求“过滤并更新原列表”，本质是状态变更需求与声明式表达的张力。成熟团队应建立分层契约：

graph TD
    A[原始 List] --> B{流式处理}
    B -->|filter/map/peek| C[只读视图]
    C --> D[Collectors.toList()]
    D --> E[新 List]
    E --> F[原子替换 list = newList]
    F --> G[发布变更事件]
    G --> H[下游监听器响应]

该流程将“副作用”收敛至终端赋值点，符合命令查询分离（CQS）原则；同时通过事件驱动解耦状态变更与业务逻辑，为未来迁移到响应式编程（如 Project Reactor）预留接口。

六、实战层：高可靠工具方法封装

推荐在通用工具类中沉淀如下静态方法（兼顾可读性、线程安全与 JDK 兼容性）：

public final class ListOps {
    public static <T> void filterInPlace(List<T> list, Predicate<T> predicate) {
        Objects.requireNonNull(list);
        list.removeIf(t -> !predicate.test(t)); // 复用 JVM 优化的 removeIf
    }

    public static <T> void updateInPlace(List<T> list, Function<T, T> mapper) {
        list.replaceAll(mapper); // 底层无结构性修改，仅元素级替换
    }

    public static <T> List<T> filteredCopy(List<T> list, Predicate<T> predicate) {
        return list.stream().filter(predicate).collect(Collectors.toUnmodifiableList());
    }
}

调用示例：ListOps.filterInPlace(users, u -> u.isActive()); —— 零异常风险，零额外 GC，且语义即实现。

```