增强for循环底层调用迭代器，是编译期语法糖，等价于显式使用iterator的hasnext()和next()方法；遍历时直接修改集合会抛concurrentmodificationexception。
增强for循环底层调用的是迭代器
Java中for (Type item : collection)不是独立语法，而是编译期语法糖，实际被编译为显式调用Iterator的hasNext()和next()方法。只要集合类实现了Iterable接口（即提供iterator()方法），就能用增强for遍历。
常见错误现象：在遍历过程中直接调用collection.remove(item)会抛ConcurrentModificationException——因为增强for隐含的迭代器检测到了结构性修改。
- 数组也能用增强for，是因为编译器对数组做了特殊处理，转为基于索引的普通
for循环，不走Iterator -
LinkedList、ArrayList、HashSet等都实现了Iterable，所以天然支持 - 自定义类若想支持增强for，必须实现
Iterable<t></t>并返回合法Iterator<t></t>
编译后字节码对应标准迭代器模式
以下Java代码：
for (String s : list) {
System.out.println(s);
}
等价于编译器生成的逻辑：
立即学习“Java免费学习笔记（深入）”；
Iterator<String> $iter = list.iterator();
while ($iter.hasNext()) {
String s = $iter.next();
System.out.println(s);
}
注意：$iter是编译器生成的临时变量名，不可在源码中引用；且该变量作用域严格限定在增强for语句块内。
- 无法在增强for中获取当前索引，除非额外声明计数器变量
- 不能在循环体中调用
$iter.remove()——语法上不暴露这个Iterator实例 - 若需安全删除元素，必须手动写
Iterator并调用其remove()方法
增强for不适用于需要并发修改或索引控制的场景
当业务逻辑涉及「边遍历边删」或「根据下标做条件判断」时，增强for不仅表达力不足，还容易引发异常或逻辑错误。
典型错误示例：
for (String s : list) {
if (s.startsWith("tmp")) {
list.remove(s); // ❌ 触发 ConcurrentModificationException
}
}
正确做法是显式使用迭代器：
Iterator<String> iter = list.iterator();
while (iter.hasNext()) {
String s = iter.next();
if (s.startsWith("tmp")) {
iter.remove(); // ✅ 安全删除
}
}
- 增强for本质是只读遍历抽象，编译器禁止你在循环体内修改集合结构
- 对
CopyOnWriteArrayList这类线程安全集合，增强for虽不会抛异常，但看到的可能是快照，非实时状态 - 性能上无额外开销——语法糖抹平了迭代器创建成本，和手写几乎一致
反编译验证是最直接的理解方式
写一个简单类，用javac编译后，用javap -c查看字节码，能清晰看到iterator()、hasNext()、next()的调用链。这是确认“它到底怎么工作的”最可靠手段，比查文档更快更准。
容易被忽略的一点：泛型擦除后，Iterator.next()返回的是Object，编译器自动插入类型强转（如(String)），若运行时实际类型不符，会在循环第一次调用next()后立即抛ClassCastException——这个异常位置常让人误以为是集合初始化问题。
