forEach中禁止修改集合结构，否则触发ConcurrentModificationException；应改用removeIf()或倒序for循环；removeIf的Predicate不可含副作用；ArrayList的removeIf性能远优于LinkedList；Stream.filter仅适用于需转换或并行处理场景。
forEach 里别改集合结构，否则直接 ConcurrentModificationException
Java 的 forEach 是只读遍历，底层用的是 Iterator 的“快速失败”机制。一旦在 lambda 里调用 list.remove() 或 list.add()，运行时立刻抛 ConcurrentModificationException——这不是并发问题，是单线程下迭代器自己拦的。
常见错误写法：
list.forEach(item -> { if (item.isExpired()) list.remove(item); }); // ❌ 立马崩
正确做法只有两个：
- 用
removeIf()做条件删除（推荐） - 用传统
for (int i = list.size()-1; i >= 0; i--)倒序删（兼容老 JDK）
removeIf 的 predicate 别写副作用逻辑
removeIf() 接收一个 Predicate，它只该返回 boolean，不该修改外部状态、不触发 I/O、不抛业务异常。一旦 predicate 抛出非 RuntimeException（比如 IOException），编译就过不去——因为 Predicate 的 test() 方法不声明受检异常。
容易踩的坑：
-
removeIf(x -> { log.info(x); return x.isStale(); })—— 日志可以，但别在里面改数据库或发 HTTP -
removeIf(x -> x.getName().trim().isEmpty())—— 没问题；但removeIf(x -> Files.deleteIfExists(x.getPath()))就越界了 - 如果真要带异常处理，先封装成不抛受检异常的工具方法，再传进去
ArrayList 和 LinkedList 对 removeIf 的性能差异很大
removeIf() 在 ArrayList 上是 O(n) 时间 + O(1) 额外空间：它用双指针原地移动有效元素，最后一次性 Arrays.fill() 清尾部。
但在 LinkedList 上是 O(n²)：因为每次删节点都要从头/尾找前驱，无法跳转。实测 10 万元素删 30%，ArrayList 耗时约 2ms，LinkedList 可能超 300ms。
所以：
- 除非你频繁在头部插入/删除且极少遍历，否则别用
LinkedList存业务数据 - 不确定用哪种？默认选
ArrayList，removeIf才不会突然变慢 - 如果必须用
LinkedList，且要批量删，先转成ArrayList再removeIf，完事再转回（仅当数据量小时可行）
Stream.filter + collect 适合需要转换+过滤的场景，不是 removeIf 的替代品
有人看到 removeIf 就想统一换成 stream().filter(...).collect(...)，这反而可能引入三重问题：
- 新建集合对象，内存翻倍（尤其大列表）
- 原集合没变，如果其他地方还持引用，会出现“以为删了其实没删”的逻辑错
-
Collectors.toList()返回的是不可变视图（JDK 16+）或新ArrayList，类型和线程安全性都变了
只在这些情况才该用 stream：
- 要同时 map + filter（比如
stream().map(User::getName).filter(Objects::nonNull).collect(...)） - 需要并行处理（
parallelStream()），且元素间无依赖 - 原集合本就是只读的，且你明确需要一个全新副本
单纯删元素，removeIf 更轻、更直接、更符合语义。
