golang使用坑两处

今天的文章给大家看看两处golang使用中存在的坑，了解这两处坑，能够防止一些隐蔽性比较大的bug出现。闲话少叙，上代码

package main

import (
	"errors"
	"fmt"
)

func main() {
	var err error

	defer func(err error) {
		fmt.Printf("inner %v\n", &err)
		fmt.Println("inner", err)
	}(err)

	err = errors.New("error here")

	fmt.Printf("outer %v\n", &err)
	fmt.Println("outer", err)
}

上面代码结构经常用在函数执行结束后需要进行后处理的时候，表面看上面的代码貌似没有问题，你希望在函数执行结束后，inner打印出err的信息，那么现在执行看下结果

outer 0xc0000881e0
outer error here
inner 0xc000088200
inner <nil>

What？怎么inner err是nil？而且存放nil的地址和outer err的地址也完全不同。如果我们这里代码逻辑是判断inner err不为nil时打印log，那么很遗憾，即使outter err不是nil，你都看不到log了。先别着急分析原因，我把代码稍微修改，再来看看。

package main

import (
	"errors"
	"fmt"
)

func main() {
	var err error

	defer func(err *error) {
		fmt.Printf("inner %v\n", err)
		fmt.Println("inner", *err)
	}(&err)

	err = errors.New("error here")

	fmt.Printf("outer %v\n", &err)
	fmt.Println("outer", err)
}

修改的地方就是匿名函数传递error指针而不是变量，相关的inner打印做一下修改，这次运行结果

outer 0xc00003a1f0
outer error here
inner 0xc00003a1f0
inner error here

完全符合要求了。那么问题来了，为什么上面那段代码inner err就是nil呢？原因在于golang的传参机制，golang给函数传参，不管什么类型的变量，传递的都是变量值的拷贝，注意，是变量值的拷贝，如果变量不是指针，拷贝的就是变量的值，如果变量是指针变量，指针变量的值就是变量的地址值，所以拷贝指针变量的值，就是拷贝变量的地址值。

第一段代码，传递的是error类型的变量err，所以，我们一开始只是声明了err变量，error是一个interface，其零值是nil，也就是我们传递给匿名函数时候的err变量值是nil，golang将nil值拷贝进匿名函数的局部变量inner err，所以打印inner err地址与outter err不同，而且inner err值是nil，这完全是正确的行为。

第二段代码则不同，匿名函数传递了指针，也就是将outter err的地址值做了拷贝赋值给了匿名函数的局部变量，inner err实际保存了变量的地址值，所以，err的值会随着outer err的变化而变化。

当然我们还有最后一种代码写法来回避这个问题

package main

import (
	"errors"
	"fmt"
)

func main() {
	var err error

	defer func() {
		fmt.Printf("inner %v\n", &err)
		fmt.Println("inner", err)
	}()

	err = errors.New("error here")

	fmt.Printf("outer %v\n", &err)
	fmt.Println("outer", err)
}

匿名函数不使用参数，这样，err都是外部定义的err，不存在二义性了。下面看另外一个坑，问题原因和上面的坑一样

package main

import (
	"fmt"
	"sync"
)

func main() {
	aSlice := []int{1, 2, 3, 4}

	wg := sync.WaitGroup{}

	wg.Add(len(aSlice))

	for _, num := range aSlice {
		go func() {
			fmt.Println(num)
			fmt.Printf("%v\n", &num)
			wg.Done()
		}()
	}

	wg.Wait()
}

注意看中间的for循环部分，这样的方式采用的是上面坑中最后一种方式，匿名函数没有传参，你以为这次正确了？你以为打印会是1到4？运行下看看再说

4
4
0xc0000120e0
0xc0000120e0
4
0xc0000120e0
4
0xc0000120e0

抛开打印的异步问题，我们关注内容，竟然全是4，而且num的地址完全一样，多运行几次，运气好，你可能会遇到结果里面零星可见的3(我是看不到1和2)，这又是怎么回事？

还是上面的思路，golang中for循环中创建的变量num，在整个for循环过程中是同一个变量，只是变量的值会变化。我们匿名协程直接使用num这个变量，随着外面num值在变化，协程只会打印它运行时刻的num值，大部分时候，协程得到调度是在main协程wait的时候。之所以偶尔会有3，那是因为赶巧num在3时，main协程不知道什么原因被抢占了，匿名协程得到了调度。

修改这个问题也很简单，代码如下：

package main

import (
	"fmt"
	"sync"
)

func main() {
	aSlice := []int{1, 2, 3, 4}

	wg := sync.WaitGroup{}

	wg.Add(len(aSlice))

	for _, num := range aSlice {
		go func(num int) {
			fmt.Println(num)
			fmt.Printf("%v\n", &num)
			wg.Done()
		}(num)
	}

	wg.Wait()
}

将num的值通过参数值拷贝实时传递给匿名函数，这样，匿名函数中的num只是记录了外部num的值，引用上已经脱离了关系，自然运行也就正常了。

从这两个坑我们应该看到，我们不可以生搬照抄某一种解决方案，对于第一个坑的解决方案却正好是第二个坑的问题原因，我们应该时刻对我们的代码怀有警惕心，切不可有之前这样的代码就没有问题，这次也不应该出问题的想法，对代码的仁慈和同情就是对自己的残忍，代码总会在我们不经意间给我们挖坑。对于语言机制的了解，才是用好一门编程语言，写出高质量代码的根本手段。