Golang Defer: ヒープ割り当て、スタック割り当て、オープンコード遅延

これは投稿の抜粋です。投稿全文はこちらからご覧いただけます: Golang Defer: 基本からトラップまで

defer ステートメントは、おそらく Go を学習し始めるときに最初に非常に興味深いと思うものの 1 つですよね?

しかし、多くの人がつまずくのはそれだけではありません。そして、それを使用するときに私たちが触れていない魅力的な側面がたくさんあります。

たとえば、defer ステートメントには実際には 3 つのタイプがあります (Go 1.22 の時点では、後で変更される可能性があります): オープンコーディングされた defer、ヒープ割り当てされた defer、およびスタック割り当て。それぞれに異なるパフォーマンスがあり、最適に使用されるシナリオも異なります。パフォーマンスを最適化したい場合は、これを知っておくと良いでしょう。

このディスカッションでは、基本からより高度な使用方法まですべてを取り上げ、内部の詳細の一部についても少しだけ掘り下げていきます。

延期とは何ですか?

深く掘り下げる前に、defer について簡単に見てみましょう。

Go では、defer は、周囲の関数が終了するまで関数の実行を遅らせるために使用されるキーワードです。

このスニペットでは、defer ステートメントは、fmt.Println("hello") が main 関数の最後に実行されるようにスケジュールします。したがって、 fmt.Println("world") がすぐに呼び出され、最初に "world" が出力されます。その後、deferを使用したため、メインが終了する前の最後のステップとして「hello」が出力されます。

リーリー

「わかった、いいけど、最後に f.Close() を入れてみませんか?」

閉じるアクションを開くアクションの近くに配置したため、ロジックに従いやすくなり、ファイルを閉じるのを忘れることがなくなります。ファイルが閉じられているかどうかを確認するために関数を下にスクロールする必要はありません。メインのロジックから気が散ってしまいます
遅延関数は、パニック (実行時エラー) が発生した場合でも、関数が返されるときに呼び出されます。
パニックが発生すると、スタックが巻き戻され、遅延関数が特定の順序で実行されます。これについては次のセクションで説明します。

遅延は積み重ねられています

関数内で複数の defer ステートメントを使用すると、それらは「スタック」順序で実行されます。つまり、最後の遅延関数が最初に実行されます。

リーリー
defer ステートメントを呼び出すたびに、次のように、その関数が現在のゴルーチンのリンク リストの先頭に追加されます。

したがって、現在の関数 (または現在のスタック フレーム) 内の遅延関数のみが実行されます。

通常、パニック状態にエラーを入れ、recover(..) でそれをキャッチしますが、文字列、整数など、何でも構いません

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.

以上がGolang Defer: ヒープ割り当て、スタック割り当て、オープンコード遅延の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。