Java Iterator 的底层原理与 Iterable 的设计美学

在日常的 Java 开发中，遍历集合是我们每天都在写的代码。自从有了增强 for 循环（for-each），很多人可能已经很久没有显式地写过 Iterator（迭代器）了。

“既然有更简洁的 for-each，为什么面试官总爱问 Iterator？为什么一边遍历一边删除时，程序总是无情地抛出 ConcurrentModificationException 异常？”

今天，我们就来彻底扒开 Java 集合遍历的底层外衣，重新认识这位隐藏在幕后的“向导”——Iterator，以及它背后的设计美学。

一、 语法糖的撕裂：for-each 的真面目

很多人喜欢用增强 for 循环，觉得它干净利落：

List<String> list = Arrays.asList("Java", "Go", "Python");
for (String lang : list) {
    System.out.println(lang);
}

但实际上，JVM 根本不认识 for-each 循环。这只是 Java 编译器提供的一颗“语法糖”。当你在编译这段代码时，编译器会自动把它翻译成如下的底层原貌：

Iterator<String> iterator = list.iterator();
while (iterator.hasNext()) {
    String lang = iterator.next();
    System.out.println(lang);
}

发现了吗？只要你遍历集合，你就永远在使用 Iterator。 它就像一个隐形的游标，默默地帮你在数据结构中穿梭。

二、 Iterator 的杀手锏：安全的“边走边删”

既然 for-each 底层就是 Iterator，那为什么我们在 for-each 循环里删除元素会报错呢？

来看这个经典的“踩坑”代码：

List<String> list = new ArrayList<>(Arrays.asList("A", "B", "C"));
for (String s : list) {
    if ("B".equals(s)) {
        list.remove(s); // ❌ 运行到这里直接抛出 ConcurrentModificationException！
    }
}

1. 为什么会崩溃？（Fail-Fast 机制）

集合的内部通常维护了一个叫做 modCount（修改次数）的变量。每次你调用 list.add() 或 list.remove()，modCount 都会加 1。

当我们生成一个 Iterator 时，它会偷偷记下当时的 modCount（存为 expectedModCount）。

• 在 for-each 循环中，你绕过了 Iterator，直接调用 list.remove()，导致集合的 modCount 变了。
• Iterator 下一次调用 next() 往前走时，一核对账本：“不对啊！现在的 modCount 怎么跟我手里的 expectedModCount 不一样了？有人偷偷动了数据！”
• 为了防止读到脏数据，Iterator 决定立刻自爆（Fail-Fast），抛出 ConcurrentModificationException。

2. 正确的做法：使用 Iterator.remove()

要想安全地删除，必须显式地请出 Iterator，并使用它自带的 remove() 方法：

Iterator<String> it = list.iterator();
while (it.hasNext()) {
    String s = it.next();
    if ("B".equals(s)) {
        it.remove(); // ✅ 安全删除
    }
}

底层原理： 当你调用 it.remove() 时，迭代器不仅会在底层的集合里删掉这个元素，还会自动把最新的 modCount 同步给自己手里的 expectedModCount。账本对上了，循环自然就能安全继续。

(注：在 Java 8 中，这种写法可以被更优雅的 list.removeIf(s -> "B".equals(s)) 替代，但其底层依然是依赖 Iterator 实现的。)

三、 Iterable 的设计美学：谁拥有遍历的特权？

在 Java 源码中，Iterator 是一个用来遍历的“工具对象”，而 Iterable 是一个接口，表示**“可迭代的能力”**。

Java 规定了一个至高无上的契约：凡是实现了 java.lang.Iterable 接口的类，都可以使用 for-each 循环，也都可以对外提供 Iterator。

我们来看看 Java 生态中不同角色对这一契约的遵守情况：

1. 忠实的践行者：Collection 家族

List、Set、Queue 这三大集合体系的父接口 Collection，直接继承了 Iterable 接口。因此，ArrayList、HashSet、PriorityQueue 等所有标准集合，天生就拥有遍历的特权。

2. 巧妙的侧面绕行：Map 家族

这是一个经典的面试易错点：Map 并没有实现 Iterable 接口！ 你不能直接对 Map 进行 for-each 遍历。
但 Map 的设计者非常聪明，它提供了三个视图（View）：

• map.keySet()（键集合）
• map.values()（值集合）
• map.entrySet()（键值对集合）

这三个视图返回的都是标准的 Collection 或 Set，因此我们通过“曲线救国”获得了 Map 的迭代器：

// 正确遍历 Map 的姿势
for (Map.Entry<String, Integer> entry : map.entrySet()) {
    System.out.println(entry.getKey() + ": " + entry.getValue());
}

3. 特权的旁落：原生数组（Array）

原生数组（如 int[]、String[]）在 JVM 底层并没有实现 Iterable 接口。那为什么数组也能用 for-each 循环？
这是因为编译器对数组做了特殊照顾。遇到数组的 for-each 时，编译器没有把它翻译成 Iterator，而是直接将其粗暴地翻译成了传统的基于下标的 for (int i=0; i<len; i++) 循环。

4. 权力的下放：自定义数据结构

理解了 Iterable 的设计美学，你就可以给自己的类赋予魔法。比如你写了一个“书架”类：

public class BookShelf implements Iterable<String> {
    private String[] books = {"Java核心技术", "Effective Java"};
    @Override
    public Iterator<String> iterator() {
        return Arrays.asList(books).iterator(); // 直接借用现成的迭代器
    }
}

仅仅加了这几行代码，别人在使用你的 BookShelf 类时，就可以直接使用优雅的增强 for 循环了！这种遵循标准接口契约的设计，正是 Java 面向对象设计的魅力所在。

四、 进阶：更强大的向导 ListIterator

普通的 Iterator 只能“一条路走到黑”（只能 next() 向前走），如果你在遍历 List，JDK 还为你准备了一个超级版的迭代器：ListIterator。

通过 list.listIterator() 获取后，你不仅可以：

1. 逆向行驶：通过 hasPrevious() 和 previous() 从后往前遍历。
2. 边走边加：通过 add() 在遍历到的当前位置动态插入新元素。
3. 原地掉包：通过 set() 直接替换刚刚遍历过的元素。

五、 最佳实践总结

最后，把日常开发中关于集合遍历的经验浓缩为三条“黄金法则”：

1. 普通的只读遍历：永远优先使用增强 for 循环（for-each），代码最干净可读。
2. 需要根据条件删除元素：
   • Java 8 及以上：无脑使用 list.removeIf(...)。
   • Java 8 以下，或逻辑极其复杂：老老实实写 while 配合 Iterator.remove()。
3. 需要在遍历中做增删改的复杂操作（仅限 List）：请出终极武器 ListIterator。

懂了 Iterator，你就懂了 Java 集合框架流转的命脉。下次再面对 ConcurrentModificationException，相信你已经可以相视一笑，信手拈来地解决它了。

做增删改的复杂操作（仅限 List）**：请出终极武器 ListIterator。

懂了 Iterator，你就懂了 Java 集合框架流转的命脉。下次再面对 ConcurrentModificationException，相信你已经可以相视一笑，信手拈来地解决它了。

到此这篇关于Java Iterator 的底层原理与 Iterable 的设计美学的文章就介绍到这了,更多相关java Iterator与 Iterable内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论