【投稿】原创：以新视角，解读【闭包】

附有丰富的 [例程]

概要

1. ​​rust​​【闭包】在内存里被保存为【结构体】。
2. 闭包不同于函数之处就是：闭包能够捕获【外部变量】为已所用。
3. 闭包捕获【外部变量】会（条件地）导致【外部变量】在闭包外就不能再被访问了。

• 对应正文中提到的【捕获方式】决定【外部变量】生命周期。
• 闭包业务代码使用【外部变量】也会（条件地）导致【闭包】自身只能被执行一次。
• 对应正文中提到的【处理方式】决定【闭包】的执行次数。

概括地讲，我这篇文章就是总结了上述​​(3)​​​与​​(4)​​项中提到的“条件”关系于一张表格，并基于该表格展开论述。

准备知识【闭包是以什么样的数据结构被管理】

1. 在代码编译过程中，每遇到一个【闭包】定义（比如，​​let test = || println!("生成类 + 实例化 + 变量绑定 一条龙服务");​​），​​rustc​​就会为该【闭包】连续做如下几件事情

• 变量里保存的是【闭包​​struct​​】的实例​​instance​​，而不是【闭包​​struct​​】的类型​​type​​。
• 所以，一旦【闭包】被定义，那么由该【闭包】所捕获的【外部变量】就已经被“锁定”了。即，【闭包】对其【外部变量】生命周期的“负面”影响是从【闭包】被定义的那个时间点就开始了，而不是从【闭包】被第一次调用执行时算起的（这个​​timing​​要更晚一些）[例程1]。

2. 生成一个全新的、匿名的、实现了​​Fn / FnMut / FnOnce trait​​之一的​​struct​​（类型）--- 下文皆称其为【闭包​​struct​​】
3. 立即实例化此【闭包​​struct​​】的唯一实例。
4. 将该【闭包​​struct​​】实例绑定给【变量绑定语句】等号​​=​​左侧的具名变量（比如，上面例子中的​​test​​）。

• 被生成【闭包​​struct​​】的【成员方法​​Fn::call / FnMut::call_mut / FnOnce::call_once​​】封装了【闭包】要执行的业务逻辑。
• 被生成【闭包​​struct​​】的若干【字段】保存了被【闭包】【捕获】的外部变量。而具体内容
• 既可以是外部变量的引用 --- 按【引用】捕获。
• 也可能是外部变量的值 --- 按【值】捕获，也被称为“捕获【外部变量】【所有权】”。

小结: 因为，在不同的代码上下文中，

• 闭包捕获的外部变量不同，
• 闭包内定义的业务逻辑代码也不一样，

所以，每个【闭包】皆对应于一个独一无二的且匿名的​​struct​​​类型。而所有【闭包​​struct​​】的共同点就是：

• 它们都实现了​​Fn / FnMut / FnOnce trait​​之一。
• 它们都是单实例。

上干货

虽然​​Rust Programming Language​​权威指南是以【闭包】对【外部变量】【捕获方式】的分类为切入点，来讲解【闭包】，但是我发现：若完全依赖这套解释标准，我对某些【闭包】代码的理解会遇到不自恰的尴尬。为了避免“思维-凑数”，我摸索了一套辅助手段来帮助解读【闭包】代码。该方法是以【闭包】业务程序对【外部变量】【处理方式】的分类为起点，进而判断【闭包】的行为特性。

首先，【捕获方式】影响的是【闭包】【外部变量】的生命周期。即，

1. 在【闭包】生存期内，被捕获的【外部变量】在【闭包】外是否还可以被

• 【只读-借入】
• 【可修改-借入】
• 【所有权-转移】
• 在【闭包】被释放​​drop​​之后，【外部变量】是否可恢复被
• 【只读-借入】
• 【可修改-借入】
• 【所有权-转移】

其次，【处理方式】描述的是【闭包】业务程序如何使用【外部变量】(是借入，还是所有权转移）。它的影响范围更广，包括：

1. 对外决定了【捕获方式】。间接影响了【外部变量】的生命周期。
2. 对内决定了该【闭包】能够被调用与执行的次数。

接着，【处理方式】【捕获方式】【〔外部变量〕生命周期】【〔闭包〕执行次数】，这四个要素之间的相互关系可概括为：

1. 【处理方式】决定【捕获方式】
2. 【捕获方式】决定【外部变量】生命周期
3. 【处理方式】决定【闭包】的调用执行次数。
4. ​​move​​关键字能开启“后门”：绕过【处理方式】强制设置【捕获方式】，定制【外部变量】生命周期

更形象、详细的描述可被展开为如下表格： 

对上表内脚注 [1] [2] [3] [4] 的展开解释如下：

1. [1] 【闭包】的生命周期是从【闭包】被定义开始，直至该【闭包】被最后一次调用执行后，立即结束。
2. [2] 【闭包】【可修改-借入】【外部变量】要求【闭包​​struct​​】实例被以​​let mut​​绑定至变量。这是由​​rust​​【继承可修改】语言特性决定的。即，若要修改某个​​struct​​的字段值，那么该字段所属的​​struct​​实例自身必须是可修改的。在这个场景下，被捕获【外部变量】的【可修改-引用】就是【闭包​​struct​​】的一个字段。[例程2]
3. [3] 在【闭包】内，对【外部变量】执行【所有权-转移】的判定标准是：

• 要么，将该【外部变量】被绑定给【闭包】内的另一个变量，而不使用​​&​​, ​​&mut​​, ​​let ref​​,​​let ref mut​​ [例程3]
• 要么，将该【外部变量】被作为实参传递给某个（以【所有权】变量为入参的）函数调用 [例程4]
• 要么，调用该【外部变量】实例上的“消耗型​​consuming​​”成员方法，从而“消费掉“实例变量自身 [例程5]
• 【外部变量】是​​!Copy trait​​值。

4. 必有条件：

题外话，为了开启泛型的​​!Trait​​​语法，需要在程序首行前注入元属性：​​#![feature(negative_impls)]​​。

1. 
   
2. 三择一条件：

题外话，若【外部变量】是​​Copy trait​​值的话，上述三类操作仅会取走【外部变量】值的【复本】，而不是触发变量的【所以权-转移】。

• [4] 在【闭包】内，对【外部变量】执行【可修改-借入】的判定标准是： [例程6]

1. 【外部变量】被使用​​let mut​​定义为可修改
2. 【闭包​​struct​​】实例被使用​​let mut​​绑定至可修改变量。
3. 在【闭包】业务程序内，对【外部变量】重新赋值

然后，既然已经有【处理方式】决定【捕获方式】的设定，那你是否曾经质疑过​​move​​​关键字开“后门”的必要性？在如下两个场景里，我们还真需要​​move​​强制指定【闭包】对【外部变量】的【捕获方式】。

1. 被跨线程执行的【闭包】。例如，

在这个场景下，所有的【外部变量】都必须从​​A​​​线程全量搬移到​​B​​线程（变量的【所有权】也就同时被转移了），以避免多线程数据竞争。

• 在​​A​​线程定义一个【闭包】
• 将该【闭包】与其捕获的【外部变量】传递给​​B​​线程执行。
• 被高阶函数返回的【闭包】[例程7]

在这个场景下，【闭包】必须把它所依赖的【外部变量】一起转移走，无论在【闭包】业务代码里是仅只【引用】借入变量，还是“消费掉”变量【所有权】。

• 当高阶函数执行结束时，高阶函数体内定义的所有局部变量会随着函数在【栈】内的【帧】一起被释放掉。
• 这会导致【闭包】按【引用】捕获的全部【外部变量】都变成【野指针】。即，【闭包】活着，但【闭包】依赖的外部环境没了。多尴尬，人还在，家没了！

最后，我推荐对【闭包】代码解读的思维步骤如下：

1. 先看【闭包】定义是否有​​move​​关键字前缀。

• 若有，则说明：即便【闭包​​struct​​】实例的生命周期结束，我们也不能对其【外部变量】做任何的操作了。
• 再看【闭包​​struct​​】实例是否被​​let mut​​绑定给 可修改变量。
• 若是，则说明：在【闭包​​struct​​】实例的生命周期内，我们不能对其【外部变量】做任何的操作了。
• 接着，精读【闭包】业务代码。分析【闭包】是否对【外部变量】做了任何的【所有权-转移】操作。
• 若执行了【所有权-转移】处理，则说明：即便【闭包​​struct​​】实例的生命周期结束，我们也不能对其【外部变量】做任何的操作了。
• 若上面三个条件均不成立，那么
• 在【闭包​​struct​​】实例的生命周期内，【外部变量】可读（只读-借入）
• 在【闭包​​struct​​】实例的生命周期结束后，我们便可恢复对【外部变量】的完全访问能力。