在 java 代码中遍历一个集合的用法是使用迭代 iterator：// Java
for (Iterator iter = collection.ite rator(); iter.hasNe xt();){ ItemType item = (ItemType) iter.ne xt();
// do something with item
}明确的实现了 Collection，或者如 List 这样的接口，也许也会通过这样的代码操作：// Java
for (int i=0; i < list.size(); i++){
ItemType item = (ItemType) list.ge t(i);
// do something with item
}Java 通过两个新的特性改进了这种情况：泛型和增强的 for 语句，使用泛型之后不再需要进行强制造型；增强的 for 语句与 groovy 的循环非常相似，只需要把“：”改成“in”：// Java 5
for (ItemType item : list) {
// do something with item
}语法也许不完美——java5 的设计者拘泥于向 java 中增加关键字，但这需要做更多的工作，对吗？对于同一件事情，这种语法被限制在 java5 平台，但许多开发者仍然在使用 java1.4或者更早期的版本，为了这样一个常用的操作需要强制的写更多的代码，它相对简单，熟悉了就会觉得平常，并且在循环体内部的错误很容易被忽略，因为你通常在阅读代码的时候会在看完一个方法之后再来看循环体。
增强的 for 语句的第二个问题是让我们感觉它与闭包非常相似，不管怎样，清晰的迭代处理集合中的每一个条目是有用的；否则，groovy 就没有必要拥有闭包了，对于初学者来说（groovy 的 for 语句比 java5 的稍微清晰一点），这是有用的，但不是我们希望看到的全部东西。
有通用的模式来表明为什么我们想遍历一个集合，比如在集合中的任何一个元素是否符合特定的条件，查找所有符合给定条件的结果，或者转换每一个元素到另外一个集合中，因此需要创建新的集合。
对于这些模式的处理有专门的语法看起来比较疯狂，使语言的实现以没有可扩展性而结 束，就像通往森林的公路那样，当设计者知道预先需要做的事情时，这样是挺好的。
但很快你将迷路，生活是坚强的，不需要语言对这些模式进行直接的语言支持，每一种模式都依赖于一遍又一遍的执行一个特定的代码块，集合中的每一个元素都执行一次，java 没有“特定 的代码块”的概念，除非这些代码块被埋植在一个方法中，这个方法可以使一个接口的实现，但这样每一个代码块都需要一个自己的类（可能为匿名内部类），代码显得十分丑陋。
Groovy 使用闭包来指定这些每次都被执行的代码块，并且增加了许多额外的方法（each、find、find All、collect 等等）到集合类上，使他们容易使用，这些方法没有魔力，只是用来简化了 groovy，因为闭包能够把控制逻辑从每次执行的代码块中分离出来，如果你发现你想到的一个相似的结构没有在 groovy 中出现，可以容易的增加到 groovy 中。
把控制逻辑和每次迭代处理的逻辑分开不是介绍闭包概念的唯一原因，第二个原因（可能是更重要的原因）是在处理资源的时候使用闭包。