Go的闭包看你犯错，Rust却默默帮你排坑

2021年7月29日 351点热度 0人点赞 0条评论

作者 | 马超责编 | 晋兆雨

出品 | CSDN博客

初识闭包

闭包（Closure）在某些编程语言中也被称为 Lambda 表达式，是能够读取其他函数内部变量的函数。一般只有函数内部的子函数才能读取局部变量，所以闭包这样一个函数内部的函数，在本质上是将函数内部和函数外部连接起来的桥梁。

在实践当中，假如我们需要统计一个函数被调用的次数，最简单的方式就是定义一个全局变量，每当目标函数被调用时就将此变量加1，但是全局变量会带来很多误用等问题，安全性往往得不到保证；而为调用次数专门设计一个以计数的接口又太小题大做了。

但是通过闭包就比较容易实现计数功能，以Go语言为例具体代码及注释如下：

package mainimport ("fmt")func SomeFunc() func() int { // 创建一个函数，返回一个闭包，闭包每次调用函数会对函数内部变量进行累加var CallNum int = 0 //函数调用次数，系函数内部变量，外部无法访问，仅当函数被调用时进行累加return func() int { // 返回一个闭包
CallNum++ //对value进行累加//实现函数具体逻辑return CallNum // 返回内部变量value的值}}func main() {accumulator := SomeFunc() //使用accumulator变量接收一个闭包
// 累加计数并打印fmt.Println("The first call CallNum is ", accumulator()) //运行结果为：The first call CallNum is 1// 累加计数并打印fmt.Println("The second call CallNum is ", accumulator()) //运行结果为：The second call CallNum is 2}

运行结果为：

The first call CallNum is 1

The second call Cal

可以看到我们通过闭包即没有暴露CallNum这个变量，又实现了为函数计数的目的。

Goroutine+闭包却出了莫名其妙的BUG

在Go语言中，闭包所依托的匿名函数也是Goroutine所经常用到的方案之一，但是这两者一结合却容易出现极难排查的BUG，接下来我把出现问题的代码简化一下，请读者们来看下面这段代码：

import (        "fmt"        "time")func main() {        tests1ice := []int{1, 2, 3, 4, 5}        for _, v := range tests1ice {
                go func() {                        fmt.Println(v)                }()        }        time.Sleep(time.Millisecond)}

这段代码的逻辑不难看懂，其目标是通过Goroutine将1,2,3,4,5乱序输出到屏幕上，但最终执行结果却如下：

55535成功: 进程退出代码 0.

也就是只有大多数情况下只有5被输出出来了，1-4几乎没有什么机会登场，这里简要复述一下问题的排查过程，由于没有在Goroutine中对切片执行写操作，所以首先排除了内存屏障的问题，最终还是通过反编译查看汇编代码，发现Goroutine打印的变量v，其实是地址引用，Goroutine执行的时候变量v所在地址所对应的值已经发生了变化，汇编代码如下：

 for _, v := range tests1ice {  499224:       48 8d 05 f5 af 00 00    lea    0xaff5(%rip),%rax        # 4a4220 <type.*+0xa220>  49922b:       48 89 04 24             mov    %rax,(%rsp)  49922f:       e8 8c 3a f7 ff          callq  40ccc0 <runtime.newobject>  499234:       48 8b 44 24 08          mov    0x8(%rsp),%rax  499239:       48 89 44 24 48          mov    %rax,0x48(%rsp)  49923e:       31 c9                   xor    %ecx,%ecx  499240:       eb 3e                   jmp    499280 <main.main+0xc0>  499242:       48 89 4c 24 18          mov    %rcx,0x18(%rsp)  499247:       48 8b 54 cc 20          mov    0x20(%rsp,%rcx,8),%rdx  49924c:       48 89 10                mov    %rdx,(%rax)                go func() {  49924f:       c7 04 24 08 00 00 00    movl   $0x8,(%rsp)  499256:       48 8d 15 f3 b7 02 00    lea    0x2b7f3(%rip),%rdx        # 4c4a50 <go.func.*+0x6c>  49925d:       48 89 54 24 08          mov    %rdx,0x8(%rsp)  499262:       48 89 44 24 10          mov    %rax,0x10(%rsp)  499267:       e8 54 3a fa ff          callq  43ccc0 <runtime.newproc>

可Goroutine中fmt.Println所处理的v，其实是v的地址中所对应的值。这也是产生这个BUG的基本原因。

找到了问题的原因，解决起来也就简单多了。

解决方案一：在参数方式向匿名函数传递值引用，具体代码如下：

package mainimport ("fmt""time")func main() {tests1ice := []int{1, 2, 3, 4, 5}for _, v := range tests1ice { w := vgo func(v int) {fmt.Println(v)}(v)}time.Sleep(time.Millisecond)}

解决方案二：在调用gorouinte前将变量进行值拷贝

package mainimport ("fmt""time")func main() {tests1ice := []int{1, 2, 3, 4, 5}for _, v := range tests1ice {w := vgo func() {fmt.Println(w)}()}time.Sleep(time.Millisecond)}

总而言之只要传值就没事，而传地址引用就会出现问题。

Rust的Lifetime检查如何排坑？

利用周末时间我想看看上述问题代码在Rust的实现中是如何处理的，却有比较意外的收获，我们来看上述代码的Rust实现：

use std::thread;use std::time::Duration;fn main() {   let arr = [1, 2, 3, 5, 5];    for i in arr.iter() {    let handle = thread::spawn(move || {        println!("{}", i);    });   }    thread::sleep(Duration::from_millis(10));}

但是上述这段代码编译都无法通过，原因是arr这个变量的生命周期错配。具体编译结果如下：

error[E0597]: `arr` does not live long enough
  --> hello16.rs:6:14
   |6  |     for i in arr.iter() {
   |              ^^^   |              |   |  borrowed value does not live long enough
   |    cast requires that `arr` is borrowed for `'static`...13 | }   | - `arr` dropped here while still borrowederror: aborting due to previous error; 1 warning emitted

我们刚刚提到过匿名函数其实是通过地址引用的方式来访问局部变量的，而地址引用也就对应Rust当中借用的概念，那么我们就可以推出来for i in arr.iter()中的 arr.iter()实际是对arr的借用，这个借用后的结果i被let handle = thread::spawn(move 中的move关键字强制转移走了，因此在handle线程离开作用域之后就被释放了，而下次迭代时arr变量由于lifetime的问题不能被编译器编译通过。

为了更简要的说明这个问题我们来看下面的代码：

fn main() {    {        let x;        {            let y = 5;            x = &y;// x借用y的值        }        // y在这里已经被释放，因此借用y的x也不能通过lifetime检查        println!("x: {}", x);    }
}

x借用y的值，如果在y的lifetime以外，再出现x的访问就会出现问题。如果想避免这个问题就不能再使用借用的机制，可以编译通过的代码如下：

use std::thread;use std::time::Duration;
fn main() {   let arr = [1, 2, 3, 5, 5];    for i in arr.iter() {//这段代码中i是对arr的借用    let j=i+1;//j通过值拷贝的方式获取了i的值    let handle = thread::spawn(move || {//move将j强制转移给了handle        println!("{}", j);    });//这里j超出lifetime就不会影响到i了   }    thread::sleep(Duration::from_millis(10));}

新添加的let j=i+1;是通过值拷贝的方式将i和j剥离了，因此j在被释放的时候就不会影响到arr的借用i了。

凡是编译器能发现的错误，都不会形成问题。通过这个Go语言问题的排查，我对于Rust的变量生命周期检查机制有了更进一步的认识，不得不承认虽然Rust虽然难度很高，学起来比较劝退，但是其安全语言的名号真是所言不虚，他强制程序员必须按照正确的方式做事，如果能对Rust的机理做到知其然还能知其所以然，必将是个巨大的提升。

作者：马超，CSDN博客专家，阿里云MVP、华为云MVP，华为2020年技术社区开发者之星。

原文链接：https://blog.csdn.net/BEYONDMA/article/details/119055829

☞名校大厂 AI 高手云集，芒果 TV 音视频算法大赛硕果累累
☞拉拢苹果用户，谷歌推出“从 iOS 转移到 Android” App
☞宁做程序员，不做 CTO！估值 50 亿美元公司的创始人只想专注编程




                                  

                                           CSDN                                      
成就一亿技术人
             3019篇原创内容                        

                


公众号

140500Go的闭包看你犯错，Rust却默默帮你排坑

Go的闭包看你犯错，Rust却默默帮你排坑

文章评论