Go知识盲区--闭包

2021/12/8 6:19:35

本文主要是介绍Go知识盲区--闭包,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

1. 引言

关于闭包的说明,曾在很多篇幅中都有过一些说明,包括Go基础--函数2, go 函数进阶,异常与错误 都有所提到, 但是会发现,好像原理(理论)都懂,但是就是不知道如何使用,或者在看到一些源码时,依然一头雾水。 刚好今天看到了一篇优质的博客,并结合以前几篇关于类似闭包的介绍,再次对 闭包进行一次分析。

2. 什么是闭包?

函数内部包含另一个函数: 且返回的是一个函数类型

2.1. 一个简单的例子

示例1

package main

import (
	"fmt"
)

// 累加器
func AddWrapper() func(int) int {
	var n int = 10
	return func(x int) int {
		n = n + x
		return n
	}
}

func main() {

	f := AddWrapper()
	fmt.Println(f(1)) // 11
	fmt.Println(f(2)) // 13
	fmt.Println(f(3)) // 16
}

2.2理解闭包

  1. 闭包本身是一个函数, 且返回的一个函数func (int) int
  2. 返回的是一个匿名函数,但是这个匿名函数 引用到了函数(匿名)函数外的变量(上面示例是 n),因此这个匿名函数就和n 形成了一个整体, 构成闭包.
  3. 相比较类可以这么理解: 闭包是类(class),函数是类里面的某个方法, n是字段(属性),函数和他使用到的n构成闭包
    当反复调用AddWrapper 函数时, n只被初始化一次,因此每调用一次就进行累计

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

调用这个函数,发现每一次调用,n 的值都会保留在 闭包函数中以待使用。

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

3. 复杂的闭包场景

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

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

你觉得它会打印什么呢?

是 6 还是 11 呢?

示例2

import "fmt"

func func1() (i int) {
    i = 10
    defer func() {
        i += 1
    }()
    // 相当于两条语句
    // i = 5
    // return i
    return 5
}

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

先不运行,先来了解下闭包的底层原理

4.闭包的底层原理?

以最上面的例子进行分析

package main

import (
   "fmt"
)

// 累加器
func AddWrapper() func(int) int {
   var n int = 10
   return func(x int) int {
   	n = n + x
   	return n
   }
}

func main() {

   f := AddWrapper()
   fmt.Println(f(1)) // 11
   fmt.Println(f(2)) // 13
   fmt.Println(f(3)) // 16
}

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

D:\gopath\src\Go_base\daily_test\闭包> go build -gcflags="-m -m -l" demo.go
# command-line-arguments
.\demo.go:11:7: AddWrapper.func1 capturing by ref: n (addr=true assign=true width=8)
.\demo.go:10:9: func literal escapes to heap:
.\demo.go:10:9:   flow: ~r0 = &{storage for func literal}:
.\demo.go:10:9:     from func literal (spill) at .\demo.go:10:9
.\demo.go:10:9:     from return func literal (return) at .\demo.go:10:2
.\demo.go:9:6: n escapes to heap:
.\demo.go:9:6:   flow: {storage for func literal} = &n:
.\demo.go:9:6:     from func literal (captured by a closure) at .\demo.go:10:9
.\demo.go:9:6:     from n (reference) at .\demo.go:11:7
.\demo.go:9:6: moved to heap: n
.\demo.go:10:9: func literal escapes to heap
.\demo.go:21:15: f(3) escapes to heap:
.\demo.go:21:15:   flow: {storage for ... argument} = &{storage for f(3)}:
.\demo.go:21:15:     from f(3) (spill) at .\demo.go:21:15
.\demo.go:21:15:     from ... argument (slice-literal-element) at .\demo.go:21:13
.\demo.go:21:15:   flow: {heap} = {storage for ... argument}:
.\demo.go:21:15:     from ... argument (spill) at .\demo.go:21:13
.\demo.go:21:15:     from fmt.Println(... argument...) (call parameter) at .\demo.go:21:13
.\demo.go:20:15: f(2) escapes to heap:
.\demo.go:20:15:   flow: {storage for ... argument} = &{storage for f(2)}:
.\demo.go:20:15:     from f(2) (spill) at .\demo.go:20:15
.\demo.go:20:15:     from ... argument (slice-literal-element) at .\demo.go:20:13
.\demo.go:20:15:   flow: {heap} = {storage for ... argument}:
.\demo.go:20:15:     from ... argument (spill) at .\demo.go:20:13
.\demo.go:20:15:     from fmt.Println(... argument...) (call parameter) at .\demo.go:20:13
.\demo.go:19:15: f(1) escapes to heap:
.\demo.go:19:15:   flow: {storage for ... argument} = &{storage for f(1)}:
.\demo.go:19:15:     from f(1) (spill) at .\demo.go:19:15
.\demo.go:19:15:     from ... argument (slice-literal-element) at .\demo.go:19:13
.\demo.go:19:15:   flow: {heap} = {storage for ... argument}:
.\demo.go:19:15:     from ... argument (spill) at .\demo.go:19:13
.\demo.go:19:15:     from fmt.Println(... argument...) (call parameter) at .\demo.go:19:13
.\demo.go:19:13: ... argument does not escape
.\demo.go:19:15: f(1) escapes to heap
.\demo.go:20:13: ... argument does not escape
.\demo.go:20:15: f(2) escapes to heap
.\demo.go:21:13: ... argument does not escape
.\demo.go:21:15: f(3) escapes to heap

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

可另一个问题,又浮现出来了,就算它不会销毁,那闭包函数若是存储的若是 sum 拷贝后的值,那每次调用闭包函数,里面的 n 应该都是一样的,调用3次应该是11,12,13,而不是可以累加记录。

因此,可以大胆猜测,闭包函数的结构体里存储的是 n 的指针。

为了验证这一猜想,只能上汇编了。

通过执行下面的命令,可以输出对应的汇编代码。

D:\gopath\src\Go_base\daily_test\闭包>go build -gcflags="-S" demo.go
# command-line-arguments
"".AddWrapper STEXT size=159 args=0x8 locals=0x20 funcid=0x0
        0x0000 00000 (D:\gopath\src\Go_base\daily_test\闭包\demo.go:8)  TEXT    "".AddWrapper(SB), ABIInternal, $32-8
        0x0000 00000 (D:\gopath\src\Go_base\daily_test\闭包\demo.go:8)  MOVQ    TLS, CX
        0x0009 00009 (D:\gopath\src\Go_base\daily_test\闭包\demo.go:8)  PCDATA  $0, $-2
        0x0045 00069 (D:\gopath\src\Go_base\daily_test\闭包\demo.go:10) LEAQ    type.noalg.struct { F uintptr; "".n *int }(SB), CX

输出的很多,提取出上面最关键的一行代码,它定义了闭包函数的结构体。

其中 F 是函数的指针,但这不是重点,重点是 n 存储的确实是指针.

type.noalg.struct { F uintptr; "".n *int }

5. 迷题揭晓

有了对闭包原理的认识,那对于第3节给出的这道题,很明显可以知道输出的内容是6。

import "fmt"

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

func main() {
    closure := func1()
    fmt.Println(closure)
}
  1. 首先,由于 i在函数定义的返回值上声明,因此根据 go 的 caller-save 模式, i 变量会存储在 main 函数的栈空间。

    1. Callee-saved register(又称非易失性寄存器AKA non-volatile registers, or call-preserved)用于保存应在每次调用中保留的长寿命值。
    2. 调用者保存”( caller saving )方法:如果采用调用者保存策略,那么在一个调用者调用别的过程时,必须保存调用者所要保存的寄存器,以备调用结束返回后,能够再次访问调用者。
  2. 然后,func1 的 return 重新把 5 赋值给了 i ,此时 i = 5

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

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

6. 可能的坑

上面那题听懂了的话,再来看看下面这道题。

func1 的返回值我们不写变量名 i 了,然后原先返回具体字面量,现在改成变量 i ,就是这两小小小的改动,会导致运行结果大大不同。

示例3

import "fmt"

func func1() (int) {
    i := 10
    
    defer func() {
        // 函数内部的作用域并不会作用到外部
        i += 1
    }()
    return i
}

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

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

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

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

7. 总结

示例1中的 n是存储在堆内存中的,而后面几个示例都是存储在栈内存里。

这是为什么呢?

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

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

闭包的优势: 类似于面向对象编程中, 引用的变量相当于 类中的一个属性, 返回的匿名函数相当于修改了属性值, 但是在每次调用时,不需要重复传入引用的变量.

8. 参考

  1. https://www.cnblogs.com/failymao/p/14716868.html
  2. https://iswbm.com/534.html
  3. https://stackoverflow.com/questions/9268586/what-are-callee-and-caller-saved-registers


这篇关于Go知识盲区--闭包的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!


扫一扫关注最新编程教程