Java迭代器遍历安全吗？机制详解

目前golang学习网上已经有很多关于文章的文章了，自己在初次阅读这些文章中，也见识到了很多学习思路；那么本文《Java迭代器遍历安全吗？详解机制》，也希望能帮助到大家，如果阅读完后真的对你学习文章有帮助，欢迎动动手指，评论留言并分享~

Iterator遍历中修改集合会抛ConcurrentModificationException，因fail-fast机制通过modCount与expectedModCount比对检测并发修改；仅iterator.remove()安全，且需先调用next()；多线程下即使只读也可能触发异常；应选用CopyOnWriteArrayList或ConcurrentHashMap等并发容器。

Iterator遍历过程中修改集合会抛ConcurrentModificationException

不安全。Java 的 Iterator 默认是“快速失败”（fail-fast）机制，只要在遍历时通过集合本身（如 list.add()、set.remove()）修改结构，下一次调用 iterator.next() 或 iterator.hasNext() 就会立即抛出 ConcurrentModificationException。

这是设计使然，不是 bug —— 它靠维护一个 modCount（修改计数器）和 expectedModCount（迭代器预期值）比对来检测并发修改。

• 仅通过 iterator.remove() 是安全的，它会同步更新 expectedModCount
• forEachRemaining() 同样受保护，内部也走的是迭代器自己的删除逻辑
• 多线程环境下即使只读，若另一线程修改了集合，仍可能触发异常（取决于具体实现和时机）

想边遍历边删元素？必须用iterator.remove()

不能用 for-each 循环配合 collection.remove()，也不能在普通 for (int i = 0; ...) 中正向遍历时 remove(i)（会跳过下一个元素）。

List list = new ArrayList<>(Arrays.asList("a", "b", "c", "b"));
Iterator it = list.iterator();
while (it.hasNext()) {
    String s = it.next();
    if ("b".equals(s)) {
        it.remove(); // ✅ 唯一安全的删除方式
    }
}
// 结果：["a", "c"]

• 使用 it.remove() 前必须已调用过 it.next()，否则抛 IllegalStateException
• 每个 next() 最多对应一次 remove()，重复调用会报错
• 如果需要删除多个匹配项，removeIf() 更简洁（但底层仍是基于迭代器）

CopyOnWriteArrayList 和 ConcurrentHashMap 是为并发遍历设计的

标准 ArrayList、HashMap 的迭代器都不支持遍历时并发修改；若业务确实需要「读多写少 + 遍历中可能被改」，应换并发容器：

• CopyOnWriteArrayList：遍历时操作的是快照，增删不影响当前迭代器，但写操作开销大、不适用于高频修改场景
• ConcurrentHashMap：其 keySet().iterator() 不抛 CME，但不保证反映最新全部修改（弱一致性），适合统计类遍历
• Vector 或 Hashtable 的迭代器仍是 fail-fast 的，**不是**线程安全替代方案

增强for循环（for-each）本质就是Iterator，风险完全一致

for (String s : list) 编译后等价于显式获取 iterator() 并调用 hasNext()/next()，所以：

List list = new ArrayList<>(Arrays.asList("x", "y"));
for (String s : list) {
    if ("x".equals(s)) {
        list.remove(s); // ❌ 这里没报错，但下一轮 next() 时抛 ConcurrentModificationException
    }
}

• 错误常发生在循环体末尾或条件分支里，看起来“还没走到下一次”，实际异常延迟抛出
• IDE（如 IntelliJ）通常会警告 “Collection is modified while iterating”
• 调试时注意：异常栈顶是 next() 或 hasNext()，不是你写的 remove() 那行

真正麻烦的不是记不住规则，而是某些框架（比如 MyBatis 的 foreach 标签、Spring 的 @EventListener 批量处理）会隐式触发迭代，而你在回调里又去改原集合 —— 这种链路里的 CME 很难一眼定位。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。