Go闭包技术

斐波那契数列(Fibonacci sequence),又称黄金分割数列 .因数学家列昂纳多·斐波那契(Leonardoda Fibonacci)以兔子繁殖为例子而引入,故又称为“兔子数列”,指的是这样一个数列: 1、1、2、3、5、8、13、21、34、……在数学上,斐波那契数列以如下被以递推的方法定义: F(1)=1,F(2)=1, F(n)=F(n-1)+F(n-2)(n>=3,n∈N*)

斐波那契数列就是形如 1 1 2 3 5 8 13 21 34 55 的递增数列,从第三项开始起,当前项是前两项之和.
为了计算方便,定义两个变量 a,b 表示前两项,初始值分别设置成 0,1 ,示例:

1
2
3
4
// 0 1 1 2 3 5 8 13 21 34 55
// a b
// a b
a, b := 0, 1

初始化后下一轮移动,a, b = b, a+b 结果是 a , b = 1 , 1,刚好能够表示斐波那契数列的开头.

1
2
3
4
5
6
func fibonacciByNormal() {
a, b := 0, 1
a, b = b, a+b
fmt.Print(a, " ")
fmt.Println()
}

但是上述示例只能生成斐波那契数列中的第一个数字,假如我们需要前十个数列,又该如何?

1
2
3
4
5
6
7
8
func fibonacciByNormal() {
a, b := 0, 1
for i := 0; i < 10; i++ {
a, b = b, a+b
fmt.Print(a, " ")
}
fmt.Println()
}

通过指定循环次数再稍加修改上述单数列代码,现在就可以生成前十位数列:

1
2
3
4
// 1 1 2 3 5 8 13 21 34 55
func TestFibonacciByNormal(t *testing.T) {
fibonacciByNormal()
}

这种做法是接触闭包概念前我们一直在采用的解决方案,相信稍微有一定编程经验的开发者都能实现,但是闭包却提供了另一种思路!

1
2
3
4
5
6
7
8
// 1 1 2 3 5 8 13 21 34 55
func fibonacci() func() int {
a, b := 0, 1
return func() int {
a, b = b, a+b
return a
}
}

不论是普通函数还是闭包函数,实现斐波那契数列生成器函数的逻辑不变,只是实现不同,闭包返回的是内部函数,留给使用者继续调用而普通函数是直接生成斐波那契数列.

1
2
3
4
5
6
7
8
// 1 1 2 3 5 8 13 21 34 55
func TestFibonacci(t *testing.T) {
f := fibonacci()
for i := 0; i < 10; i++ {
fmt.Print(f(), " ")
}
fmt.Println()
}

对于这种函数内部嵌套另一个函数并且内部函数引用了外部变量的这种实现方式,称之为”闭包”!

闭包自带独立的运行环境,每一次运行闭包的环境都是相互独立的,正如面向对象中类和对象实例化的关系那样,闭包是类,闭包的引用是实例化对象.

1
2
3
4
5
6
7
func autoIncrease() func() int {
i := 0
return func() int {
i = i + 1
return i
}
}

上述示例是闭包实现的计算器自增,每一次引用 autoIncrease 函数获得的闭包环境都是彼此独立的,直接上单元测试用例.

1
2
3
4
5
6
7
8
func TestAutoIncrease(t *testing.T) {
a := autoIncrease()
// 1 2 3
t.Log(a(), a(), a())
b := autoIncrease()
// 1 2 3
t.Log(b(), b(), b())
}

函数引用 a 和 b 的环境是独立的,相当于另一个一模一样计数器重新开始计数,并不会影响原来的计数器的运行结果.

普通函数内部定义的变量寿命有限,函数运行结束后也就被系统销毁了,结束了自己短暂而又光荣的一生.

但是,闭包所引用的变量却不一样,只要一直处于使用中状态,那么变量就会”长生不老”,并不会因为出身于函数内就和普通变量拥有一样的短暂人生.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
func fightWithHorse() func() int {
horseShowTime := 0
return func() int {
horseShowTime++
fmt.Printf("(%d)祖国需要我,我就提枪上马立即战斗!\n",horseShowTime)
return horseShowTime
}
}

func TestFightWithHorse(t *testing.T) {
f := fightWithHorse()
// 1 2 3
t.Log(f(), f(), f())
}

凡事有利必有弊,闭包不死则引用变量不灭,如果不理解变量长生不老的特性,编写闭包函数时可能一不小心就掉进作用域陷阱了,千万要小心!
下面以绑定循环变量为例讲解闭包作用域的陷阱,示例如下:

1
2
3
4
5
6
7
8
9
func countByClosureButWrong() []func() int {
var arr []func() int
for i := 1; i <= 3; i++ {
arr = append(arr, func() int {
return i
})
}
return arr
}

countByClosureButWrong 闭包函数引用的自由变量不仅有 arr 数组还有循环变量 i ,函数的整体逻辑是: 闭包函数内部维护一个函数数组,保存的函数主要返回了循环变量.

1
2
3
4
5
6
func TestCountByClosure(t *testing.T) {
// 4 4 4
for _, c := range countByClosureButWrong() {
t.Log(c())
}
}

当我们运行 countByClosureButWrong 函数获得闭包返回的函数数组 arr,然后通过 range 关键字进行遍历数组,得到正在遍历的函数项 c.

当我们运行 c() 时,期望输出的 1,2,3 循环变量的值,但是实际结果却是 4,4,4.

原因仍然是变量长生不老的特性:遍历循环时绑定的变量值肯定是 1,2,3,但是循环变量 i 却没有像普通函数那样消亡而是一直长生不老,所以变量的引用发生变化了!

长生不老的循环变量的值刚好是当初循环的终止条件 i=4,只要运行闭包函数,不论是数组中的哪一项函数引用的都是相同的变量 i,所以全部都是 4,4,4.

既然是变量引用出现问题,那么解决起来就很简单了,不用变量引用就好了嘛!

最简单的做法就是使用短暂的临时变量 n 暂存起来正在遍历的值,闭包内引用的变量不再是 i 而是临时变量 n.

1
2
3
4
5
6
7
8
9
10
11
12
func countByClosureButWrong() []func() int {
var arr []func() int
for i := 1; i <= 3; i++ {
n := i
fmt.Printf("for i=%d n=%d \n", i,n)
arr = append(arr, func() int {
fmt.Printf("append i=%d n=%d\n", i, n)
return n
})
}
return arr
}

上述解决办法很简单就是采用临时变量绑定循环变量的值,而不是原来的长生不老的变量引用,但是这种做法不够优雅,还可以继续简化进行版本升级.

既然是采用变量赋值的做法,是不是和参数传递中的值传递很相像?那我们就可以用值传递的方式重新复制一份变量的值传递给闭包函数.

1
2
3
4
5
6
7
8
9
10
11
12
13
func countByClosureWithOk() []func() int {
var arr []func() int
for i := 1; i <= 3; i++ {
fmt.Printf("for i=%d \n", i)
func(n int) {
arr = append(arr, func() int {
fmt.Printf("append n=%d \n", n)
return n
})
}(i)
}
return arr
}

采用匿名函数进行值传递进行改造后,我们再次运行测试用例验证一下改造结果:

1
2
3
4
5
6
func TestCountByClosureWithOk(t *testing.T) {
// 1 2 3
for _, c := range countByClosureWithOk() {
t.Log(c())
}
}
  • 模拟类和对象的关系,也可以实现封装,具备一定面向对象能力
    • 每次调用闭包函数所处的环境都是相互独立的,这种特性类似于面向对象中类和实例化对象的关系.
  • 缓存复杂逻辑,常驻内存,避免滥用全局变量徒增维护成本.
    • 长生不老的特性使得闭包引用变量可以常驻内存,用于缓存一些复杂逻辑代码非常合适,避免了原来的全局变量的滥用.
  • 实现闭包成本较高,同时也增加了理解难度.
    • 普通函数转变成闭包函数不仅实现起来有一定难度,而且理解起来也不容易,不仅要求多测试几遍还要理解闭包的特性.
  • 滥用容易占用过多内存,可能造成内存泄漏.
    • 过多使用闭包势必造成引用变量一直常驻内存,如果出现循环引用或者垃圾回收不及时有可能造成内存泄漏问题.