歴史から学ぶ、Goのメモリ管理基礎

2026/1/9 BuriKaigi 2026にて登壇した際の資料です。

Transcript

1. Takuto Nagami @logica0419 歴史から学ぶ Goのメモリ管理基礎
2. メモリ管理を知らない / 理解に苦しんでいる人？
3. 【通説】 メモリ管理は難しい 僕も結構苦しんでいました
4. メモリ管理ってなんだ？ • メモリ管理は広い概念 ◦ マシン、OS、言語など領域によって意味が異なる • プログラミング言語の領域で言うと… ◦ どのようにデータ(変数)が メモリ内で管理されるかを 決める戦略
5. なぜメモリ管理を気にするのか？ • アプリケーションのパフォーマンス向上 • Go自身のメンテナンスにはメモリ管理の知識が必要 • 深堀りすると面白い！ 中でも、特にパフォーマンス 向上が大きなモチベーション
6. メモリ周りのパフォーマンス向上例 • たった一つのメモリ割り当ての変更だけで、CPU使用率 57%削減、メモリ使用量99%削減した例も！
7. メモリ管理のセッションは難しい！
8. メモリ管理のセッションは難しい！
9. メモリ管理のセッションは難しい！
10. メモリ管理のセッションは難しい！
11. メモリ管理のセッションは難しい！
12. メモリ管理のセッションは難しい！ 正直わからん！ ではなぜ難しいんだろう？
13. 学習プロセス: Why, What and How アプリケーションに新機能を追加するとき
14. 学習プロセス: Why, What and How アプリケーションに新機能を追加するとき Why なぜ必要 なのか
15. 学習プロセス: Why, What and How Why なぜ必要 なのか What 何を追加 するのか アプリケーションに新機能を追加するとき
16. 学習プロセス: Why, What and How Why なぜ必要 なのか What 何を追加 するのか How どのように 実装するのか アプリケーションに新機能を追加するとき
17. アプリケーションに新機能を追加するとき 学習プロセス: Why, What and How Why なぜ必要 なのか What 何を追加 するのか How どのように 実装するのか 既存セッションは メモリ管理がどのように 実装されているかに フォーカスしがち
18. 学習プロセス: Why, What and How Why なぜ必要 なのか What 何を追加 するのか How どのように 実装するのか アプリケーションに新機能を追加するとき
19. 今日お話するのは メモリ管理の 「なぜ」と「何」です！ それぞれの戦略がなぜ生まれ、何をするのか学びましょう
20. 前提: Goが提供するコンポーネント • コンパイラ ◦ ソースコードを実行ファイル (バイナリ) にする • ランタイム ◦ 実行中、書いたソースコードと一緒に動く
21. 前提: Goが提供するコンポーネント ソース コード • コンパイラ ◦ ソースコードを実行ファイル (バイナリ) にする • ランタイム ◦ 実行中、書いたソースコードと一緒に動く go build
22. 前提: Goが提供するコンポーネント ソース コード 実行 ファイル go build • コンパイラ ◦ ソースコードを実行ファイル (バイナリ) にする • ランタイム ◦ 実行中、書いたソースコードと一緒に動く
23. 前提: Goが提供するコンポーネント コンパイラ の仕事 • コンパイラ ◦ ソースコードを実行ファイル (バイナリ) にする • ランタイム ◦ 実行中、書いたソースコードと一緒に動く ソース コード 実行 ファイル go build
24. 前提: Goが提供するコンポーネント (バイナリを実行) • コンパイラ ◦ ソースコードを実行ファイル (バイナリ) にする • ランタイム ◦ 実行中、書いたソースコードと一緒に動く コンパイラ の仕事 ソース コード 実行 ファイル go build
25. 前提: Goが提供するコンポーネント ランタイム の仕事 • コンパイラ ◦ ソースコードを実行ファイル (バイナリ) にする • ランタイム ◦ 実行中、書いたソースコードと一緒に動く コンパイラ の仕事 ソース コード 実行 ファイル go build (バイナリを実行)
26. 前提: Goが提供するコンポーネント go run • コンパイラ ◦ ソースコードを実行ファイル (バイナリ) にする • ランタイム ◦ 実行中、書いたソースコードと一緒に動く コンパイラ の仕事 ソース コード 実行 ファイル go build (バイナリを実行) ランタイム の仕事
27. メモリとは何か / 古のメモリ管理
28. メモリとは何か メモリ = RAM (Random Access Memory)
29. メモリとは何か メモリ = RAM (Random Access Memory) ↑ ストレージ (HDD/SSD)
30. メモリとは何か メモリ = RAM (Random Access Memory) ↑ ストレージ (HDD/SSD)
31. メモリを図解する . . . • メモリはアプリケーションから Key-Valueストアとして使用 ◦ Key: メモリアドレス ◦ Value: 各アドレスに1バイト ※ OSはRAMを分割し、それぞれの プロセスに「仮想メモリ」として割り当てる (詳しくは「仮想メモリ」で検索) 0x0000 0x0001 0x0002 0x0003
32. アセンブリにおけるメモリの読み書き . . . . . . 0x0000 0x0001 0x0002 0x0003 {address}
33. アセンブリにおけるメモリの読み書き . . . . . . 書き込み 0x0000 0x0001 0x0002 0x0003 {address} 1 1
34. アセンブリにおけるメモリの読み書き . . . . . . 読み込み 0x0000 0x0001 0x0002 0x0003 {address} 1 1 %eax (CPUレジスタ)
35. 【つらみ】直感的だが、かなりつらい • プログラマが、使うメモリアドレスを全て覚えておく 必要がある 🤯
36. 変数の誕生 / スタックとヒープ
37. 高級プログラミング言語の誕生 • 1957: Fortranがリリース ◦ 「最初」の高級プログラミング言語 • COBOL, BASIC, PASCAL, C... からGoに至るまで、様々 な言語が開発されてきた
38. データの抽象化 - 変数 . . . (変数)
39. データの抽象化 - 変数 . . . . . . . . . . . {a addr} 12 a (変数) 12
40. データの抽象化 - 変数 a (変数) 12 {a addr} {b addr} b 34 . . . . . . . . . 12 34
41. データの抽象化 - 変数 a (変数) 12 b 34 {a addr} {b addr} . . . . . . . . . 12 34 プログラマは 変数の名前だけ 認識すれば良い
42. プログラマーはアドレスを 覚える必要ナシ🙌 代わりに言語側に 管理責任が生まれる😨
43. データを配置するためのルールが欲しい {a addr} ? {b addr} ? . . . . . . . . . 12 34
44. 関数呼び出し
45. main() 関数呼び出し
46. 呼び出し main() 関数呼び出し
47. 呼び出し main() a() 関数呼び出し
48. 関数呼び出し 呼び出し main() a() 呼び出し
49. 関数呼び出し 呼び出し main() a() 呼び出し b()
50. 関数呼び出し 呼び出し main() a() return
51. 関数呼び出し 呼び出し main() a()
52. 関数呼び出し return main()
53. 関数呼び出し main()
54. 関数呼び出し プログラム終了
55. 関数呼び出しのデータ構造 Last In, First Out (LIFO)...? main() a() 呼び出し main() a() return
56. 関数呼び出しのデータ構造 First In, First Out (FIFO)...? main() a() 呼び出し main() a() return そう、 スタックですね！
57. . . . スタック メモリ領域
58. . . . main() stack frame スタック メモリ領域 {main() s.f. addr}
59. スタックフレーム • メモリ内における「関数」の表現方法 ◦ それぞれのフレームがスコープになる • 構造はABIによって定められている ◦ ローカル変数 ◦ (一部) 引数 ◦ 自分を呼び出した関数のスタックフレームアドレス ◦ 別関数を呼び出した場所 などが格納される a() stack frame • 10行目で呼び出し • main()にreturn 5 7
60. . . . main() stack frame スタック メモリ領域 {main() s.f. addr}
61. . . . main() stack frame 5 スタック メモリ領域 {main() s.f. addr} {v addr}
62. . . . main() stack frame • 3行目で呼び出し 5 スタック メモリ領域 {main() s.f. addr} {v addr}
63. . . . main() stack frame • 3行目で呼び出し 5 a() stack frame スタック メモリ領域 {a() s.f. addr} {main() s.f. addr} {v addr}
64. . . . main() stack frame • 3行目で呼び出し 5 a() stack frame • main()にreturn スタック メモリ領域 {a() s.f. addr} {main() s.f. addr} {v addr}
65. . . . main() stack frame • 3行目で呼び出し 5 a() stack frame • main()にreturn 5 スタック メモリ領域 {a() s.f. addr} {arg addr} {main() s.f. addr} {v addr}
66. . . . main() stack frame • 3行目で呼び出し 5 a() stack frame • main()にreturn 5 arg+2= 7 スタック メモリ領域 {a() s.f. addr} {arg addr} {a addr} {main() s.f. addr} {v addr}
67. . . . main() stack frame • 3行目で呼び出し 5 a() stack frame • main()にreturn 5 7 スタック メモリ領域 {a() s.f. addr} {arg addr} {a addr} {main() s.f. addr} {v addr}
68. . . . main() stack frame • 3行目で呼び出し 5 a() stack frame • main()にreturn 5 7 スタック メモリ領域 {a() s.f. addr} {arg addr} {a addr} {main() s.f. addr} {v addr}
69. . . . main() stack frame • 3行目で呼び出し 5 a() stack frame • 10行目で呼び出し • main()にreturn 5 7 スタック メモリ領域 {a() s.f. addr} {arg addr} {a addr} {main() s.f. addr} {v addr}
70. . . スタック メモリ領域 main() stack frame • 3行目で呼び出し 5 a() stack frame • 10行目で呼び出し • main()にreturn {b() s.f. addr} {a() s.f. addr} {arg addr} {a addr} {main() s.f. addr} {v addr} 5 7 b() stack frame
71. . . スタック メモリ領域 main() stack frame • 3行目で呼び出し 5 a() stack frame • 10行目で呼び出し • main()にreturn {b() s.f. addr} {a() s.f. addr} {arg addr} {a addr} {main() s.f. addr} {v addr} 5 7 b() stack frame • a()にreturn
72. . . スタック メモリ領域 main() stack frame • 3行目で呼び出し 5 a() stack frame • 10行目で呼び出し • main()にreturn {b() s.f. addr} {arg addr} {a() s.f. addr} {arg addr} {a addr} {main() s.f. addr} {v addr} 5 7 b() stack frame • a()にreturn 7
73. . . スタック メモリ領域 main() stack frame • 3行目で呼び出し 5 a() stack frame • 10行目で呼び出し • main()にreturn {b() s.f. addr} {arg addr} {b addr} {a() s.f. addr} {arg addr} {a addr} {main() s.f. addr} {v addr} 5 7 b() stack frame • a()にreturn 7 1
74. . . スタック メモリ領域 main() stack frame • 3行目で呼び出し 5 a() stack frame • 10行目で呼び出し • main()にreturn {b() s.f. addr} {arg addr} {b addr} {a() s.f. addr} {arg addr} {a addr} {main() s.f. addr} {v addr} 5 7 b() stack frame • a()にreturn 7 1
75. . . スタック メモリ領域 main() stack frame • 3行目で呼び出し 5 a() stack frame • 10行目で呼び出し • main()にreturn {b() s.f. addr} {arg addr} {b addr} {a() s.f. addr} {arg addr} {a addr} {main() s.f. addr} {v addr} 5 7 b() stack frame • a()にreturn 7 1 arg+b= 8 (CPUレジスタ)
76. . . スタック メモリ領域 main() stack frame • 3行目で呼び出し 5 a() stack frame • 10行目で呼び出し • main()にreturn {b() s.f. addr} {arg addr} {b addr} {a() s.f. addr} {arg addr} {a addr} {main() s.f. addr} {v addr} 5 7 b() stack frame • a()にreturn 7 1 8 (CPUレジスタ)
77. . . . スタック メモリ領域 main() stack frame • 3行目で呼び出し 5 a() stack frame • main()にreturn {a() s.f. addr} {arg addr} {a addr} {main() s.f. addr} {v addr} 5 7 8 (CPUレジスタ)
78. . . . スタック メモリ領域 main() stack frame • 3行目で呼び出し 5 a() stack frame • main()にreturn {a() s.f. addr} {arg addr} {a addr} {main() s.f. addr} {v addr} 5 7 8 (CPUレジスタ)
79. . . . スタック メモリ領域 main() stack frame 5 {main() s.f. addr} {v addr} 8 (CPUレジスタ)
80. . . . スタック メモリ領域 main() stack frame 8 {main() s.f. addr} {v addr} 8 (CPUレジスタ)
81. . . . スタック メモリ領域 main() stack frame 8 {main() s.f. addr} {v addr}
82. . . . スタック メモリ領域 プログラム終了
83. スタックは銀の弾丸ではない • ビルド時にサイズが不定の型 (map/slice) は扱えない ◦ スタック関連の処理はコンパイラの仕事 • 引数以外の方法で関数をまたいだ変数の共有ができない
84. 新しい戦略: 動的メモリ確保 (ヒープ メモリ領域) スタックの問題を解決するためのメモリ割り当て方法
85. {main() s.f. addr} ヒープ メモリ領域 . . . . . . . main() stack frame
86. ヒープ メモリ領域 . . . . . . . [] {slice_h addr} {main() s.f. addr} main() stack frame
87. ヒープ メモリ領域 . . . . . . . [] {slice_h addr} {main() s.f. addr} main() stack frame ランタイムに よって アドレスが決まる
88. ヒープ メモリ領域 . . . . . . . [] {slice_h addr} {main() s.f. addr} main() stack frame main()はsliceが どこかわからない (スタックフレームの中 しか見られない)
89. . . . . . . . [] {slice_h addr} {main() s.f. addr} {slice addr} main() stack frame ヒープ メモリ領域 {slice_h addr}
90. . . . . . . . [] {slice_h addr} {main() s.f. addr} {slice addr} main() stack frame ヒープ メモリ領域 これが ポインタ {slice_h addr}
91. . . . . . . . [] {slice_h addr} {main() s.f. addr} {slice addr} {num addr} main() stack frame ヒープ メモリ領域 5 これが ポインタ {slice_h addr}
92. ポインタは大事なので、もう少し詳しく見ていきます もう一つ例を挙げて ポインタがどのように 振る舞うか見てみよう
93. 値渡し と ポインタ渡し 違いを原理からきちんと説明できますか？
94. . . . main() stack frame • 3行目で呼び出し 5 値渡し {main() s.f. addr} {num addr}
95. . . . main() stack frame • 3行目で呼び出し 5 値渡し f() stack frame {f() s.f. addr} {main() s.f. addr} {num addr}
96. . . . main() stack frame • 3行目で呼び出し 5 値渡し f() stack frame 5 {f() s.f. addr} {num addr} {main() s.f. addr} {num addr}
97. {f() s.f. addr} {num addr} {main() s.f. addr} {num addr} . . . main() stack frame • 3行目で呼び出し 5 値渡し f() stack frame 10
98. {f() s.f. addr} {num addr} {main() s.f. addr} {num addr} . . . main() stack frame • 3行目で呼び出し 5 値渡し f() stack frame 10 main()関数の numには 影響しない
99. . . . ポインタ渡し main() stack frame • 3行目で呼び出し 5 {main() s.f. addr} {num addr}
100. . . . ポインタ渡し main() stack frame • 3行目で呼び出し 5 f() stack frame {f() s.f. addr} {main() s.f. addr} {num addr}
101. . . . main() stack frame • 3行目で呼び出し f() stack frame ポインタ渡し 5 {num addr} {f() s.f. addr} {num addr} {main() s.f. addr} {num addr}
102. . . . main() stack frame • 3行目で呼び出し f() stack frame ポインタ渡し {f() s.f. addr} {num addr} {main() s.f. addr} {num addr} 10 {num addr}
103. . . . {f() s.f. addr} {num addr} {main() s.f. addr} {num addr} main() stack frame • 3行目で呼び出し 10 f() stack frame ポインタ渡し {num addr} main()関数の numに 影響を及ぼす
104. スタックとヒープを 組み合わせることで 汎用的なメモリ管理が 実現できる
105. 古のヒープ管理 . . . . . . . {main() s.f. addr} main() stack frame C言語を例にとると • func malloc(int size) pointer • func free(pointer memory) (上記関数は疑似コード)
106. 古のヒープ管理 C言語を例にとると • func malloc(int size) pointer • func free(pointer memory) (上記関数は疑似コード) . . . . . . . ~~~ {ヒープのどこか} {main() s.f. addr} main() stack frame {ヒープのどこか}
107. 古のヒープ管理 . . . . . . . {main() s.f. addr} main() stack frame {ヒープのどこか} C言語を例にとると • func malloc(int size) pointer • func free(pointer memory) (上記関数は疑似コード)
108. 【つらみ】もしもfree()を忘れたら？ • メモリ使用量が無限に増えていく ◦ メモリリークと呼ばれている • 最終的にはOOM (Out of Memory) killで強制終了
109. ヒープの自動管理 / ガベージコレクション
110. ガベージコレクション (GC) • もう使われないヒープ内のデータを削除する ◦ スタックは一切関係ない戦略 • 基本的にランタイムの仕事
111. ヒープ領域 スタック領域 マーク & スイープ main() stack frame a() stack frame b() stack frame a b c e {a addr} d {b addr} {var1 addr} var1 {d addr}
112. ヒープ領域 スタック領域 マーク段階 main() stack frame a() stack frame b() stack frame a b c e {a addr} d {b addr} {var1 addr} var1 {d addr}
113. ヒープ領域 スタック領域 マーク段階 main() stack frame a() stack frame b() stack frame a b c e {a addr} d {b addr} {var1 addr} var1 {d addr}
114. ヒープ領域 スタック領域 マーク段階 main() stack frame a() stack frame b() stack frame a b c e {a addr} d {b addr} {var1 addr} var1 {d addr}
115. ヒープ領域 スタック領域 マーク段階 main() stack frame a() stack frame b() stack frame a b c e {a addr} d {b addr} {var1 addr} var1 {d addr}
116. ヒープ領域 スタック領域 マーク段階 main() stack frame a() stack frame b() stack frame a b c e {a addr} d {b addr} {var1 addr} var1 {d addr}
117. ヒープ領域 スタック領域 マーク段階 main() stack frame a() stack frame b() stack frame a b c e {a addr} d {b addr} {var1 addr} var1 {d addr}
118. ヒープ領域 スタック領域 マーク段階 main() stack frame a() stack frame b() stack frame a b c e {a addr} d {b addr} {var1 addr} var1 {d addr}
119. ヒープ領域 スタック領域 main() stack frame a() stack frame b() stack frame a b e {a addr} d {b addr} {var1 addr} var1 {d addr} スイープ段階 c
120. ヒープ領域 スタック領域 main() stack frame a() stack frame b() stack frame a b e {a addr} d {b addr} {var1 addr} var1 {d addr} スイープ段階
121. シンプルだが、最適化は結構難しい 例えばGo言語では、以下のような最適化が行われている • 我々が書いたコードと並列で動かす ◦ Tri-colorマーキングなどを使う • GCのトリガーの調整 ◦ GOGC ◦ GOMEMLIMIT • Go 1.25で実験的マークアルゴリズム Green Tea GCが導入
122. シンプルだが、最適化は結構難しい • 複雑なアルゴリズムを使った最適化は可能 • Goは↑をしていない ◦ シンプルの哲学が、仕様だけでなくランタイム実装 にも根付いている
123. 【つらみ】GCは重い • ヒープに多くのデータを置くと、GCが重くなる ◦ 特にマーク段階が重い
124. 多くのGC言語は型でヒープを決める • 昔のJava: オブジェクトは全てヒープ • Python: オブジェクトは全てヒープ • JS: non-primitive型の値は全てヒープ
125. 多くのGC言語は型でヒープを決める • 昔のJava: オブジェクトは全てヒープ • Python: オブジェクトは全てヒープ • JS: non-primitive型の値は全てヒープ Non-primitiveな型は ヒープに行きがち
126. ヒープエスケープ 【Go特有】
127. ヒープエスケープ • できる限り多くのデータをスタックに置く • 本当に必要なデータのみヒープに「逃げる」
128. どの変数がヒープに逃げるかわかる？
129. by Jacob Walker どの変数がヒープに逃げるかわかる？
130. 典型的なパターンは存在するけど… • 返り値がポインタの場合 • インターフェース型として扱われる場合 • map, channel, string, 大抵のslice
131. コンパイラとランタイムのみぞ知る • 多くのヒープエスケープはコンパイラが決める • 残りのヒープエスケープはランタイムが決める
132. エスケープ解析 • コンパイラは変数を解析してヒープに行くものを決める ◦ この解析ログを出力させることができる go {run/build/test} -gcflags="-m" **.go
133. ベンチマーク • ランタイム担当分まで含め、実際にヒープに割り当て られたかはベンチマークで確かめる go test -bench {package} -benchmem
134. 例 (エスケープあり)
135. 例 (エスケープあり)
136. 例 (エスケープあり)
137. 例 (エスケープなし)
138. 例 (エスケープなし)
139. 例 (エスケープなし)
140. 例 (エスケープなしに見えてもある場合)
141. 例 (エスケープなしに見えてもある場合)
142. 例 (エスケープなしに見えてもある場合)
143. ヒープ内でのオブジェクト管理 int (8 byte) • 色んなデータ (オブジェクト) がヒープに入る ◦ バラバラに入れていたら管理が面倒 struct (可変サイズ) ポインタ (8 byte)
144. … … ヒープ内でのオブジェクト管理 • 同サイズのオブジェクトをスパンでまとめる int (8 byte) struct (8 byte) struct struct (32 byte) struct struct int int スパン1 (8 byte用) スパン2 (8 byte用) スパン3 (32 byte用) int int
145. ヒープ内でのオブジェクト管理 • スパン (mspan) はもっと大きな単位でまとめられる ◦ mcentral ▪ 同じサイズのスパンをグループ化 ◦ arena ▪ mheapが1回で引き出してくるメモリ量 ▪ mcentralを複数格納 ◦ mheap ▪ ヒープ本体
146. ゼロアロケーション • ヒープ割り当て (エスケープ) が無いという意味 ◦ スタックにはデータを入れるので「文字通りゼロ」 ではない • パフォーマンス向上のためによく使われる
147. ゼロアロケーションライブラリ zerolog: ゼロアロケーションログ
148. ゼロアロケーションライブラリ fasthttp: (一部) ゼロアロケーションhttp server
149. ゼロアロケーションライブラリ go-reflect: ゼロアロケーションリフレクション
150. ゼロアロケーションも銀の弾丸ではない • ヒープを使わないので、関数をまたいだ データ共有は全て引数のコピー ◦ 引数のサイズが大きいと逆に重くなる • ゼロアロケーション = 正義 ではない ◦ ベンチマークで効果を計測しよう main() Var foo() Arg bar() Arg
151. ヒープエスケープを理解し ゼロアロケーションを 賢く使いましょう
152. スタックオーバーフロー • ヒープとスタックの境目を決めるのは言語 ◦ 例: Linux上のC言語ならスタックは8MB . . . . . ヒープ変数 main() stack frame
153. スタックオーバーフロー • 再帰関数などでスタックサイズの制限を超えてしまう
154. スタックオーバーフロー • 再帰関数などでスタックサイズの制限を超えてしまう → スタックオーバーフロー！！ • !!
155. 【つらみ】スタックが爆発する • ヒープエスケープはスタックの使用量を増やす ◦ スタックオーバーフローが起こりやすくなる
156. 【つらみ】ヒープも爆発する • スタック領域を大きくするといいのでは…？ • スタックが大きい = ヒープが小さい ◦ ✅ スタックオーバーフローは 起こりにくくなる ◦ ❌ OOM killの確率が上がる😭 • あちらを立てればこちらが立たず状態 . . . . . Heap var main() stack frame 󰷺
157. 可変サイズスタック 【Go特有】
158. Goのスタックは可変サイズ • Goはgoroutineごとに分離したスタックを持つ • それぞれのスタックが状況に合わせて伸び縮みする ◦ 4kBで初期化される
159. ざっくりしたイメージ main goroutine main() stack frame a() stack frame a2() stack frame a3() stack frame a4() stack frame m2() stack frame b() stack frame a goroutine b goroutine
160. 可変スタックの実装 • 昔はセグメント化スタックによって実装されていた • 今はスタックコピー (より効率が良い)
161. スタックコピー . . . main() stack frame m2() stack frame main goroutine のスタック
162. スタックコピー . . . main() stack frame m2() stack frame m3() stack frame m3()を実行する ためには サイズが足りない
163. スタックコピー . . . main() stack frame m2() stack frame 2倍のサイズ 新しい main goroutine のスタック
164. スタックコピー . . . main() stack frame m2() stack frame main() stack frame m2() stack frame
165. スタックコピー . . . main() stack frame m2() stack frame
166. スタックコピー . . . main() stack frame m2() stack frame m3() stack frame これでm3()が 実行できる
167. スタックコピー . . . main() stack frame m2() stack frame
168. スタックコピー . . . main() stack frame m2() stack frame
169. スタックが可変サイズなら スタックオーバーフローは 起きないのでは？
170. Goのスタックオーバーフロー 残念ながら実際は起こる
171. 最大スタックサイズ • 各goroutineはデフォルトで1GBまでしかスタックを 拡大できない ◦ 制限を超えるとスタックオーバーフローは起こる
172. 最大サイズの変更 • runtime/debug.SetMaxStack()で上書き可能
173. goroutineごとの 可変サイズスタックが Goのスタックの特殊さ goroutineが特殊だと言われる理由の一つでもある
174. 冒頭で紹介した事例の解説
175. 【おさらい】今回扱う事例 https://developers.cyberagent.co.jp/blog/archives/54653/ • たった一つのメモリ割り当ての変更だけで、CPU使用率 57%削減、メモリ使用量99%削減した例
176. 異常なスパイク - 大量のエスケープ • CPU使用率に定期的なスパイクが見られた • 寿命の短いヒープオブジェクトが大量に生成されていた ◦ GCが高頻度でトリガーされていた • ↑ を引き起こしていたのはフィルター関数
177. 改善前のフィルター関数
178. 改善前のフィルター関数
179. 改善前のフィルター関数
180. 改善前のフィルター関数 たった一つの 割り当てが大量の GCを引き起こしていた
181. 改善後のフィルター関数
182. 改善後のフィルター関数 スライスを 再利用
183. ベンチマーク • 両方の関数でベンチマークを回してみた ◦ 1から100までのリストを元の配列とする ◦ 偶数のみを抜き出すようフィルタリング
184. 2倍の速さ！ ベンチマーク • 両方の関数でベンチマークを回してみた ◦ 1から100までのリストを元の配列とする ◦ 偶数のみを抜き出すようフィルタリング
185. ベンチマーク • 両方の関数でベンチマークを回してみた ◦ 1から100までのリストを元の配列とする ◦ 偶数のみを抜き出すようフィルタリング たった一つの割り当て で引き起こされた ことがわかる 2倍の速さ！
186. 更なるリファクタリング (記事の内容) • イテレータを使うと、よりシンプルかつ安全に書ける
187. 改善結果 • ワークロード全体で ◦ CPU使用率57%削減!! ◦ メモリ使用量99%削減!!
188. まとめ
189. まとめ • メモリ管理はプログラマーの需要を満たすために発展 してきた • メモリ管理に関する知識は強い力となる • 今回のセッションはあくまで出発点 ◦ 他のセッションで各機能を深堀りしてみよう！
190. おまけ: 次のステップは？
191. ガベージコレクションの実装 GoのGCについて理解する @ Go Conference 2022 Spring
192. ガベージコレクションの条件とその活用 Go1.19から始めるGCのチューニング方法 @ Go Conference 2023 Online
193. エスケープ解析とその活用 Escape Analysis in Go: Understanding and Optimizing Memory Allocation @ Go Conference 2023 Online
194. Goのメモリ割り当てとOSの関係 Goのメモリ管理 @ Go Conference 2023 Online ⚠発展的
195. 並列処理におけるメモリ管理 よくわかるThe Go Memory Model - 行間を 図解で埋め尽くす @ Go Conference 2023 Online
196. ありがとう ございました カンファレンス、楽しみましょう！