出于性能原因，我很好奇 for..in 是否应该优先于 .each。
【问题讨论】：
each 更改为 for-in 可能是优化技术列表中的最后一个。只是说 :-) 或者换句话说，一个不必要的数据库调用可以等于 1000 个优化的for-ins。
标签： groovy microbenchmark
For .. in 是标准语言流控制的一部分。
而不是each 调用闭包，因此需要额外的开销。
.each {...} 是相当于方法调用.each({...}) 的语法糖
此外，由于它是一个闭包，在 each 代码块内你不能使用 break 和 continue 语句来控制循环。
http://kunaldabir.blogspot.it/2011/07/groovy-performance-iterating-with.html
更新了基准 Java 1.8.0_45 Groovy 2.4.3：
这是另一个具有 100000 次迭代的基准：
lines = (1..100000)
// with list.each {}
start = System.nanoTime()
lines.each { line->
line++;
}
println System.nanoTime() - start
// with loop over list
start = System.nanoTime()
for (line in lines){
line++;
}
println System.nanoTime() - start
结果：
【讨论】：
break 和 continue传递给each 方法的闭包。例如，如果你在闭包中有一个循环或一个 switch 语句。
让我们从理论上看一下哪些调用是动态的，哪些调用是用 Java 逻辑更直接地完成的（我将这些调用称为静态调用）。
在for-in 的情况下，Groovy 对一个迭代器进行操作，为了获得它，我们对 iterator() 进行了一次动态调用。如果我没记错的话，hasNext 和 next 调用是使用普通的 Java 方法调用逻辑完成的。因此，对于每次迭代，我们这里只有 2 个静态调用。根据基准，必须注意第一次 iterator() 调用可能会导致严重的初始化时间，因为这可能会初始化元类系统并且需要一些时间。
在each 的情况下，我们对每个自身进行动态调用，以及为打开的块创建对象（闭包实例）。 each(Closure) 也将调用 iterator() ，但未缓存......以及所有一次性成本。在循环期间 hasNext 和 next 是使用 Java 逻辑完成的，该逻辑进行 2 次静态调用。对 Closure 实例的调用是使用方法调用的 java 标准逻辑完成的，然后将使用动态调用调用 doCall。
总结起来，每次迭代 for-in 只使用 2 个静态调用，而 each 有 3 个静态调用和 1 个动态调用。动态调用比多个静态调用慢得多，并且更难以针对 JVM 进行优化，因此占主导地位。因此，只要打开的块需要动态调用，each 应该总是更慢。
由于 Closure#call 的复杂逻辑，很难优化动态调用。这很烦人，因为它并不是真正需要的，一旦我们找到解决方法就会被删除。如果我们成功了，each 可能仍然会更慢，但这是一件更加困难的事情，因为字节码大小和调用配置文件在这里发挥了作用。理论上它们可以相等（忽略初始化时间），但是 JVM 有更多的工作要做。当然，这同样适用于 Java8 中基于流的 lambda 处理示例，
【讨论】：