Golang Defer：堆分配、堆栈分配、开放编码的 Defer

这是帖子的摘录；完整的帖子可以在这里找到：golang defer：从基础到陷阱。

defer 语句可能是我们开始学习 go 时首先发现非常有趣的事情之一，对吗？

但是它还有很多让很多人困惑的地方，并且有很多令人着迷的方面是我们在使用它时经常没有触及的。

例如，defer 语句实际上有 3 种类型（从 go 1.22 开始，尽管稍后可能会改变）：开放编码 defer、堆分配 defer 和堆栈分配。每一种都有不同的性能和不同的最佳使用场景，如果您想优化性能，了解这一点很有帮助。

在本次讨论中，我们将涵盖从基础知识到更高级用法的所有内容，我们甚至会深入研究一些内部细节。

立即学习“go语言免费学习笔记（深入）”；

什么是延期？

在我们深入研究之前，让我们快速了解一下 defer。

在 go 中，defer 是一个关键字，用于延迟函数的执行，直到周围的函数完成。

func main() {
  defer fmt.println("hello")
  fmt.println("world")
}

// output:
// world
// hello

在此代码片段中，defer 语句安排 fmt.println(“hello”) 在 main 函数的最后执行。因此，立即调用 fmt.println(“world”)，并首先打印“world”。之后，因为我们使用了 defer，所以在 main 完成之前的最后一步会打印“hello”。

这就像设置一个任务稍后运行，就在函数退出之前运行。这对于清理操作非常有用，例如关闭数据库连接、释放互斥体或关闭文件：

func dosomething() error {
  f, err := os.open("phuong-secrets.txt")
  if err != nil {
    return err
  }
  defer f.close()

  // ...
}

上面的代码是一个很好的例子来展示 defer 是如何工作的，但这也是一个不好的使用 defer 的方式。我们将在下一节中讨论这个问题。

“好吧，很好，但是为什么不把 f.close() 放在最后呢？”

这样做有几个很好的理由：

• 我们将关闭操作放在打开附近，这样更容易遵循逻辑并避免忘记关闭文件。我不想向下滚动函数来检查文件是否已关闭；它分散了我对主要逻辑的注意力。
• 即使发生panic（运行时错误），延迟函数也会在函数返回时被调用。

发生恐慌时，堆栈将被展开，并且延迟函数将按特定顺序执行，我们将在下一节中介绍。

延迟已堆积

当您在函数中使用多个 defer 语句时，它们会按“堆栈”顺序执行，这意味着最后一个延迟函数会先执行。

func main() {
  defer fmt.println(1)
  defer fmt.println(2)
  defer fmt.println(3)
}

// output:
// 3
// 2
// 1

每次调用 defer 语句时，都会将该函数添加到当前 goroutine 链表的顶部，如下所示：

当函数返回时，它会遍历链表并按照上图所示的顺序执行每一个。

但是请记住，它不会执行 goroutine 链表中的所有 defer，它只运行返回函数中的 defer，因为我们的 defer 链表可能包含来自许多不同函数的许多 defer。

func b() {
  defer fmt.println(1)
  defer fmt.println(2)
  a()
}

func a() {
  defer fmt.println(3)
  defer fmt.println(4)
}

因此，仅执行当前函数（或当前堆栈帧）中的延迟函数。

但是有一种典型情况，当前 goroutine 中的所有延迟函数都被跟踪并执行，那就是发生恐慌的时候。

延迟、恐慌和恢复

除了编译时错误之外，我们还有很多运行时错误：除以零（仅限整数）、越界、取消引用 nil 指针等等。这些错误会导致应用程序出现恐慌。

panic 是一种停止当前 goroutine 执行、展开堆栈并执行当前 goroutine 中的延迟函数的方法，从而导致我们的应用程序崩溃。

为了处理意外错误并防止应用程序崩溃，您可以在延迟函数中使用恢复函数来重新获得对恐慌 goroutine 的控制。

func main() {
  defer func() {
    if r := recover(); r != nil {
      fmt.println("recovered:", r)
    }
  }()

  panic("this is a panic")
}

// output:
// recovered: this is a panic

通常，人们会在恐慌中放入错误并使用recover(..)捕获该错误，但它可以是任何东西：字符串、整数等。

在上面的例子中，延迟函数内部是唯一可以使用recover的地方。让我再解释一下。

我们可以在这里列出一些错误。我在实际代码中至少见过三个这样的片段。

第一个是，直接使用recover作为延迟函数：

func main() {
  defer recover()

  panic("this is a panic")
}

上面的代码仍然会出现恐慌，这是 go 运行时的设计。

recover 函数旨在捕获恐慌，但必须在延迟函数中调用它才能正常工作。

在幕后，我们对恢复的调用实际上是runtime.gorecover，它检查恢复调用是否在正确的上下文中发生，特别是来自发生恐慌时处于活动状态的正确的延迟函数。

“这是否意味着我们不能在延迟函数内的函数中使用恢复，就像这样？”

func myrecover() {
  if r := recover(); r != nil {
    fmt.println("recovered:", r)
  }
}

func main() {
  defer func() {
    myrecover()
    // ...
  }()

  panic("this is a panic")
}

确切地说，上面的代码不会像你想象的那样工作。这是因为恢复不是直接从延迟函数调用，而是从嵌套函数调用。

现在，另一个错误是试图从不同的 goroutine 中捕获恐慌：

func main() {
  defer func() {
    if r := recover(); r != nil {
      fmt.println("recovered:", r)
    }
  }()

  go panic("this is a panic")

  time.sleep(1 * time.second) // wait for the goroutine to finish
}

有道理吧？我们已经知道延迟链属于特定的 goroutine。如果一个 goroutine 可以干预另一个 goroutine 来处理恐慌，那就很困难了，因为每个 goroutine 都有自己的堆栈。

不幸的是，在这种情况下，如果我们不处理该 goroutine 中的恐慌，唯一的出路就是使应用程序崩溃。

延迟参数，包括立即评估接收者

我以前遇到过这个问题，旧数据被推送到分析系统，很难找出原因。

这就是我的意思：

func pushAnalytic(a int) {
  fmt.Println(a)
}

func main() {
  a := 10
  defer pushAnalytic(a)

  a = 20
}

你认为输出会是什么？是10个，不是20个。

那是因为当您使用 defer 语句时，它会立即获取值。这称为“按值捕获”。因此，当延迟被安排时，发送到pushanalytic的a的值被设置为10，即使a稍后发生变化。

有两种方法可以解决这个问题。

…

完整帖子可在此处查看：golang defer：从基础到陷阱。