哪个更有效，for-each 循环还是迭代器？

Question

遍历集合的最有效方法是什么？

List<Integer>  a = new ArrayList<Integer>();
for (Integer integer : a) {
  integer.toString();
}

或

List<Integer>  a = new ArrayList<Integer>();
for (Iterator iterator = a.iterator(); iterator.hasNext();) {
   Integer integer = (Integer) iterator.next();
   integer.toString();
}

请注意，这不是 this、this、this 或 this 的完全重复，尽管最后一个问题的答案之一很接近。这不是骗局的原因是，其中大多数是比较循环，您在循环内调用 get(i)，而不是使用迭代器。

按照Meta 的建议，我将发布我对这个问题的答案。

Answer 1

foreachunderhood 正在创建iterator，调用 hasNext() 并调用 next() 获取值；仅当您使用实现 RandomomAccess 的东西时，才会出现性能问题。

for (Iterator<CustomObj> iter = customList.iterator(); iter.hasNext()){
   CustomObj custObj = iter.next();
   ....
}

基于迭代器的循环的性能问题是因为它是：

1. 即使列表为空也分配对象 (Iterator<CustomObj> iter = customList.iterator();)；
2. iter.hasNext() 在循环的每次迭代中都有一个 invokeInterface 虚拟调用（遍历所有类，然后在跳转前进行方法表查找）。
3. 迭代器的实现必须至少进行 2 个字段查找，以使 hasNext() 调用图的值：#1 获取当前计数，#2 获取总计数
4. 在主体循环内部，还有另一个invokeInterface 虚拟调用iter.next（所以：在跳转之前遍历所有类并进行方法表查找）并且还必须进行字段查找：#1 获取索引和# 2 获取对数组的引用以对其进行偏移（在每次迭代中）。

一个潜在的优化是使用缓存大小查找切换到index iteration：

for(int x = 0, size = customList.size(); x < size; x++){
  CustomObj custObj = customList.get(x);
  ...
}

我们有：

1. 一个invokeInterface虚拟方法调用customList.size()在for循环初始创建时获取大小
2. 在for循环体中调用get方法customList.get(x)，这是对数组的字段查找，然后可以对数组进行偏移

我们减少了大量的方法调用和字段查找。这是你不想用LinkedList 或不是RandomAccess 集合obj 的东西，否则customList.get(x) 会变成每次迭代都必须遍历LinkedList 的东西。

当您知道这是任何基于 RandomAccess 的列表集合时，这是完美的。

Answer 2

foreach 在底层使用迭代器。它实际上只是语法糖。

考虑以下程序：

import java.util.List;
import java.util.ArrayList;

public class Whatever {
    private final List<Integer> list = new ArrayList<>();
    public void main() {
        for(Integer i : list) {
        }
    }
}

让我们用javac Whatever.java编译它，
并读取main()的反汇编字节码，使用javap -c Whatever：

public void main();
  Code:
     0: aload_0
     1: getfield      #4                  // Field list:Ljava/util/List;
     4: invokeinterface #5,  1            // InterfaceMethod java/util/List.iterator:()Ljava/util/Iterator;
     9: astore_1
    10: aload_1
    11: invokeinterface #6,  1            // InterfaceMethod java/util/Iterator.hasNext:()Z
    16: ifeq          32
    19: aload_1
    20: invokeinterface #7,  1            // InterfaceMethod java/util/Iterator.next:()Ljava/lang/Object;
    25: checkcast     #8                  // class java/lang/Integer
    28: astore_2
    29: goto          10
    32: return

我们可以看到foreach 编译成一个程序：

• 使用List.iterator() 创建迭代器
• 如果Iterator.hasNext()：调用Iterator.next()并继续循环

---

至于“为什么这个无用的循环没有从编译后的代码中得到优化？我们可以看到它对列表项没有任何作用”：嗯，你可以编写你的迭代代码这样@ 987654333@ 有副作用，或者说.hasNext() 有副作用或有意义的后果。

您可以很容易地想象，表示来自数据库的可滚动查询的迭代可能会在 .hasNext() 上做一些戏剧性的事情（比如联系数据库，或者因为您已经到达结果集的末尾而关闭游标）。

因此，即使我们可以证明循环体中没有发生任何事情……但证明在我们迭代时没有发生任何有意义/后果性的事情会更加昂贵（难以处理？）。编译器必须将这个空循环体留在程序中。

我们所能期望的最好的结果就是编译器警告。有趣的是，javac -Xlint:all Whatever.java 确实没有警告我们这个空循环体。 IntelliJ IDEA 可以。诚然，我已将 IntelliJ 配置为使用 Eclipse 编译器，但这可能不是原因。

Answer 3

Iterator 是 Java Collections 框架中的一个接口，它提供了遍历或迭代集合的方法。

当您的动机只是遍历集合以读取其元素时，迭代器和 for 循环的行为相似。

for-each 只是迭代集合的一种方式。

例如：

List<String> messages= new ArrayList<>();

//using for-each loop
for(String msg: messages){
    System.out.println(msg);
}

//using iterator 
Iterator<String> it = messages.iterator();
while(it.hasNext()){
    String msg = it.next();
    System.out.println(msg);
}

for-each 循环只能用于实现迭代器接口的对象。

现在回到 for 循环和迭代器的例子。

当您尝试修改集合时，差异就出现了。在这种情况下，迭代器的效率更高，因为它具有快速故障属性。 IE。它在遍历下一个元素之前检查基础集合结构中的任何修改。如果发现任何修改，它将抛出 ConcurrentModificationException。

（注意：迭代器的此功能仅适用于 java.util 包中的集合类。它不适用于并发集合，因为它们本质上是故障安全的）

Answer 4

如果您只是在集合中徘徊以读取所有值，那么使用迭代器或新的 for 循环语法没有区别，因为新语法只是在水下使用迭代器。

但是，如果您指的是循环旧的“c 样式”循环：

for(int i=0; i<list.size(); i++) {
   Object o = list.get(i);
}

然后新的 for 循环或迭代器可能会更有效，具体取决于底层数据结构。原因是对于某些数据结构，get(i) 是 O(n) 操作，这使得循环成为 O(n²) 操作。传统的链表就是这种数据结构的一个例子。所有迭代器都有一个基本要求，即next() 应该是一个 O(1) 操作，使得循环 O(n)。

要验证新的 for 循环语法是否在水下使用了迭代器，请比较以下两个 Java sn-ps 生成的字节码。首先是for循环：

List<Integer>  a = new ArrayList<Integer>();
for (Integer integer : a)
{
  integer.toString();
}
// Byte code
 ALOAD 1
 INVOKEINTERFACE java/util/List.iterator()Ljava/util/Iterator;
 ASTORE 3
 GOTO L2
L3
 ALOAD 3
 INVOKEINTERFACE java/util/Iterator.next()Ljava/lang/Object;
 CHECKCAST java/lang/Integer
 ASTORE 2 
 ALOAD 2
 INVOKEVIRTUAL java/lang/Integer.toString()Ljava/lang/String;
 POP
L2
 ALOAD 3
 INVOKEINTERFACE java/util/Iterator.hasNext()Z
 IFNE L3

第二个，迭代器：

List<Integer>  a = new ArrayList<Integer>();
for (Iterator iterator = a.iterator(); iterator.hasNext();)
{
  Integer integer = (Integer) iterator.next();
  integer.toString();
}
// Bytecode:
 ALOAD 1
 INVOKEINTERFACE java/util/List.iterator()Ljava/util/Iterator;
 ASTORE 2
 GOTO L7
L8
 ALOAD 2
 INVOKEINTERFACE java/util/Iterator.next()Ljava/lang/Object;
 CHECKCAST java/lang/Integer
 ASTORE 3
 ALOAD 3
 INVOKEVIRTUAL java/lang/Integer.toString()Ljava/lang/String;
 POP
L7
 ALOAD 2
 INVOKEINTERFACE java/util/Iterator.hasNext()Z
 IFNE L8

如您所见，生成的字节码实际上是相同的，因此使用任何一种形式都不会降低性能。因此，您应该选择最美观的循环形式，对于大多数人来说，这将是 for-each 循环，因为它的样板代码较少。

Answer 5

在使用集合时，我们应该避免使用传统的 for 循环。 我将给出的简单原因是 for 循环的复杂度为 O(sqr(n)) 量级，而 Iterator 甚至增强的 for 循环的复杂度仅为 O(n)。 所以它给出了性能差异.. 只需列出大约 1000 个项目并使用两种方式打印即可。并打印执行的时间差。您可以看到差异。

Answer 6

为了扩展 Paul 自己的答案，他已经证明了该特定编译器（可能是 Sun 的 javac？）上的字节码是相同的，但不同的编译器并不能保证生成相同的字节码，对吧？要了解两者之间的实际区别是什么，让我们直接进入源代码并查看 Java 语言规范，具体来说是 14.14.2, "The enhanced for statement"：

增强的for 语句等效于基本for 语句的形式：

for (I #i = Expression.iterator(); #i.hasNext(); ) {
    VariableModifiers(opt) Type Identifier = #i.next();    
    Statement 
}

换句话说，JLS 要求两者是等价的。理论上这可能意味着字节码的微小差异，但实际上增强的 for 循环需要：

• 调用.iterator()方法
• 使用.hasNext()
• 通过.next() 使局部变量可用

因此，换句话说，对于所有实际目的，字节码将是相同的，或几乎相同的。很难想象任何编译器实现会导致两者之间有任何显着差异。

Answer 7

区别不在于性能，而在于能力。当直接使用引用时，您对显式使用一种迭代器有更大的权力（例如 List.iterator() 与 List.listIterator()，尽管在大多数情况下它们返回相同的实现）。您还可以在循环中引用迭代器。这使您可以执行诸如从集合中删除项目之类的操作，而不会收到 ConcurrentModificationException。

例如

没关系：

Set<Object> set = new HashSet<Object>();
// add some items to the set

Iterator<Object> setIterator = set.iterator();
while(setIterator.hasNext()){
     Object o = setIterator.next();
     if(o meets some condition){
          setIterator.remove();
     }
}

---

这不是，因为它会抛出一个并发修改异常：

Set<Object> set = new HashSet<Object>();
// add some items to the set

for(Object o : set){
     if(o meets some condition){
          set.remove(o);
     }
}