defer
是Golang一大语言特色,它扮演的是类似Java中finally
的角色。用于执行释放资源的一些操作。
defer语句定义在函数内,后面跟一个函数,被defer的函数会在defer所在的函数结果前被执行。defer能够保证函数不管以何种方式结束(return或panic),被defer的函数一定被执行。
defer可以被定义在函数中的任何地方,这意味着当我们打开一个资源,马上可以使用defer声明它的释放,这样我们在编写后面的代码的时候就不用操心这个资源的释放了。函数结束的时候会自动执行释放操作:
func ReadFile() error {
// 打开了一些资源
file, err := os.Open("file")
if err != nil {
return err
}
// 这条语句会自动在函数结束时执行
defer file.Close()
// 继续执行后面的操作,而不用操心file的释放了
...
}
这就是defer的一般用法了,当然,defer远没有这么简单,下面我们来扣扣defer的语法细节:
如果一个函数里面有多个defer,那么会如何执行呢?观察下面的代码:
package main
import "fmt"
func main() {
deferFunc()
}
func deferFunc() {
defer fmt.Println("exec 1")
defer fmt.Println("exec 2")
defer fmt.Println("exec 3")
}
注意,defer的执行顺序遵循后进先出
的原则,后面的defer语句将会被先执行,因此执行的顺序应该是从下至上的,下面是输出:
exec 3
exec 2
exec 1
我们只需要知道defer是从下到上执行的即可。
defer的顺序还有更加深层次的话题,那就是defer和return之间的执行顺序。
观察下面的代码:
package main
import "fmt"
func main() {
fmt.Println(deferReturn())
}
func deferReturn() (i int) {
defer func() {
i += 3
}()
i = 3
return
}
执行一下,结果输出"6"
。这说明,defer是在函数return之前执行的。而具名返回参数i
的作用域是整个函数,因此理所当然地,defer可以访问i
并对其做修改。
当函数遇到panic
,defer仍然会被执行。Go会先执行所有的defer链表(该函数的所有defer),当所有defer被执行完毕且没有recover
时,才会进行panic。
package main
import "fmt"
func main() {
deferPanic()
}
func deferPanic() {
defer fmt.Println("exec 1")
defer fmt.Println("exec 2")
defer fmt.Println("exec 3")
panic("出了点小小的错误")
}
所有的defer都没有recover,因此会先从下到上执行所有的defer,最后进行panic,程序退出:
exec 3
exec 2
exec 1
panic: 出了点小小的错误
我们可以在defer中进行recover,如果defer中包含recover,则程序将不会再进行panic,观察下面代码:
package main
import "fmt"
func main() {
deferPanic()
}
func deferPanic() {
defer fmt.Println("最后执行")
defer func() {
if err := recover(); err != nil {
fmt.Println("发生了错误!")
}
}()
fmt.Println("错误之前")
panic("出了点小小的错误")
fmt.Println("错误之后")
}
程序输出:
错误之前
发生了错误!
最后执行
和之前的区别就是程序没有再panic退出了。
熟悉其它语言诸如C++
、Java
、Python
的应该知道,这实际上就是这些语言的try...catch
功能。所以所谓的golang没有try...catch功能,处理异常都是返回error
的说法其实不准确,Go是有类似try...catch
的功能的,只不过写法和其它语言不一样。上面的代码到Java中就是这么写了:
public class TestTryCatch {
public static void main(String[] args) {
try {
System.out.Println("错误之前");
throw new Exception();
System.out.Println("错误之后");
} catch (Exception e) {
System.out.Println("发生了错误!");
} finally {
System.out.Println("最后执行");
}
}
}
程序输出和上面的是一样的。
如果是其它函数的panic,recover可以成功吗?观察下面代码:
package main
import "fmt"
func main() {
defer func() {
if err := recover(); err != nil {
fmt.Println("产生了错误!")
}
}()
panicFun()
}
func panicFun() {
panic("我是错误")
}
输出:
产生了错误!
可见,main对panicFunc
的panic进行了恢复。
而如果panicFunc自己对panic进行了恢复,则main的恢复将不会再执行。观察下面的代码:
package main
import "fmt"
func main() {
defer func() {
if err := recover(); err != nil {
fmt.Println("main修复错误!")
}
}()
panicFunc()
}
func panicFunc() {
defer func() {
if err := recover(); err != nil {
fmt.Println("panicFunc修复错误!")
}
}()
panic("我是错误")
}
程序输出:
panicFunc修复错误!
main并没有去修复panic,因为该panic已经被先执行的panicFunc给修复掉了。
最后一个问题来,recover可以检测到其它goroutine的panic吗?看下面的代码:
package main
import (
"fmt"
"time"
)
func main() {
defer fmt.Println("main defer")
defer func() {
if err := recover(); err != nil {
fmt.Println("发生了错误!")
}
}()
go func() {
defer fmt.Println("other defer")
panic("一些小问题")
}()
time.Sleep(1*time.Second)
fmt.Println("程序执行完毕")
}
程序输出:
other defer
panic: 一些小问题
注意这里面有3个defer,有两个是main的defer,其中一个进行了recover;另外一个是另一个goroutine的defer。我们观察,尽管代码中的goroutine是由main创建的,但是当其发生了panic之后,main goroutine的defer并不会被主动执行。
但是,上面的例子退出是因为main中有recover的defer根本没有机会执行,那么,如果给它执行的机会呢?panic是否会被recover?观察下面的代码:
package main
import (
"fmt"
"time"
)
func main() {
defer fmt.Println("main defer")
defer func() {
if err := recover(); err != nil {
fmt.Println("发生了错误!")
}
}()
go func() {
defer fmt.Println("other defer")
time.Sleep(2 * time.Second) // 隔久一点再产生panic
panic("一些小问题")
}()
time.Sleep(1*time.Second)
fmt.Println("程序执行完毕")
time.Sleep(4*time.Second)
}
程序输出:
程序执行完毕
other defer
panic: 一些小问题
还是发生了panic。可见main的defer不进行recover并不是时间的原因。而是main的recover()
并不能发现其它goroutine的panic。
我们可以总结一下:
defer有一个非常费解的陷阱,话不多说,先看下面的代码:
package main
import "fmt"
func main() {
defer addAndPrint(addAndPrint(1, 2), 3) // defer1
defer addAndPrint(addAndPrint(4, 5), 6) // defer2
}
func addAndPrint(a, b int) int {
sum := a + b
fmt.Printf("%d + %d = %d\n", a, b, sum)
return sum
}
很多golang的新手看到这段代码,会想,按照defer的执行顺序,应该会先执行defer2,再执行defer1,因此理所当然地这段代码应该输出:
4 + 5 = 9
9 + 6 = 15
1 + 2 = 3
3 + 3 = 6
真实运行结果让人大跌眼镜:
1 + 2 = 3
4 + 5 = 9
9 + 6 = 15
3 + 3 = 6
产生这个结果的原因是,在定义defer的时候,go就需要确定defer语句的函数的参数。因此go顺序执行到defer定义的时候,会直接把defer函数的参数计算出来。
在顺序执行到defer1定义时,其第一个参数是一个函数,因此Go会先执行这个函数,所以第一个执行的应该是1 + 2 = 3
,随后遇到defer2,参数也有函数,执行该函数,第二个执行的就是4 + 5 = 9
。随后函数结束,再按照defer的逆序执行defer2,defer1。这时候它们的参数已经被确定,不再需要执行其他函数。
也就是说,Go保证在函数执行结束后,该defer处仅有这个函数执行,其参数在函数结束前已经全部确定好,不需要再执行其他函数来确定参数。