defer 的价值

在Go语言中，defer作为一项功能强大且应用广泛的关键字，能够使函数调用的执行被推迟至包含该defer语句的函数返回之时。这种延迟执行机制为资源管理工作带来了显著便利，可确保无论函数以何种方式退出——无论是正常返回还是发生panic——相关的清理操作均能得到执行。

defer的核心价值再于对资源管理代码的简化，进而提升代码的可读性与健壮性。试想在未使用defer的函数中，若存在多个返回路径，就必须在每个返回点之前逐一添加资源清理代码。而在使用defer之后，只需在资源创建完成后立即调用defer注册清理函数，如此一来，即便后续新增了返回路径，也无需担忧会遗漏资源清理环节。

不过，defer同样存在其复杂性与潜在陷阱。随着Go版本的迭代演进，尤其是从1.13版本到1.14版本，defer的实现机制发生了重大优化。这些优化不仅带来了性能上的提升，同时也改变了defer在部分场景下的行为表现。

机制和原理

执行规则

defer语句的语法非常简单，只需要在函数调用前加上defer关键字即可。例如：

defer fmt.Println("world")

关于defer的执行，有三条核心规则需要牢记：

延迟函数的参数在defer语句出现时就已经确定：这意味着即使在defer语句之后修改了相关变量，也不会影响延迟函数的参数值。
延迟函数执行按后进先出（LIFO）顺序：多个defer语句注册的延迟函数会按照”后注册先执行”的顺序执行，就像栈结构一样。
延迟函数可以操作主函数的具名返回值：如果函数有具名返回值，延迟函数可以在函数返回前修改其值。

实现原理和背后的数据结构

从实现角度看，defer的工作原理涉及到几个关键的数据结构和运行时函数。在Go语言中，每个defer语句都会被转换为对runtime.deferproc函数的调用，而在函数返回前，会插入对runtime.deferreturn函数的调用，用于执行所有已注册的延迟函数。

defer的核心数据结构是_defer结构体，它定义在runtime包中，大致如下：

type _defer struct {
    siz     int32    // 包含参数和结果的大小
    started bool     // 标记defer是否已经执行
    heap    bool     // 是否为堆分配
    openDefer bool   // 是否经过开放编码优化
    sp        uintptr // 调用者栈指针
    pc        uintptr // 程序计数器
    fn        *funcval // 延迟处理的函数
    _panic    *_panic // 触发延迟调用的panic（如果有的话）
    link      *_defer // 指向下一个_defer结构体的指针
    // 以下是Go 1.14新增的字段，用于支持开放编码优化
    fd   unsafe.Pointer // 函数相关的funcdata
    varp uintptr        // 栈帧中varp的值
    framepc uintptr      // 当前栈帧的pc值
}

三个机制

在Go语言的发展过程中，defer经历了三种不同的实现机制，分别是堆分配、栈分配和开放编码（Open Coded）。这三种机制各有优缺点，Go编译器会根据具体情况选择最合适的实现方式。

堆分配（Go 1.12及之前）：每个defer语句都会在堆上分配一个_defer结构体，主要缺点是堆分配和销毁带来的性能开销。
栈分配（Go 1.13引入）：在栈上分配_defer结构体，避免了堆分配的开销，提高了性能。
开放编码（Go 1.14引入）：编译器会直接将延迟函数的调用插入到函数返回之前，省去了_defer结构体和链表的使用，极大地提升了性能。

1.14 针对 defer的优化

开放编码？？

Go 1.14引入的开放编码（Open Coded）机制是defer优化的核心。这种机制的基本思想是在编译阶段直接将延迟函数的调用插入到函数返回之前，而不是通过运行时的deferproc和deferreturn函数来管理。

开放编码机制的工作原理如下：

延迟函数的直接插入：当编译器遇到defer语句时，如果满足开放编码的条件，它会直接在函数的每个返回点之前插入延迟函数的调用。
延迟比特（Defer Bits）：为了处理条件性defer，开放编码机制引入了延迟比特的概念。延迟比特是一个字节（8位）的变量，每一位对应一个defer语句。
开放编码的条件：函数内的defer数量不超过8个、不在循环中、函数的return语句数量与defer语句数量的乘积不超过15、没有禁用编译器优化。

性能up up up！

func top(max int) int {
    total := 0
    for i := 0; i < max; i++ {
        total += i
    }
    return total
}

func MSP() {
    defer func() {
        top(10)
    }()
    top(100)
}

func CMP() {
    top(100)
    top(10)
}

func BenchmarkConnext(b *testing.B) {
    for i := 0; i < b.N; i++ {
        MSP()
    }
}

func BenchmarkPanCloud(b *testing.B) {
    for i := 0; i < b.N; i++ {
        CMP()
    }
}

开放编码对panic处理的影响

虽然开放编码机制大大提升了defer的性能，但它也对panic处理产生了一些影响。在开放编码机制下，延迟函数是直接插入到函数中的，而不是注册到_defer链表中。因此，当panic发生时，这些开放编码的defer不会被自动捕获，需要通过栈扫描的方式来发现。

为了支持这种情况，Go 1.14在_defer结构体中添加了几个新的字段（如fd、varp、framepc），用于辅助栈扫描。这些字段记录了与开放编码defer相关的函数信息，使得在panic发生时能够正确地找到并执行这些延迟函数。

实务指南

资源管理：文件、锁与网络连接

defer最常见的应用场景是资源管理，确保在函数执行完毕后释放资源。以下是几种常见的资源管理场景：

文件场景

func readFile(path string) ([]byte, error) {
    file, err := os.Open(path)
    if err != nil {
        return nil, err
    }
    defer file.Close() // 确保文件会被关闭，无论函数如何返回
    return io.ReadAll(file)
}

互斥锁管理

var mu sync.Mutex
var count int

func increment() {
    mu.Lock()
    defer mu.Unlock() // 确保锁会被释放，即使函数发生panic
    count++
}

网络连接管理

func connectToServer(addr string) error {
    conn, err := net.Dial("tcp", addr)
    if err != nil {
        return err
    }
    defer conn.Close() // 确保连接会被关闭
    // 处理连接...
    return nil
}

并发编程中的defer使用

在并发编程中，defer也有一些特殊的应用场景：

func processData(data []int, wg *sync.WaitGroup) {
    defer wg.Done() // 确保在函数返回时通知WaitGroup
    // 处理数据...
}

func main() {
    var wg sync.WaitGroup
    data := []int{1, 2, 3, 4, 5}
    for _, d := range data {
        wg.Add(1)
        go processData(d, &wg)
    }
    wg.Wait() // 等待所有goroutine完成
}

注意事项

优先使用defer进行资源管理：当打开资源后，应立即使用defer来注册清理函数。
避免在循环中使用defer：在循环中使用defer可能导致性能问题和资源泄漏。
了解defer的性能特性：在Go 1.14及之后的版本中，defer的性能已经非常高效，几乎可以忽略不计。
注意defer的参数求值时机：由于defer的参数在defer语句出现时就已经确定，因此在使用闭包或引用外部变量时需要特别小心。
考虑使用匿名函数增强defer的灵活性：当需要更复杂的逻辑或条件处理时，可以将defer与匿名函数结合使用。

陷阱

参数求值时机带来的问题

defer的第一个主要陷阱是其参数求值的时机。如前所述，defer语句中的函数参数在defer语句出现时就已经确定，而不是在延迟函数执行时确定。这个特性可能导致一些不易察觉的问题。

func deferParameterIssue() {
    i := 0
    defer fmt.Println("defer 1:", i) // i的值在defer时被捕获为0
    i++
    defer fmt.Println("defer 2:", i) // i的值在defer时被捕获为1
    i++
}
// 输出：
// defer 2: 1
// defer 1: 0

当使用指针或引用类型时，情况会有所不同。例如：

func deferPointerIssue() {
    i := 0
    defer func(p *int) {
        fmt.Println("defer:", *p) // 输出defer: 2
    }(&i) // 传递i的地址，闭包会引用该地址
    i++
    i++
}

延迟函数执行顺序的复杂性

defer的第二个主要陷阱是其执行顺序的复杂性。虽然规则本身很简单（后进先出），但在嵌套defer或与其他控制结构结合使用时，可能会导致意外的结果。

func nestedDefer() {
    defer fmt.Println("A")
    defer func() {
        defer fmt.Println("C")
        fmt.Println("B")
    }()
    defer fmt.Println("D")
}
// 输出：
// D
// B
// C
// A

开放编码机制下的特殊问题

Go 1.14引入的开放编码机制虽然大大提升了defer的性能，但也带来了一些特殊的问题和限制。

开放编码的条件限制：开放编码机制有严格的条件限制，如defer数量不超过8个、不在循环中等。
panic处理的变化：在开放编码机制下，defer是直接插入到函数中的，当panic发生时，这些开放编码的defer不会被自动捕获，需要通过栈扫描的方式来发现。
延迟比特的限制：开放编码机制使用一个字节（8位）的延迟比特来跟踪哪些defer需要执行，这意味着一个函数中最多只能有8个开放编码的defer。

Go Defer的魔法和陷阱