詳解！defer panic recover のしくみ / Understanding defer, panic, and recover

golang\.tokyo #40 にて発表した内容です
https://golangtokyo.connpass.com/event/365231/

Transcript

1. 詳解！defer / panic / recover のしくみ 2025/09/01(月) golang.tokyo #40
2. 自己紹介 @convto 株式会社LayerX所属 たまにGoのランタイムを読んだりしてい ます (読みはこんぶとです)
3. defer 便利ですよね
4. defer は便利 - 安全にリソース解放ができたり - 安全に recover できたり - 「最後に実行される」という性質は便利
5. defer について知っていること - その関数の最後に実行される - 複数あると LIFO で実行される
6. ぼくは defer のことをなにも知らない
7. ということで調べる - どこから調べよう - 組み込み予約語なので実装自体は runtime にありそう - どの runtime 関数や構造によって管理されているかはわからない
8. ということで調べる - どこから調べよう - 組み込み予約語なので実装自体は runtime にありそう - どの runtime 関数や構造によって管理されているかはわからない
9. どの関数がとっかかりになるか探そう - こういうときは、最小コードを書いて go tool compile からの go tool objdump が 便利 - 最小コードはさっきの→で - 以降 go 1.25.0 でやっていきます o tool compile main.go
10. go tool compile & objdump 結果
11. go tool compile & objdump 結果
12. runtime.deferreturn をみる - panic .go に処理が書いてある - _panic という構造にマークをつけてる - pc, sp を登録 - nextDefer を呼ぶ
13. なるほどわからん
14. がとっかかりは得られた
15. とっかかり - コメントにあるとおり deferreturn は caller 側の最後に defer 評価を差し込むような 挙動を示しそう - これはさっき貼った objdump の結果とも一致する - おそらく nextDefer で LIFO の defer スタックを消化していきそう - 消化する場所はここっぽいんだけど、積んでるのはどこ？ - _panic 構造 に色々処理が生えてそう
16. defer スタックどこで積んでるの
17. defer スタックを積むのはどこ？ - さっきの objdump したとき、なんか関数積まれてた - そいつがおそらく defer に登録した関数なので、関数名とかを書いてもう一回見て みる
18. defer スタックを積むのはどこ？
19. objdump
20. objdump
21. objdump - なんか積まれてそう - deferreturn が開始点で、スタック で defer func を呼び出す感じっぽ い - deferreturn は defer の開始点を 初期化し、さらにここに積んだ defer を nextDefer で全て消化して そう
22. defer スタックどこで消化してるの
23. スタック消化 - go1.14くらいで Open-Coded defer という最適化が入ったっぽい - https://github.com/golang/proposal/blob/master/design/34481-opencoded -defers.md - これはめちゃざっくりいうと、コンパイラ側で defer チェーンをいい感じに評価して、 そのままコンパイル結果で展開してしまうというアプローチ - 関数内の defer の数が 8 個以下だとこの最適化通るらしい - ので今回の例はこのパスを通って、コンパイラ側で展開されているはず
24. nextDefer - こいつがスタックに積まれた defer を消化していそう - deferreturn マーク有無でチェッ ク分岐がある - recover マークがついてれば mcall でそこに飛んじゃう(制御 戻ってこない！) - recover はマークするだけな気配
25. nextDefer - さっき話してた Open-Coded 最適化を 考慮した箇所もある
26. nextDefer - その後 deferconvert と popDefer が呼び出される - みるものが残ってる時は true を返して呼び出し元の探索を 継続
27. defer の仕組みは概ねわかった
28. 次は panic / recover
29. とっかかりをみる - さっきとおなじく objdump - recover は defer の実装から、recovered フラグを立てていそう
30. 最小コード
31. objdump
32. objdump
33. みると良さそうなところがわかった - gorecover と gopanic をみるといい感じそう - よしみていくぞ
34. recover
35. nextDefer - defer 評価時に recovered だっ たらそこに飛ぶだけだったことを 思い出そう - ということは recovered ってフラ グ立てるだけなんでは？
36. gorecover - やっぱりそうでした - 条件満たしたら recovered にす るだけ
37. panic
38. gopanic - ざっくりいうと print して fatalpanic を呼び出している - 面白いところで言うと、読み間違ってなければ多分その時点までの defer スタック を評価したりしてる - panic しても defer は実行される！(落ち着いて考えると、そうじゃないと recover できない)
39. まとめ
40. ざっくり関係 関数 deferreturn ←コンパイラによって関数末尾に挿入、実行時 スタックから関数を評価 (recovered だと panic からも復帰できる) defer に登録され た関数 gorecover ↑ panic起きてるときに recovered 立てる gopanic ← fatalpanic 投げる
41. いい感じにわかってきた - 今回は出力からボトムアップでみていったが、結構コンパイラが仕事してそう - 評価は deferreturn を起点に実行時にやられそう - Open-Coded 最適化パスを通ったときは既に展開されてて、順序通り評価するだけ？ - 「panic 時も defer は評価する」が守られてるから recover もできる - つぎはコンパイラ側の仕事もみてみたい
42. そもそも defer 周りの仕組みがわかって なにがうれしいの？
43. しくみがわかってうれしい
44. というのは冗談で - 仕組みがわかると評価順についてちょっと自信が持てたりする - 自前で似たようなことやりたくなったとき、参考にできる - こういう引き出しを増やすのは楽しいし、さらにいつか役に立つかもしれない！お 得！ - とくに go は runtime におもしろ実装が多く、かつ(深入りしすぎなければ) go で実 装されてるので、気になる実装があったら確認してみるとおもしろいかもしれませ ん！
45. ご清聴ありがとうございました