遍历ArrayList时调用remove()会抛ConcurrentModificationException，因其迭代器为fail-fast机制，通过modCount检测非迭代器途径的结构性修改。
为什么遍历 ArrayList 时调用 remove() 会抛 ConcurrentModificationException
因为 ArrayList 的迭代器是“快速失败”（fail-fast）的：内部维护一个 modCount 计数器，每次调用 add()、remove() 等结构性修改方法时自增；而迭代器在 next() 前会检查当前 modCount 是否与创建时一致。不一致就直接抛异常——它不关心你是不是单线程，只认“非迭代器途径修改”这个事实。
常见错误现象：
- 用 for-each 循环遍历
list，循环体内写list.remove(obj) - 用
Iterator.next()遍历，但调用的是list.remove()而不是iterator.remove() - 多个线程共用一个
ArrayList，哪怕只读不写，只要有一个线程在修改，其他线程迭代就可能崩
单线程下安全删除元素的三种写法
核心原则：别绕过迭代器改集合本身。
- 用
Iterator.remove()—— 最常用也最直观：Iterator<String> it = list.iterator(); while (it.hasNext()) { String s = it.next(); if (s.startsWith("tmp")) { it.remove(); // ✅ 安全 } } - 倒序 for 循环 + 索引删除 —— 适合需要索引或批量删固定位置的场景：
for (int i = list.size() - 1; i >= 0; i--) { if (list.get(i).startsWith("tmp")) { list.remove(i); // ✅ 不影响前面元素索引 } } - 收集待删项，遍历完再批量删 —— 适合条件复杂、要多次判断的逻辑：
List<String> toRemove = new ArrayList<>(); for (String s : list) { if (needRemove(s)) toRemove.add(s); } list.removeAll(toRemove); // ✅ removeAll 内部不走迭代器路径
多线程环境该选哪个并发集合
别给 ArrayList 加 synchronized 包装器——锁粒度太粗，性能差，且仍无法避免迭代时被其他线程修改。
立即学习“Java免费学习笔记（深入）”；
- 读多写少，且允许弱一致性（比如监控列表）：用
CopyOnWriteArrayList
每次写都复制底层数组，迭代器基于快照，完全不加锁；但写操作开销大，不适合高频修改 - 读写均衡，需强一致性：用
ConcurrentHashMap替代“键值对集合”，或封装成线程安全的容器类ConcurrentLinkedQueue适合纯队列场景，但不支持随机访问 - 真需要线程安全的动态数组语义，又不愿妥协性能：考虑
java.util.concurrent.ForkJoinPool配合不可变集合（如ImmutableList），靠“替换引用”而非“原地修改”来规避问题
removeIf() 看似方便，但要注意 JDK 版本和实现细节
ArrayList.removeIf() 是 JDK 8 引入的默认方法，底层用的是 Iterator.remove()，所以单线程下是安全的；但它不是原子操作——中间如果其他线程修改了集合，仍可能触发 ConcurrentModificationException（即使你在调用 removeIf()）。
- JDK 8–10：
removeIf()在ArrayList中会先遍历收集匹配索引，再倒序删除，实际是“两阶段”，比手写Iterator稍慢但更简洁 - JDK 11+：优化为单次遍历 + 位图标记，性能更好，但行为一致
- 注意：它对
LinkedList的实现是逐个调用Iterator.remove()，所以链表场景下不要依赖它做高频删除
真正容易被忽略的是：所有这些方案都假设你知道“什么时候要删”，而不是在监听器、回调、Stream 中隐式触发修改——那种场景下，得回溯源头，把修改动作挪到迭代生命周期之外。
