Stefno

Stefno

关注
发信
关注(28)粉丝(399)

Golang之轻松化解defer的温柔陷阱

什么是defer？

defer是Go语言提供的一种用于注册延迟调用的机制：让函数或语句可以在当前函数执行完毕后（包括通过return正常结束或者panic导致的异常结束）执行。

defer语句通常用于一些成对操作的场景：打开连接/关闭连接；加锁/释放锁；打开文件/关闭文件等。

defer在一些需要回收资源的场景非常有用，可以很方便地在函数结束前做一些清理操作。在打开资源语句的下一行，直接一句defer就可以在函数返回前关闭资源，可谓相当优雅。

f, _ := os.Open("defer.txt")
defer f.Close()

注意：以上代码，忽略了err, 实际上应该先判断是否出错，如果出错了，直接return. 接着再判断f是否为空，如果f为空，就不能调用f.Close()函数了，会直接panic的。

为什么需要defer？

程序员在编程的时候，经常需要打开一些资源，比如数据库连接、文件、锁等，这些资源需要在用完之后释放掉，否则会造成内存泄漏。

但是程序员都是人，是人就会犯错。因此经常有程序员忘记关闭这些资源。Golang直接在语言层面提供defer关键字，在打开资源语句的下一行，就可以直接用defer语句来注册函数结束后执行关闭资源的操作。因为这样一颗“小小”的语法糖，程序员忘写关闭资源语句的情况就大大地减少了。

怎样合理使用defer?

defer的使用其实非常简单：

f,err := os.Open(filename)
if err != nil {
    panic(err)
}

if f != nil {
    defer f.Close()
}

在打开文件的语句附近，用defer语句关闭文件。这样，在函数结束之前，会自动执行defer后面的语句来关闭文件。

当然，defer会有小小地延迟，对时间要求特别特别特别高的程序，可以避免使用它，其他一般忽略它带来的延迟。

defer进阶

defer的底层原理是什么？

我们先看一下官方对defer的解释：

翻译一下：每次defer语句执行的时候，会把函数“压栈”，函数参数会被拷贝下来；当外层函数（非代码块，如一个for循环）退出时，defer函数按照定义的逆序执行；如果defer执行的函数为nil, 那么会在最终调用函数的产生panic.

defer语句并不会马上执行，而是会进入一个栈，函数return前，会按先进先出的顺序执行。也说是说最先被定义的defer语句最后执行。先进先出的原因是后面定义的函数可能会依赖前面的资源，自然要先执行；否则，如果前面先执行，那后面函数的依赖就没有了。

在defer函数定义时，对外部变量的引用是有两种方式的，分别是作为函数参数和作为闭包引用。作为函数参数，则在defer定义时就把值传递给defer，并被cache起来；作为闭包引用的话，则会在defer函数真正调用时根据整个上下文确定当前的值。

defer后面的语句在执行的时候，函数调用的参数会被保存起来，也就是复制了一份。真正执行的时候，实际上用到的是这个复制的变量，因此如果此变量是一个“值”，那么就和定义的时候是一致的。如果此变量是一个“引用”，那么就可能和定义的时候不一致。

举个例子：

func main() {
    var whatever [3]struct{}

    for i := range whatever {
        defer func() {
            fmt.Println(i)
        }()
    }
}

执行结果：

2
2
2

defer后面跟的是一个闭包（后面会讲到），i是“引用”类型的变量，最后i的值为2, 因此最后打印了三个2.

有了上面的基础，我们来检验一下成果：

type number int

func (n number) print()   { fmt.Println(n) }
func (n *number) pprint() { fmt.Println(*n) }

func main() {
    var n number

    defer n.print()
    defer n.pprint()
    defer func() { n.print() }()
    defer func() { n.pprint() }()

    n = 3
}

执行结果是：

3
3
3
0

第四个defer语句是闭包，引用外部函数的n, 最终结果是3;
第三个defer语句同第四个；
第二个defer语句，n是引用，最终求值是3.
第一个defer语句，对n直接求值，开始的时候n=0, 所以最后是0;

利用defer原理

有些情况下，我们会故意用到defer的先求值，再延迟调用的性质。想象这样的场景：在一个函数里，需要打开两个文件进行合并操作，合并完后，在函数执行完后关闭打开的文件句柄。

func mergeFile() error {
    f, _ := os.Open("file1.txt")
    if f != nil {
        defer func(f io.Closer) {
            if err := f.Close(); err != nil {
                fmt.Printf("defer close file1.txt err %v\n", err)
            }
        }(f)
    }

    // ……

    f, _ = os.Open("file2.txt")
    if f != nil {
        defer func(f io.Closer) {
            if err := f.Close(); err != nil {
                fmt.Printf("defer close file2.txt err %v\n", err)
            }
        }(f)
    }

    return nil
}

上面的代码中就用到了defer的原理，defer函数定义的时候，参数就已经复制进去了，之后，真正执行close()函数的时候就刚好关闭的是正确的“文件”了，妙哉！可以想像一下如果不这样将f当成函数参数传递进去的话，最后两个语句关闭的就是同一个文件了，都是最后一个打开的文件。

不过在调用close()函数的时候，要注意一点：先判断调用主体是否为空，否则会panic. 比如上面的代码片段里，先判断f不为空，才会调用Close()函数，这样最安全。

defer命令的拆解

如果defer像上面介绍地那样简单（其实也不简单啦），这个世界就完美了。事情总是没这么简单，defer用得不好，是会跳进很多坑的。

理解这些坑的关键是这条语句：

return xxx

上面这条语句经过编译之后，变成了三条指令：

1. 返回值 = xxx
2. 调用defer函数
3. 空的return

1,3步才是Return 语句真正的命令，第2步是defer定义的语句，这里可能会操作返回值。

下面我们来看两个例子，试着将return语句和defer语句拆解到正确的顺序。

第一个例子：

func f() (r int) {
     t := 5
     defer func() {
       t = t + 5
     }()
     return t
}

拆解后：

func f() (r int) {
     t := 5

     // 1. 赋值指令
     r = t

     // 2. defer被插入到赋值与返回之间执行，这个例子中返回值r没被修改过
     func() {
         t = t + 5
     }

     // 3. 空的return指令
     return
}

这里第二步没有操作返回值r, 因此，main函数中调用f()得到5.

第二个例子：

func f() (r int) {
    defer func(r int) {
          r = r + 5
    }(r)
    return 1
}

拆解后：

func f() (r int) {
     // 1. 赋值
     r = 1

     // 2. 这里改的r是之前传值传进去的r，不会改变要返回的那个r值
     func(r int) {
          r = r + 5
     }(r)

     // 3. 空的return
     return
}

因此，main函数中调用f()得到1.

defer语句的参数

defer语句表达式的值在定义时就已经确定了。下面展示三个函数：

func f1() {
    var err error

    defer fmt.Println(err)

    err = errors.New("defer error")
    return
}

func f2() {
    var err error

    defer func() {
        fmt.Println(err)
    }()

    err = errors.New("defer error")
    return
}

func f3() {
    var err error

    defer func(err error) {
        fmt.Println(err)
    }(err)

    err = errors.New("defer error")
    return
}

func main() {
    f1()
    f2()
    f3()
}

运行结果：

<nil>
defer error
<nil>

第1，3个函数是因为作为函数参数，定义的时候就会求值，定义的时候err变量的值都是nil, 所以最后打印的时候都是nil. 第2个函数的参数其实也是会在定义的时候求值，只不过，第2个例子中是一个闭包，它引用的变量err在执行的时候最终变成defer error了。关于闭包在本文后面有介绍。

第3个函数的错误还比较容易犯，在生产环境中，很容易写出这样的错误代码。最后defer语句没有起到作用。

闭包是什么？

闭包是由函数及其相关引用环境组合而成的实体,即：

闭包=函数+引用环境

一般的函数都有函数名，但是匿名函数就没有。匿名函数不能独立存在，但可以直接调用或者赋值于某个变量。匿名函数也被称为闭包，一个闭包继承了函数声明时的作用域。在Golang中，所有的匿名函数都是闭包。

有个不太恰当的例子，可以把闭包看成是一个类，一个闭包函数调用就是实例化一个类。闭包在运行时可以有多个实例，它会将同一个作用域里的变量和常量捕获下来，无论闭包在什么地方被调用（实例化）时，都可以使用这些变量和常量。而且，闭包捕获的变量和常量是引用传递，不是值传递。

举个简单的例子：

func main() {
    var a = Accumulator()

    fmt.Printf("%d\n", a(1))
    fmt.Printf("%d\n", a(10))
    fmt.Printf("%d\n", a(100))

    fmt.Println("------------------------")
    var b = Accumulator()

    fmt.Printf("%d\n", b(1))
    fmt.Printf("%d\n", b(10))
    fmt.Printf("%d\n", b(100))


}

func Accumulator() func(int) int {
    var x int

    return func(delta int) int {
        fmt.Printf("(%+v, %+v) - ", &x, x)
        x += delta
        return x
    }
}

执行结果：

(0xc420014070, 0) - 1
(0xc420014070, 1) - 11
(0xc420014070, 11) - 111
------------------------
(0xc4200140b8, 0) - 1
(0xc4200140b8, 1) - 11
(0xc4200140b8, 11) - 111

闭包引用了x变量，a,b可看作2个不同的实例，实例之间互不影响。实例内部，x变量是同一个地址，因此具有“累加效应”。

defer配合recover

Golang被诟病比较多的就是它的error, 经常是各种error满天飞。编程的时候总是会返回一个error, 留给调用者处理。如果是那种致命的错误，比如程序执行初始化的时候出问题，直接panic掉，省得上线运行后出更大的问题。

但是有些时候，我们需要从异常中恢复。比如服务器程序遇到严重问题，产生了panic, 这时我们至少可以在程序崩溃前做一些“扫尾工作”，如关闭客户端的连接，防止客户端一直等待等等。

panic会停掉当前正在执行的程序，不只是当前协程。在这之前，它会有序地执行完当前协程defer列表里的语句，其它协程里挂的defer语句不作保证。因此，我们经常在defer里挂一个recover语句，防止程序直接挂掉，这起到了try...catch的效果。

注意，recover()函数只在defer的上下文中才有效（且只有通过在defer中用匿名函数调用才有效），直接调用的话，只会返回nil.

func main() {
    defer fmt.Println("defer main")
    var user = os.Getenv("USER_")

    go func() {
        defer func() {
            fmt.Println("defer caller")
            if err := recover(); err != nil {
                fmt.Println("recover success. err: ", err)
            }
        }()

        func() {
            defer func() {
                fmt.Println("defer here")
            }()

            if user == "" {
                panic("should set user env.")
            }

            // 此处不会执行
            fmt.Println("after panic")
        }()
    }()

    time.Sleep(100)
    fmt.Println("end of main function")
}

上面的panic最终会被recover捕获到。这样的处理方式在一个http server的主流程常常会被用到。一次偶然的请求可能会触发某个bug, 这时用recover捕获panic, 稳住主流程，不影响其他请求。

程序员通过监控获知此次panic的发生，按时间点定位到日志相应位置，找到发生panic的原因，三下五除二，修复上线。一看四周，大家都埋头干自己的事，简直完美：偷偷修复了一个bug, 没有发现！嘿嘿！

后记

defer非常好用，一般情况下不会有什么问题。但是只有深入理解了defer的原理才会避开它的温柔陷阱。掌握了它的原理后，就会写出易懂易维护的代码。

Golang之轻松化解defer的温柔陷阱-LMLPHP

参考资料

【defer那些事】https://xiaozhou.net/something-about-defer-2014-05-25.html
【defer代码案例】https://tiancaiamao.gitbooks.io/go-internals/content/zh/03.4.html
【闭包】https://www.kancloud.cn/liupengjie/go/576456
【闭包】http://blog.51cto.com/speakingbaicai/1703229
【闭包】https://blog.csdn.net/zhangzhebjut/article/details/25181151
【延迟】http://liyangliang.me/posts/2014/12/defer-in-golang/
【defer三条原则】https://leokongwq.github.io/2016/10/15/golang-defer.html
【defer代码例子】https://juejin.im/post/5b948b3e6fb9a05d3827beda
【defer panic】https://ieevee.com/tech/2017/11/23/go-panic.html
【defer panic】https://zhuanlan.zhihu.com/p/33743255

02-13 02:40
Powered by LMLPHP ©2024 Stefno 0.043965