Java遍历List的四种方法

Java遍历List看似简单，实则暗藏玄机：从传统for循环中为何必须每次调用list.size()以保障语义安全，到增强for底层依赖Iterator却无法安全删除元素；从Iterator.remove()如何通过同步modCount绕过fail-fast机制实现线程内安全修改，到Lambda forEach与Stream forEach在执行顺序、线程行为和异常处理上的根本差异——每种方式的选择都紧密耦合着集合实现（如ArrayList随机访问快、LinkedList遍历慢）、并发场景和JVM规范。一个看似微小的缓存size或误用remove，可能在日常测试中安然无恙，却在高并发压测时突然崩溃，真正考验的是对Java集合底层机制的深度理解。

用 for 循环遍历 List 时，为什么 list.size() 要在每次迭代中重新调用？

因为 List 实例可能在遍历过程中被其他线程或代码逻辑修改（比如删除元素），导致索引越界或跳过元素。虽然多数场景下 size() 是 O(1)，但关键不是性能，而是语义安全——它保证你始终按当前真实长度访问。

常见错误是提前缓存 int len = list.size()，然后用 i 判断，这在并发或中间有 remove() 时会出错。

• 只在确定集合不会被修改时才缓存 size()
• 若需边遍历边删除，改用 Iterator.remove()，而不是 list.remove(i)
• 对 LinkedList，用 get(i) 是 O(n) 复杂度，此时 for 循环效率远低于迭代器

增强 for 循环（for-each）底层到底调用了什么？

编译后等价于显式使用 Iterator：调用 list.iterator() 获取迭代器，再反复调用 hasNext() 和 next()。这意味着它天然支持所有实现了 Iterable 接口的集合，但不暴露迭代器本身。

陷阱在于：无法在循环体内调用 list.remove()，否则抛 ConcurrentModificationException；想删除必须用 Iterator.remove()，而增强 for 不提供该引用。

• 适合只读遍历，代码简洁可读性高
• 对 ArrayList 性能接近传统 for；对 LinkedList 更优（避免了随机访问开销）
• 不能获取当前索引，也不能在循环中修改集合结构

Iterator 遍历时调用 remove() 为什么比 list.remove(Object) 安全？

因为 Iterator.remove() 是唯一被允许在迭代过程中修改集合的方式，它会同步更新内部 modCount 和 expectedModCount，从而绕过快速失败（fail-fast）检查。

Iterator<String> it = list.iterator();
while (it.hasNext()) {
    String s = it.next();
    if (s.startsWith("A")) {
        it.remove(); // ✅ 合法且高效
    }
}

• list.remove(s) 会触发 modCount 变更，但迭代器不知情，下次 next() 就抛异常
• Iterator.remove() 只能删除上一次 next() 返回的元素，不能连续调两次
• 对 CopyOnWriteArrayList，Iterator.remove() 是空操作（不支持），此时只能用普通 remove()

Lambda 的 forEach() 和 Stream 的 forEach() 有什么本质区别？

前者是 Iterable.forEach() 默认方法，直接委托给 Iterator；后者是 Stream 的终端操作，底层可能并行（取决于是否调用 parallelStream()），且有短路、延迟执行等特性。

最易忽略的一点：Stream 的 forEach() **不保证顺序**（即使在顺序流中，JVM 也不强制规定执行顺序），而 Iterable.forEach() 严格按集合顺序执行。

• 多线程环境下，list.forEach(System.out::println) 是线程安全的（只要 list 本身不被并发修改）
• list.stream().forEach(...) 在并行流中可能乱序，需用 forEachOrdered() 强制顺序
• Stream 版本无法在 lambda 中抛受检异常，必须包装成 RuntimeException

本篇关于《Java遍历List的四种方法》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！