」工欲善其事,必先利其器。「—孔子《論語.錄靈公》
首頁 > 程式設計 > Golang Defer:堆疊分配、堆疊分配、開放式編碼的 Defer

Golang Defer:堆疊分配、堆疊分配、開放式編碼的 Defer

發佈於2024-08-19
瀏覽:201

这是帖子的摘录;完整的帖子可以在这里找到:Golang Defer: From Basic To Trap.

defer 语句可能是我们开始学习 Go 时首先发现非常有趣的事情之一,对吧?

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

Golang Defer: Heap-allocated, Stack-allocated, Open-coded Defer

堆分配、堆栈分配、开放编码延迟

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

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

什么是延期?

在我们深入探讨之前,让我们快速浏览一下 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 链表的顶部,如下所示:

Golang Defer: Heap-allocated, Stack-allocated, Open-coded 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)
}

因此,仅执行当前函数(或当前堆栈帧)中的延迟函数。

Golang Defer: Heap-allocated, Stack-allocated, Open-coded Defer

Goroutine 延迟链

但是有一种典型情况,当前 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作为延迟函数:

func main() {
  defer recover()

  panic("This is a panic")
}

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

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

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

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

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: From Basic To Trap。

版本聲明 本文轉載於:https://dev.to/func25/golang-defer-heap-allocated-stack-allocated-open-coded-defer-1h9o?1如有侵犯,請聯絡[email protected]刪除
最新教學 更多>

免責聲明: 提供的所有資源部分來自互聯網,如果有侵犯您的版權或其他權益,請說明詳細緣由並提供版權或權益證明然後發到郵箱:[email protected] 我們會在第一時間內為您處理。

Copyright© 2022 湘ICP备2022001581号-3