Golang Defer: Diperuntukkan timbunan, Diperuntukkan tindanan, Penangguhan berkod terbuka

Ini adalah petikan siaran; siaran penuh boleh didapati di sini: Golang Defer: From Basic To Trap.

Pernyataan penangguhan mungkin merupakan salah satu perkara pertama yang kami dapati agak menarik apabila kami mula belajar Go, bukan?

Tetapi banyak lagi perkara yang mengecewakan ramai orang, dan terdapat banyak aspek menarik yang sering kita tidak sentuh apabila menggunakannya.

Sebagai contoh, penyataan penangguhan sebenarnya mempunyai 3 jenis (mulai Go 1.22, walaupun mungkin berubah kemudian): penangguhan berkod terbuka, penangguhan timbunan diperuntukkan dan diperuntukkan tindanan. Setiap satu mempunyai prestasi yang berbeza dan senario yang berbeza di mana ia digunakan dengan sebaiknya, yang baik untuk diketahui jika anda ingin mengoptimumkan prestasi.

Dalam perbincangan ini, kami akan membincangkan segala-galanya daripada asas kepada penggunaan yang lebih maju, malah kami akan menggali sedikit, sedikit sahaja, beberapa butiran dalaman.

Apakah penangguhan?

Mari kita lihat penangguhan sebelum kita menyelam terlalu dalam.

Dalam Go, tangguh ialah kata kunci yang digunakan untuk menangguhkan pelaksanaan fungsi sehingga fungsi sekeliling selesai.

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

// Output:
// world
// hello

Dalam coretan ini, penyata tangguh menjadualkan fmt.Println("hello") untuk dilaksanakan pada penghujung fungsi utama. Jadi, fmt.Println("dunia") dipanggil serta-merta, dan "dunia" dicetak dahulu. Selepas itu, kerana kami menggunakan penangguhan, "hello" dicetak sebagai langkah terakhir sebelum selesai utama.

Ia sama seperti menyediakan tugasan untuk dijalankan kemudian, sejurus sebelum fungsi keluar. Ini sangat berguna untuk tindakan pembersihan, seperti menutup sambungan pangkalan data, membebaskan mutex atau menutup fail:

func doSomething() error {
  f, err := os.Open("phuong-secrets.txt")
  if err != nil {
    return err
  }
  defer f.Close()

  // ...
}

Kod di atas ialah contoh yang baik untuk menunjukkan cara penangguhan berfungsi, tetapi ia juga merupakan cara yang tidak baik untuk menggunakan penangguhan. Kita akan membincangkannya dalam bahagian seterusnya.

"Baiklah, tetapi kenapa tidak letakkan f.Close() di hujungnya?"

Terdapat beberapa sebab yang baik untuk ini:

• Kami letakkan close action dekat open, jadi lebih senang ikut logik dan elakkan lupa tutup fail. Saya tidak mahu menatal ke bawah fungsi untuk menyemak sama ada fail ditutup atau tidak; ia mengalihkan perhatian saya daripada logik utama.
• Fungsi tertunda dipanggil apabila fungsi kembali, walaupun panik (ralat masa jalan) berlaku.

Apabila panik berlaku, timbunan dibongkar dan fungsi tertunda dilaksanakan dalam susunan tertentu, yang akan kami bincangkan dalam bahagian seterusnya.

Penangguhan bertindan

Apabila anda menggunakan berbilang penyataan penangguhan dalam fungsi, ia dilaksanakan dalam susunan 'tindanan', bermakna fungsi tertunda terakhir dilaksanakan dahulu.

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

// Output:
// 3
// 2
// 1

Setiap kali anda memanggil penyata tangguh, anda menambahkan fungsi itu ke bahagian atas senarai terpaut goroutine semasa, seperti ini:

Dan apabila fungsi itu kembali, ia akan melalui senarai terpaut dan melaksanakan setiap satu dalam susunan yang ditunjukkan dalam imej di atas.

Tetapi ingat, ia tidak melaksanakan semua penangguhan dalam senarai terpaut goroutine, ia hanya menjalankan penangguhan dalam fungsi yang dikembalikan, kerana senarai terpaut penangguhan kami boleh mengandungi banyak penangguhan daripada pelbagai fungsi yang berbeza.

func B() {
  defer fmt.Println(1)
  defer fmt.Println(2)
  A()
}

func A() {
  defer fmt.Println(3)
  defer fmt.Println(4)
}

Jadi, hanya fungsi tertunda dalam fungsi semasa (atau bingkai tindanan semasa) dilaksanakan.

Tetapi terdapat satu kes biasa di mana semua fungsi tertunda dalam goroutine semasa dikesan dan dilaksanakan, dan pada masa itulah panik berlaku.

Tangguh, Panik dan Pulih

Selain ralat masa kompilasi, kami mempunyai banyak ralat masa jalan: bahagi dengan sifar (integer sahaja), di luar sempadan, membatalkan penunjuk sifar dan sebagainya. Ralat ini menyebabkan aplikasi menjadi panik.

Panik ialah satu cara untuk menghentikan pelaksanaan goroutine semasa, melepaskan timbunan dan melaksanakan fungsi tertunda dalam goroutine semasa, menyebabkan aplikasi kami ranap.

Untuk mengendalikan ralat yang tidak dijangka dan menghalang aplikasi daripada ranap, anda boleh menggunakan fungsi pulih dalam fungsi tertunda untuk mengawal semula goroutine yang panik.

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

  panic("This is a panic")
}

// Output:
// Recovered: This is a panic

Biasanya, orang meletakkan ralat dalam keadaan panik dan menangkapnya dengan recover(..), tetapi boleh jadi apa sahaja: rentetan, int, dsb.

In the example above, inside the deferred function is the only place you can use recover. Let me explain this a bit more.

There are a couple of mistakes we could list here. I’ve seen at least three snippets like this in real code.

The first one is, using recover directly as a deferred function:

func main() {
  defer recover()

  panic("This is a panic")
}

The code above still panics, and this is by design of the Go runtime.

The recover function is meant to catch a panic, but it has to be called within a deferred function to work properly.

Behind the scenes, our call to recover is actually the runtime.gorecover, and it checks that the recover call is happening in the right context, specifically from the correct deferred function that was active when the panic occurred.

"Does that mean we can’t use recover in a function inside a deferred function, like this?"

func myRecover() {
  if r := recover(); r != nil {
    fmt.Println("Recovered:", r)
  }
}

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

  panic("This is a panic")
}

Exactly, the code above won’t work as you might expect. That’s because recover isn’t called directly from a deferred function but from a nested function.

Now, another mistake is trying to catch a panic from a different 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
}

Makes sense, right? We already know that defer chains belong to a specific goroutine. It would be tough if one goroutine could intervene in another to handle the panic since each goroutine has its own stack.

Unfortunately, the only way out in this case is crashing the application if we don’t handle the panic in that goroutine.

Defer arguments, including receiver are immediately evaluated

I've run into this problem before, where old data got pushed to the analytics system, and it was tough to figure out why.

Here’s what I mean:

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

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

  a = 20
}

What do you think the output will be? It's 10, not 20.

That's because when you use the defer statement, it grabs the values right then. This is called "capture by value." So, the value of a that gets sent to pushAnalytic is set to 10 when the defer is scheduled, even though a changes later.

There are two ways to fix this.

...

Full post is available here: Golang Defer: From Basic To Trap.

Atas ialah kandungan terperinci Golang Defer: Diperuntukkan timbunan, Diperuntukkan tindanan, Penangguhan berkod terbuka. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!