Goにおけるガーベジコレクション（GC）は自動的なメモリ管理メカニズムであり、言語の初期バージョンで最初に登場しました。歴史的に、GoのGCはパフォーマンスに与える影響により批判の対象となることがありました。しかし、特にGo 1.5以降、言語の進化に伴い、大幅に改善されました：現在では、最小限のポーズ（低遅延GC）で動作する三重の競合（concurrent, tricolor, mark-and-sweep）ガーベジコレクタが使用されています。
問題は、プログラムが大量の一時オブジェクトを生成したり、未使用の構造体への参照を削除しなかったりする場合に発生します。これによりGCの負荷が増加し、大きなポーズにつながることがあります。特にオブジェクトの種類、循環参照、およびスタック外にある長い参照のチェーンに注意を払う必要があります。
解決策は、メモリの割り当てを監視し、プロファイリングを使用し、「GOGC」環境変数を通じてGCを調整し、内部ループやクリティカルセクションでの割り当てを最小限に抑えることです。Goのガーベジコレクションはヒープに対してのみ機能することを覚えておくことが重要です：スタック上で割り当てられたものは、スコープを出ると自動的に削除されますが、ヒープに「移行」したオブジェクトはGCによって管理されます。
コード例：
// メモリアロケーションのプロファイリングとGCの最適化 import ( "runtime" "fmt" ) func main() { var memStats runtime.MemStats runtime.ReadMemStats(&memStats) fmt.Printf("アロケーション前: %d bytes\n", memStats.Alloc) s := make([]int, 1_000_000) for i := range s { s[i] = i } runtime.GC() // 手動クリーンアップ runtime.ReadMemStats(&memStats) fmt.Printf("GC後: %d bytes\n", memStats.Alloc) }
主な特徴：
どのオブジェクトがヒープに「移動」し、どのオブジェクトがスタックに残るのかを調べるには？
回答：これにはエスケープ解析が使用され、コンパイラフラグ「go build -gcflags="-m"」を使用して分析できます。関数の外に戻されるオブジェクトやクロージャーで使用されるオブジェクトは、ヒープに移動することが多いです。
コード例：
func escape() *int { v := 42 return &v // vはヒープに移動します }
GCは全ての変数、スタック上のものを含むすべての変数に影響を与えるか？
いいえ、GCはヒープ（ヒープに割り当てられたオブジェクト）のみで機能します。スタック上で割り当てられたものは、関数の終了時に自動的にクリアされます。
手動でruntime.GC()を呼び出すことでパフォーマンスが大幅に向上するか？
逆に、手動呼び出しはしばしばパフォーマンスを低下させ、CPUの消費を増加させます。テストやデバッグされたケースでのみ使用するべきです。
ネガティブケース
開発者が各リクエストで新しい大きなスライスを生成するサービスを書いており、それらのライフサイクルについて考慮していません。これによりGCへの負荷が急増し、ポーズが急増し、パフォーマンスが低下します。
長所：
短所：
ポジティブケース
開発者がサービスを最適化し、アロケーションをプロファイリングし、sync.Poolを介してバッファを再利用し、GCの呼び出し頻度を下げ、ホットスポットでのメモリ割り当てを最小限に抑えます。
長所：
短所：