Fixing For Loops in Go 1.22

社内イベントでLTした時の資料

Link
p8 - https://go.dev/play/p/mjXjtKeT6JD
p14 - https://go.dev/play/p/xeWv2pldX6c
p15 - https://go.dev/play/p/pFoeA2_EKLI
p17 - https://go.dev/play/p/lM8kkEPu8Tw
p18 - https://bugzilla.mozilla.org/show_bug.cgi?id=1619047
p26 - https://go.dev/blog/toolchain
p27 - https://go.dev/play/p/mjXjtKeT6JD?v=gotip
p37 - https://github.com/golang/go/issues/60078
p37 - https://go.dev/wiki/LoopvarExperiment
p44 - https://go.googlesource.com/proposal/+/master/design/60078-loopvar.md

Transcript

1. Fixing For Loops in Go 1.22 @uncle__ko
2. Self Introduction Kohei Ouchi(@uncle__ko) いままでは銀行の勘定系の開発をしたり、ECサイトの開発をしたり、DSP/DMPの開発 をしたり、クレジットカードの開発をしたりしてた 現在はDeveloper Productivity室に在籍 プライベートでは6歳児の父として育児に励んでる
3. Agenda • The Problem • The Fix • The Impact • Summary
4. The Problem
5. The Problem このコードを見てみましょう func main() { done := make(chan bool) values := []string{"a", "b", "c"} for _, v := range values { go func() { fmt.Println(v) done <- true }() } // wait for all goroutines to complete before exiting for _ = range values { <-done } }
6. The Problem このコードはどのように Printされると思いますか? func main() { done := make(chan bool) values := []string{"a", "b", "c"} for _, v := range values { go func() { fmt.Println(v) done <- true }() } // wait for all goroutines to complete before exiting for _ = range values { <-done } }
7. The Problem 実は... func main() { done := make(chan bool) values := []string{"a", "b", "c"} for _, v := range values { go func() { fmt.Println(v) done <- true }() } // wait for all goroutines to complete before exiting for _ = range values { <-done } }
8. The Problem 実は... "c", "c", "c" とPrintされます https://go.dev/play/p/mjXjtKeT6JD func main() { done := make(chan bool) values := []string{"a", "b", "c"} for _, v := range values { go func() { fmt.Println(v) done <- true }() } // wait for all goroutines to complete before exiting for _ = range values { <-done } }
9. Why?󰤇
10. The Problem ループの各繰り返しで変数vの 同じインスタンスが使用される つまり変数のスコープがループ全体 になってる 各クロージャは単一の変数を共有 func main() { done := make(chan bool) values := []string{"a", "b", "c"} for _, v := range values { go func() { fmt.Println(v) done <- true }() } // wait for all goroutines to complete before exiting for _ = range values { <-done } }
11. The Problem クロージャが実行されると fmt.Printlnが実行された時点での 変数vの値を出力 func main() { done := make(chan bool) values := []string{"a", "b", "c"} for _, v := range values { go func() { fmt.Println(v) done <- true }() } // wait for all goroutines to complete before exiting for _ = range values { <-done } }
12. The Problem 各クロージャが起動時に現在の変数vの値をバインドするには 内側のループを各繰り返しで新しい変数を作成するように変更する必要がある たとえば...
13. The Problem 各クロージャが起動時に現在の変数vの値をバインドするには 内側のループを各繰り返しで新しい変数を作成するように変更する必要がある たとえば... 変数をクロージャに引数として渡すとか
14. The Problem 変数vの値が無名関数に 引数として渡される その値はその後 関数内で変数uとしてアクセス可能 https://go.dev/play/p/xeWv2pldX6c func main() { done := make(chan bool) values := []string{"a", "b", "c"} for _, v := range values { go func(u string) { fmt.Println(u) done <- true }(v) } // wait for all goroutines to complete before exiting for _ = range values { <-done } }
15. The Problem もっと簡単な方法は 新しい変数を作成すること これで想定通り動く https://go.dev/play/p/xeWv2pldX6c func main() { done := make(chan bool) values := []string{"a", "b", "c"} for _, v := range values { v := v // create a new 'v'. go func() { fmt.Println(v) done <- true }() } // wait for all goroutines to complete before exiting for _ = range values { <-done } }
16. The Problem 多くの場合では並行処理が関連しているが、必ずしもその限りではない 次の例は、同じ問題が発生するがgoroutineは使用されてない
17. The Problem この例だと "4", "4", "4" が出力される https://go.dev/play/p/lM8kkEPu8Tw func main() { var prints []func() for i := 1; i <= 3; i++ { prints = append(prints, func() { fmt.Println(i) }) } for _, print := range prints { print() } }
18. The Problem この問題はLet's Encryptを含む多くの企業で問題を引き起こした そしてこの種の問題はとても見つけにくい https://bugzilla.mozilla.org/show_bug.cgi?id=1619047
19. The Problem このようなミスを特定するためのツールも開発されているが 変数への参照がその反復より長いかどうかを分析するのは難しい go vetやgoplsで使われているloopclosure analyzerは偽陰性 問題があることが確実な場合のみ報告するが、それ以外は見逃す 偽陽性のチェッカーは、正しいコードが正しくないと指摘することもある
20. The Fix
21. The Fix Go 1.22では、forループを変更して、これらの変数がループごとではなく、各繰り返しで スコープを持つようになる
22. The Fix Go 1.22では、forループを変更して、これらの変数がループごとではなく、各繰り返しで スコープを持つようになる この変更により、いままで見てきた問題が修正され、この種のミスに起因する問題が解 消され、不正確なツールを使用してユーザーにコードを不要に変更させる必要がなくな る
23. 後方互換性は大丈夫なん?🤔
24. The Fix この新しいセマンティクスは go.modファイルでgo 1.22以降を宣言しているモジュールに含まれるパッケージにのみ 適用
25. The Fix この新しいセマンティクスは go.modファイルでgo 1.22以降を宣言しているモジュールに含まれるパッケージにのみ 適用 コードベース全体で新しいセマンティクスへの段階的な更新を開発者が制御できるよう に また、//go:build行を使用してファイルごとに制御することも可能
26. The Fix 前方互換性の作業の結果として、Go 1.21はgo 1.22以降を宣言したコードをコンパイル しようとしない https://go.dev/blog/toolchain そのため、Go 1.22がリリースされたとき、新しいセマンティクスに従って書かれたコード が古いセマンティクスでコンパイルされることはない
27. The Fix ちなみに最初の例に出したコードをGo dev branchで実行すると “a”,”b”,”c”が出力されるようになってる https://go.dev/play/p/mjXjtKeT6JD?v=gotip
28. The Fix Go 1.21にはスコープ変更のプレビューが含まれてる
29. The Fix Go 1.21にはスコープ変更のプレビューが含まれてる GOEXPERIMENT=loopvar を指定してコードをコンパイルすると、新しいセマンティクスがすべてのループに適用さ れる（go.mod の go lineは無視される）
30. The Impact
31. The Impact このような偶数であることを確認する テストがあったとする func TestAllEvenBuggy(t *testing.T) { testCases := []int{1, 2, 4, 6} for _, v := range testCases { t.Run("sub", func(t *testing.T) { t.Parallel() if v&1 != 0 { t.Fatal("odd v", v) } }) } }
32. The Impact Go 1.21では、このテストはパスする t.Parallelは各サブテストをブロックし ループ全体が完了するまで待機 その後すべてのサブテストを 並行して実行するから func TestAllEvenBuggy(t *testing.T) { testCases := []int{1, 2, 4, 6} for _, v := range testCases { t.Run("sub", func(t *testing.T) { t.Parallel() if v&1 != 0 { t.Fatal("odd v", v) } }) } }
33. The Impact ループが終了するとvは常に6になる そのため、このテストはパスしてしまう このテストは実際には失敗するべきであり 1は偶数ではない forループを修正すると この種のバグのあるテストが露呈する func TestAllEvenBuggy(t *testing.T) { testCases := []int{1, 2, 4, 6} for _, v := range testCases { t.Run("sub", func(t *testing.T) { t.Parallel() if v&1 != 0 { t.Fatal("odd v", v) } }) } }
34. The Impact 実際、そんなに影響が出ることはないと思われる
35. The Impact 実際、そんなに影響が出ることはないと思われる Kubernetesでも試されてる
36. The Impact ベースとなるコードに潜在するループ変数のスコープ関連のバグが原因で、2つのテスト が失敗した 比較のために、KubernetesをGo 1.20からGo 1.21に更新したところ、新たに3つのテス トが失敗した ループ変数の変更によって失敗する2つのテストは、通常のリリースの更新と比較して、 新たな大きな負担にはならない
37. The Impact Russ Coxが試してるIssue https://github.com/golang/go/issues/60078 Wikiにも詳細が載ってる https://go.dev/wiki/LoopvarExperiment
38. より多くのallocationが発生して プログラムが遅くならんの?🤔
39. The Impact 遅くなることもある
40. The Impact 遅くなることもある …が多くの場合は気にしなくてよい程度 public “bent” bench suiteのベンチマークでは、統計的に有意なパフォーマンスの差は 見られなかった ほとんどのプログラムは影響を受けないものと思われる
41. The Impact なにかあったとしても pprof --alloc_objects などで特定は可能
42. Summary
43. Summary • 変数がループ全体ではなく各繰り返しでスコープを持つようになる • 後方互換性が確保 ◦ go.modファイルでgo 1.22以降を宣言しているモジュールに含まれるパッケー ジにのみ適用 • テストなどがコケるようになるかも ◦ とはいえGo 1.22の導入に備えてloopclosure analyzerが強化されてる
44. Summary もっと詳しく知りたい人はぜひProposal見てみてね https://go.googlesource.com/proposal/+/master/design/60078-loopvar.md