0
点赞
收藏
分享

微信扫一扫

Go 中闭包的底层原理


阅读目录

  • ​​什么是闭包?​​
  • ​​复杂的闭包场景​​
  • ​​闭包的底层原理?​​
  • ​​迷题揭晓​​
  • ​​再度变题​​
  • ​​知识点​​

什么是闭包?

一个函数内引用了外部的局部变量,这种现象,就称之为闭包。

例如下面的这段代码中,adder 函数返回了一个匿名函数,而该匿名函数中引用了 adder 函数中的局部变量 sum ,那这个函数就是一个闭包。

package main

import "fmt"

func adder() func(int) int {
sum := 0
return func(x int) int {
sum += x
return sum
}
}

func main() {
intscc := adder()
fmt.Println(intscc(1)) // 输出1
fmt.Println(intscc(2)) // 输出3
}

这个闭包中引用的外部局部变量并不会随着 adder 函数的返回而被从栈上销毁。

我们尝试着调用这个函数,发现每一次调用,sum 的值都会保留在闭包函数中以待使用。

复杂的闭包场景

写一个闭包是比较容易的事,但单单会写简单的闭包函数,还远远不够,如果不搞清楚闭包真正的原理,那很容易在一些复杂的闭包场景中对函数的执行逻辑进行误判。

别的不说,就拿下面这个例子来说吧?

你觉得它会打印什么呢?

是 6 还是 11 呢?

package main

import "fmt"

func func1() (i int) {
i = 10
defer func() {
i += 1
}()
return 5
}

func main() {
closure := func1()
fmt.Println(closure) // 6
}

闭包的底层原理?

package main

import "fmt"

func adder() func(int) int {
sum := 0
return func(x int) int {
sum += x
return sum
}
}

func main() {
valueFunc:= adder()
fmt.Println(valueFunc(2)) // output: 2
}

我们先对它进行逃逸分析,很容易发现 sum 作为 adder 函数局部变量,并不是分配在栈上,而是分配在堆上的。

这就解决了第一个疑惑:为什么 adder 函数返回后, sum 不会随之销毁。

迷题揭晓

package main

import "fmt"

func func1() (i int) {
i = 10
defer func() {
i += 1
}()
return 5
}

func main() {
closure := func1()
fmt.Println(closure) // 6
}

首先,由于 i 在函数定义的返回值上声明,因此根据 go 的 caller-save 模式, i 变量会存储在 main 函数的栈空间。

然后,func1 的 return 重新把 5 赋值给了 i ,此时 i = 5

由于闭包函数存储了这个变量 i 的指针。

因此最后,在 defer 中对 i 进行自增,是直接更新到 i 的指针上,此时 i = 5+1,所以最终打印出来的结果是 6。

再度变题

package main

import "fmt"

func func1() int {
i := 10
defer func() {
i += 1
}()
return i
}

func main() {
closure := func1()
fmt.Println(closure) // 10
}

返回值里写了变量名,那么该变量会存储 main 的栈空间里,而如果你不写,那 i 只能存储在 func1 的栈空间里,与此同时,return 的值,不会作用于原变量 i 上,而是会存储在该函数在另一块栈内存里。

因此你在 defer 中对原 i 进行自增,并不会作用到 func1 的返回值上。

所以打印的结果,只能是 10。

知识点

在第一节示例中的 sum 是存储在堆内存中的,而后面几个示例都是存储在栈内存里。

这是为什么呢?

仔细对比,不难发现,示例一返回的是闭包函数,闭包函数在 adder 返回后还要在其他地方继续使用,在这种情况下,为了保证闭包函数的正常运行,无论闭包函数在哪里,i 都不能回收,所以 Go 编译器会智能地将其分配在堆上。

而后面的其他示例,都只是涉及了闭包的特性,并不是直接把闭包函数返回,因此完全可以将其分配在栈上,非常的合理。


举报

相关推荐

0 条评论