【入門編】GoランタイムのGC（ガベージコレクション）をハックする：GOGC設定と実行制御の深層 – 実行環境・ランタイム・コンパイラ生産性向上バイブル

GoランタイムのGCをハックする：GOGC設定と実行制御の深層

こんにちは！日々の開発やインフラ運用、お疲れ様です。

Go言語（Golang）は、高速な実行性能とシンプルな文法を両立した素晴らしい言語ですよね。多くのバックエンドAPIやKubernetesをはじめとするクラウドネイティブな基盤ツールがGoで書かれています。

Goを使い始めたばかりのころは「goroutineで簡単に並行処理ができて速い！」と感動するものですが、プロダクション環境（特にKubernetesなどのコンテナ環境）にデプロイした途端、「なぜか意図しないタイミングでOOM（Out of Memory）キルされてPodが再起動を繰り返す」「スパイクアクセス時にレイテンシが急激に跳ね上がる」といった壁にぶつかることがあります。

その原因の多くは、GoランタイムのGC（ガベージコレクション）の特性を把握しきれていないことにあります。

この記事を最後まで読み、GCの制御方法をマスターすれば、限られたリソース内でアプリケーションのパフォーマンスを最大限に引き出し、OOMに怯えることのない堅牢なシステムを構築できるようになりますよ。一緒にGoの深層へ潜ってみましょう！

—

1. Goのガベージコレクション（GC）の仕組みを覗いてみよう

GoのGCは、開発者がメモリ管理（malloc/freeのような作業）を意識しなくても安全にプログラムを動かせるように自動でメモリを回収してくれます。まずは、その内部で何が起きているのかを直感的に理解しておきましょう。

非世代別・並行三色マーク＆スイープ（Concurrent Tricolor Mark & Sweep）

多くのプログラミング言語（JavaやV8 JavaScriptエンジンなど）は「世代別GC（若いオブジェクトと長寿命のオブジェクトを分ける方式）」を採用していますが、Goは「非世代別の並行三色マーク＆スイープ」というアルゴリズムを採用しています。

オブジェクトを以下の3色に塗り分けながら探索します：

1. 白（White）: まだ探索されていない、または回収対象（ゴミ）の候補。
2. 灰（Gray）: 自身は生きていることが確認されたが、参照先のオブジェクトがまだ探索されていない状態。
3. 黒（Black）: 自身も生きており、参照先のオブジェクトもすべて探索済み。

[ ルート (スタック/グローバル変数) ]
│
▼
( 灰色ノード ) ─── 探索中 ───▶ ( 白色ノード )
│
▼
( 黒色ノード ) ─── 探索完了（解放されない）

[ 孤立した白色ノード ] ───▶ GC終了時にメモリ解放！

なぜGoのGCは「Stop The World (STW)」が極小なのか？

GoのGCの最大の特徴は、アプリケーションの停止時間（Stop The World: STW）が極めて短い（1ミリ秒未満）という点です。

プログラムの実行（ミューテータ）をほぼ止めずに、バックグラウンドのゴルーチンが並行してマーキングを行います。その代わり、「並行して動くためにCPUリソースを一定割合（デフォルトで約25%）消費する」というトレードオフを持っています。

—

2. メモリとGCの司令塔：`GOGC` パラメータの正体

Goランタイムが「いつGCを発火させるか」を決める最も基本的なパラメータが、環境変数 `GOGC` です。

GOGCの計算式

`GOGC` のデフォルト値は `100` です。この数字は「前回のGC完了時に残った生きたヒープサイズに対して、何％ヒープが増えたら次のGCを実行するか」を表しています。

$$NextGC = TargetHeap = LiveHeap \times (1 + \frac{GOGC}{100})$$

前回GC直後の生きたヒープ (`LiveHeap`): 100 MB
GOGC: 100（デフォルト）
次回GCがトリガーされるヒープサイズ (`TargetHeap`): $100\text{MB} \times (1 + 1.00) = 200\text{MB}$

つまり、常に生存メモリと同量のバッファを許容する設定になっているわけです。

LiveHeap (100MB) ──────▶ 次回GCトリガー (200MB)
[■■■ 生存メモリ ■■■] ─── [□□□ 割り当て猶予 (100%) □□□]

GOGCを調整するトレードオフ

—

3. Go 1.19で世界が変わった：`GOMEMLIMIT` との組み合わせ

以前のGoでは、`GOGC` だけでは「メモリの上限値（例：コンテナ制限の512MB）」を直接指定できませんでした。そのため、突発的なメモリアロケーションがあると `GOGC=100` の計算が追いつかず、コンテナ上限を突破してOOMキルされる悲劇が多発していました。

そこで Go 1.19 で導入された救世主が `GOMEMLIMIT`（ソフトメモリリミット）です。

512MiBのメモリ制限のコンテナで動かす場合のベストプラクティス
メモリ全体の約80〜90%をランタイムに教える
export GOMEMLIMIT=450MiB
export GOGC=100

`GOMEMLIMIT` を設定すると、ランタイムはターゲット上限に近づくにつれて自動的にGC頻度を高め、制限値を超えないよう粘り強くメモリを回収します。

—

4. ハンズオン：GC挙動を可視化＆制御するコードを動かしてみよう

理論が分かったところで、実際に手を動かしてGCの挙動を体感してみましょう！
GCのログを詳細に出力させ、ランタイムパッケージを使って手動制御を試すミニマムなGoプログラムを作成します。

Step 1: プロジェクトのセットアップ

作業ディレクトリを作成し、Goモジュールを初期化します。

作業ディレクトリ作成
mkdir go-gc-hack
cd go-gc-hack

モジュールの初期化
go mod init go-gc-hack

Step 2: GC制御と観測のコードを作成

以下のコードを `main.go` として作成してください。

package main

import (
“fmt”
“os”
“runtime”
“runtime/debug”
“time”
)

// 指定したサイズ(MB)のダミーデータをヒープに確保する関数
func allocateMemory(mb int) [][]byte {
// スライスのスライスを作成してヒープに保持し続ける
data := make([][]byte, mb)
for i := 0; i < mb; i++ { // 1MBのバイト配列を確保 data[i] = make([]byte, 10241024) // 実際に書き込みを行って実メモリを割り当てさせる data[i][0] = 1 } return data } // 現在のヒープアロケーション状況を出力するヘルパー関数 func printMemStats(label string) { var m runtime.MemStats runtime.ReadMemStats(&m) fmt.Printf("[%s]\n", label) fmt.Printf(" Alloc (現在のヒープ使用量) : %v MiB\n", m.Alloc/1024/1024) fmt.Printf(" TotalAlloc (累積割り当て量) : %v MiB\n", m.TotalAlloc/1024/1024) fmt.Printf(" Sys (OSから取得したメモリ) : %v MiB\n", m.Sys/1024/1024) fmt.Printf(" NumGC (GC実行回数) : %v 回\n\n", m.NumGC) } func main() { fmt.Println("=== Goランタイム GC制御ハックデモ ===") printMemStats("開始直後") // 1. 意図的に50MBのメモリを確保 fmt.Println(">> 50MB のメモリを割り当てます…”)
holder := allocateMemory(50)
printMemStats(“50MB 割り当て後”)

// 2. メモリの参照を解除して「ゴミ（Garbage）」にする
fmt.Println(“>> 参照を破棄してメモリを解放可能にします…”)
holder = nil
_ = holder

// 3. runtime/debug を利用したチューニングの動的変更
// プログラムの実行中に動的にGOGCの値を変更できます
oldGOGC := debug.SetGCPercent(50) // GOGCを一時的に50%に引き締める
fmt.Printf(“>> GOGCを変更しました: 前=%d -> 今=50\n”, oldGOGC)

// 4. 明示的なGCの強制実行
fmt.Println(“>> runtime.GC() を手動実行して強制回収します…”)
runtime.GC()