闭包的概念、形式与应用（1）概念

look_w

什么是闭包？闭包并不是什么新奇的概念，它早在高级语言开始发展的年代就产生了。闭包（Closure）是词法闭包（Lexical Closure）的简称。对闭包的具体定义有很多种说法，这些说法大体可以分为两类：

• 一种说法认为闭包是符合一定条件的函数，比如中这样定义闭包：闭包是在其词法上下文中引用了自由变量()的函数。
• 另一种说法认为闭包是由函数和与其相关的引用环境组合而成的实体。比如中就有这样的的定义：在实现深约束()时，需要创建一个能显式表示引用环境的东西，并将它与相关的子程序捆绑在一起，这样捆绑起来的整体被称为闭包。

这两种定义在某种意义上是对立的，一个认为闭包是函数，另一个认为闭包是函数和引用环境组成的整体。虽然有些咬文嚼字，但可以肯定第二种说法更确切。闭包只是在形式和表现上像函数，但实际上不是函数。函数是一些可执行的代码，这些代码在函数被定义后就确定了，不会在执行时发生变化，所以一个函数只有一个实例。闭包在运行时可以有多个实例，不同的引用环境和相同的函数组合可以产生不同的实例。所谓引用环境是指在程序执行中的某个点所有处于活跃状态的约束所组成的集合。其中的约束是指一个变量的名字和其所代表的对象之间的联系。那么为什么要把引用环境与函数组合起来呢？这主要是因为在支持嵌套作用域的语言中，有时不能简单直接地确定函数的引用环境。这样的语言一般具有这样的特性：

• 函数是一阶值（First-class value），即函数可以作为另一个函数的返回值或参数，还可以作为一个变量的值。
• 函数可以嵌套定义，即在一个函数内部可以定义另一个函数。

这些概念上的解释很难理解，显然一个实际的例子更能说明问题。Lua 语言的语法比较接近伪代码，我们来看一段 Lua 的代码：
清单 1. 闭包示例1

1 2 3 4 5 6

function make_counter() local count = 0 function inc_count() count = count + 1         return count

end
return inc_countendc1 = make_counter()c2 = make_counter()print(c1())print(c2())
在这段程序中，函数 inc_count 定义在函数 make_counter 内部，并作为 make_counter 的返回值。变量 count 不是 inc_count 内的局部变量，按照最内嵌套作用域的规则，inc_count 中的 count 引用的是外层函数中的局部变量 count。接下来的代码中两次调用 make_counter() ，并把返回值分别赋值给 c1 和 c2 ，然后又依次打印调用 c1 和 c2 所得到的返回值。
这里存在一个问题，当调用 make_counter 时，在其执行上下文中生成了局部变量 count 的实例，所以函数 inc_count 中的 count 引用的就是这个实例。但是 inc_count 并没有在此时被执行，而是作为返回值返回。当 make_counter 返回后，其执行上下文将失效，count 实例的生命周期也就结束了，在后面对 c1 和 c2 调用实际是对 inc_count 的调用，而此处并不在 count 的作用域中，这看起来是无法正确执行的。
上面的例子说明了把函数作为返回值时需要面对的问题。当把函数作为参数时，也存在相似的问题。下面的例子演示了把函数作为参数的情况。
清单 2. 闭包示例2

1 2 3 4 5 6 7 8 9 10 11 12 13

function do10times(fn) for i = 0,9 do fn(i) end end sum = 0 function addsum(i) sum = sum + i end do10times(addsum) print(sum)

这里我们看到，函数 addsum 被传递给函数 do10times，被并在 do10times 中被调用10次。不难看出 addsum 实际的执行点在 do10times 内部，它要访问非局部变量 sum，而 do10times 并不在 sum 的作用域内。这看起来也是无法正常执行的。
这两种情况所面临的问题实质是相同的。在这样的语言中，如果按照作用域规则在执行时确定一个函数的引用环境，那么这个引用环境可能和函数定义时不同。要想使这两段程序正常执行，一个简单的办法是在函数定义时捕获当时的引用环境，并与函数代码组合成一个整体。当把这个整体当作函数调用时，先把其中的引用环境覆盖到当前的引用环境上，然后执行具体代码，并在调用结束后恢复原来的引用环境。这样就保证了函数定义和执行时的引用环境是相同的。这种由引用环境与函数代码组成的实体就是闭包。当然如果编译器或解释器能够确定一个函数在定义和运行时的引用环境是相同的()，那就没有必要把引用环境和代码组合起来了，这时只需要传递普通的函数就可以了。现在可以得出这样的结论：闭包不是函数，只是行为和函数相似，不是所有被传递的函数都需要转化为闭包，只有引用环境可能发生变化的函数才需要这样做。
再次观察上面两个例子会发现，代码中并没有通过名字来调用函数 inc_count 和 addsum，所以他们根本不需要名字。以第一段代码为例，它可以重写成下面这样：
清单 3. 闭包示例3

1 2 3 4 5 6 7 8 9 10 11 12 13 14

function make_counter() local count = 0 return function() count = count + 1 return count end end c1 = make_counter() c2 = make_counter() print(c1()) print(c2())

这里使用了匿名函数。使用匿名函数能使代码得到简化，同时我们也不必挖空心思地去给一个不需要名字的函数取名字了。
上面简单地介绍了闭包的原理，更多的闭包相关的概念和理论请参考中的"名字，作用域和约束"一章。
一个编程语言需要哪些特性来支持闭包呢，下面列出一些比较重要的条件：

• 函数是一阶值；
• 函数可以嵌套定义；
• 可以捕获引用环境，并
• 把引用环境和函数代码组成一个可调用的实体；
• 允许定义匿名函数；

这些条件并不是必要的，但具备这些条件能说明一个编程语言对闭包的支持较为完善。另外需要注意，有些语言使用与函数定义不同的语法来定义这种能被传递的"函数"，如 Ruby 中的 Block。这实际上是语法糖，只是为了更容易定义匿名函数而已，本质上没有区别。
借用一个非常好的说法来做个总结()：对象是附有行为的数据，而闭包是附有数据的行为。