【Golang】defer的这些坑,你遇到过吗?
前言
之前的文章中分享了关于defer的一些用法和实现原理,但是在实际使用过程中,总会踩不少坑(在上一篇最后的总结中也有一些关于特性的总结),这篇文章中将结合代码的方式展现,希望能帮到你少走弯路。
1:延迟函数传递的参数是值
func deferTest() {
var a = 1
defer fmt.Println(a)
a = 2
return
}
结论:延迟函数 fmt.Println(a) 的参数在 defer 语句出现的时候就已经确定下来了,所以不管后面如何修改 a 变量,都不会影响延迟函数
2:延迟函数传递的参数是地址
func deferTest() {
var arr = [3]int{1, 2, 3}
defer printTest(&arr)
arr[0] = 4
return
}
func printTest(array *[3]int) {
for i := range array {
fmt.Println(array[i])
}
}
结论:延迟函数 printTest() 的参数在 defer 语句出现的时候就已经确定下来了,即为数组的地址,延迟函数执行的时机是在 return 语句之前,所以对数组的最终修改的值会被打印出来。
3:延迟函数可能会影响函数的返回值
fmt.Println(deferTest)
func deferTest() (result int) {
i := 1
defer func() {
result = 2
}()
return i
}
结论:函数的 return 语句并不是原子级的,实际的执行过程为为设置返回值—>ret,defer 语句是在返回前执行,所以返回过程是:「设置返回值—>执行defer—>ret」。所以 return 语句先把 result 设置成 i 的值(1),defer 语句中又把 result设置为 2 ,所以最终返回值为 2
4:defer需要定义在panic前
func panicBeforeDefer() {
panic("a")
defer func() {
fmt.Println("b")
}()
}
func panicAfterDefer() {
defer func() {
fmt.Println("b")
}()
panic("a")
}
结论:代码执行到了painc之后再执行的defer,然后按照defer的先进后出的顺序执行defer,最后才执行panic。那为什么panic时会执行defer,可以看下这段代码就很清楚了。
func gopanic(e interface{}) {
gp := getg()
...
var p _panic
p.arg = e
p.link = gp._panic
gp._panic = (*_panic)(noescape(unsafe.Pointer(&p)))
for {
d := gp._defer
if d == nil {
break
}
...
}
}
5:先判断err,再defer释放资源
func openFile() {
file, err := os.Open("txt")
if err != nil {
return
}
defer file.Close()
}
结论:获取文件资源的时候会返回err,如果我们在后续需要进行defer释放文件资源时,这里需要对err进行判断。因为如果获取文件资源失败的时候不需要进行释放,也避免了没获取到资源可能导致的释放函数执行错误。
6:os.Exit时defer不会被执行
func deferExit() {
defer func() {
fmt.Println("exit")
}()
os.Exit(1)
}
结论:上面代码中的defer不会得到执行,因为os.Exit()用于立即中止程序,不可能恢复或运行延迟清理语句,不像panic会去找goroutine的defer链表。