DocsPricingBlog
Contact Us
Log inSign up for FREE
Back to Tech Articles

Goのメモリ管理の理解

Sep 03, 2025
# Go

Daniel Hayes

Full-Stack Engineer · Leapcell

This post is also available in English, 한국어, and Deutsch
Cover of "Goのメモリ管理の理解"

モダンアプリケーションのためのGoの効率的なメモリ管理

現代のソフトウェア開発においては、効率的なリソース管理が最優先事項です。C言語やC++のような言語はメモリに対してきめ細かな制御を提供しますが、開発者に重い負担をかけ、メモリリークやuse-after-freeエラーといった一般的な落とし穴につながることがよくあります。逆に、JavaやPythonのような自動メモリ管理を備えた言語は開発を簡素化しますが、ガベージコレクションによる予期しない一時停止が発生し、アプリケーションの応答性に影響を与えることがあります。高性能で並行性の高いシステムを構築するために設計されたGoは、驚くべきバランスを実現しています。洗練されたガベージコレクタによる自動メモリ管理を提供しつつ、低レベル言語に匹敵する予測可能なパフォーマンス特性を維持しています。Goのメモリ割り当てとガベージコレクション（GC）のメカニズムを理解することは、効率的で信頼性が高く、高性能なGoアプリケーションを書く上で不可欠です。この記事では、Goが内部でどのようにメモリを管理しているかを、そのコア原則と実践的な影響を探りながら解き明かしていきます。

GoのメモリとGCの内部動作

Goのメモリ管理を完全に理解するには、まずいくつかの基本概念とその全体的なアーキテクチャを把握することが不可欠です。

主要概念：ヒープ対スタックとポインタ

Goでは、多くの他の言語と同様に、メモリは主にスタックとヒープの2つの主要領域に分けられます。

  • スタック: スタックは、ローカル変数、関数引数、およびリターンアドレスを格納するために使用されます。LIFO（Last-In, First-Out）の原則で動作します。スタック上の割り当てと解放は、単にポインタを移動するだけなので非常に高速です。スタックに割り当てられたメモリは、関数が終了すると自動的に解放されます。
  • ヒープ: ヒープは、動的メモリ割り当て、つまりコンパイル時にサイズが不明なメモリや、単一の関数呼び出しのスコープを超えて存続するメモリに対して使用されます。スライス、マップ、チャネル、ユーザー定義構造体のインスタンス（ヒープにエスケープする場合）などのデータ構造は、通常ヒープに割り当てられます。ヒープ上の割り当ては、一般的にスタック上の割り当てよりも遅く、ヒープに割り当てられたメモリはガベージコレクションが必要です。

Goは、メモリ内の値を参照するためにポインタを使用します。ポインタは変数のメモリアドレスを保持します。Goは明示的なポインタの使用を許可しますが、その設計はよりイディオマティックなアプローチを奨励しており、コンパイラはしばしばポインタの間接参照を暗黙的に処理します（例：スライスやマップを渡す場合）。変数がスタックに割り当てられるかヒープに割り当てられるかの決定は、Goコンパイラによってエスケープ解析と呼ばれる最適化を通じて行われます。変数の生存期間が宣言された関数のスコープを超えて延長される場合、またはグローバルにアクセス可能な変数や他のゴルーチンによって逆参照される可能性のあるポインタによって参照される場合、それはヒープに「エスケープ」します。

簡単な例でエスケープ解析を説明しましょう。

package main

type Person struct {
	Name string
	Age  int
}

func createPersonOnStack() Person {
	// Pは、その有効期間がこの関数に限定されており、値型で返される（コピーされる）ため、
	// スタック上に割り当てられる可能性が高いです。
	p := Person{Name: "Alice", Age: 30}
	return p
}

func createPersonOnHeap() *Person {
	// Pは、そのアドレスが返されるため、この関数のスコープを超えて有効期間が延長されるため、
	// ヒープ上に割り当てられる可能性が高いです。
	p := &Person{Name: "Bob", Age: 25}
	return p
}

func main() {
	_ = createPersonOnStack()
	_ = createPersonOnHeap()
}

エスケープ解析の出力を見るには、go build -gcflags='-m' を使用できます。

$ go build -gcflags='-m' ./your_package_path/main.go
# github.com/your_user/your_repo
./main.go:13:9: &Person{...} escapes to heap
./main.go:8:9: moved to heap: p (return value)

createPersonOnStack の出力は直感に反するように見えるかもしれません。多くの場合、そのような小さな構造体では、コンパイラが最適化して p をスタックに移動させる可能性がありますが、戻り値がすぐに「使用」されない場合や構造体が大きくなる場合、コンパイラはコストのかかるコピーを避けるためにそれをヒープに昇格させることを決定する可能性があります。しかし、createPersonOnHeap は &Person{...} がヒープにエスケープすることを明確に示しており、これはポインタで返される値に関する重要なポイントです。

Goの並行三色マーク・アンド・スイープGC

Goのガベージコレクタは、並行、三色、マーク・アンド・スイープコレクタです。これが何を意味するのかを分解してみましょう。

  1. 並行 (Concurrent): GCはアプリケーションのゴルーチンと並行して実行されます。これは、アプリケーションがガベージコレクションのために完全に停止する期間である「ストップ・ザ・ワールド」（STW）の一時停止を最小限に抑えるための重要な設計上の選択です。GoのGCは、レイテンシが非常に低いことを目指しており、一時停止時間はマイクロ秒の範囲で達成されることがよくあります。

  2. 三色 (Tri-Color): これは、マーキングフェーズ中にオブジェクトを追跡するために多くの最新のトレースガベージコレクタによって使用される概念的なモデルです。

    • 白 (White): GCによってまだ訪問されていないオブジェクト。GCサイクルの開始時には、すべてのオブジェクトは白です。マーキングフェーズの終わりにオブジェクトが白のままである場合、それは到達不能と見なされ、収集の対象となります。
    • 灰 (Gray): 訪問されたが、その子（参照しているオブジェクト）はまだスキャンされていないオブジェクト。これらのオブジェクトはワークキューに入れられます。
    • 黒 (Black): 訪問され、そのすべての子も訪問されマークされている（またはすでに黒/灰である）オブジェクト。これらのオブジェクトは「ライブ」と見なされます。

    GCは、一連の「ルート」オブジェクト（例：グローバル変数、アクティブなゴルーチンのスタック変数）から開始して機能します。これらのルートは最初に灰にマークされます。次にGCは灰色のオブジェクトを選択し、それを黒にマークし、それが参照するすべてのオブジェクトをスキャンして、それらが現在白い場合は灰色にマークします。このプロセスは、灰色のオブジェクトがなくなるまで続きます。

  3. マーク・アンド・スイープ (Mark-and-Sweep): これはGCサイクルの2つの主要フェーズを説明しています。

    • マークフェーズ (Mark Phase): GCはルートから開始して、到達可能な（ライブな）すべてのオブジェクトを識別します。このフェーズでは、オブジェクトグラフをトラバースし、オブジェクトを黒にマークします。ミューテータ（Goプログラム）が実行されている間、一貫性を確保するライトバリアが存在します。プログラムがポインタを変更した場合（例：オブジェクトを新しいオブジェクトにポインタさせる）、ライトバリアは、新しいオブジェクトが白である場合、誤って収集されるのを防ぐためにすぐに灰に着色されることを保証します。
    • スイープフェーズ (Sweep Phase): マークフェーズが完了した後、GCはヒープを反復処理し、マークされていない（白い）オブジェクトが占有しているメモリを回収します。これもアプリケーションと並行して実行されます。回収されたメモリは、中央プール（mheap）に返され、その後、Pごとの（プロセッサ）キャッシュに渡されて、迅速な割り当てが行われます。

GCサイクルの詳細

典型的なGo GCサイクルは、いくつかのステージで構成されます。

  1. GCトリガー: GCは、最後のGCサイクル以降に割り当てられた新しいメモリの量が特定のしきい値に達すると自動的にトリガーされます。このしきい値は、GOGC環境変数（デフォルト：100）によって制御され、次のGCサイクルが発生する前のライブヒープサイズの増加率を表します。たとえば、GOGC=100 の場合、GCは最後のGCサイクルの終了後、ライブヒープが2倍のサイズになったときに実行されます。通常運用では推奨されませんが、runtime.GC() を使用して明示的にトリガーすることもできます。
  2. マークアシスト (プログラム実行中の並行処理): アプリケーションのGoroutineがメモリを割り当てようとしたときに、GCが現在アクティブであり、Goroutineの割り当てレートが非常に高い場合、マーキング作業の一部を行うように「アシスト」するように依頼されることがあります。これは、GCが割り当てレートに追いつき、ヒープが大きくなりすぎるのを防ぐのに役立ちます。
  3. マーキング (マイナーSTW一時停止との並行処理):
    • ワールドの開始 (STW-1): ライトバリアを有効にし、ルートをスキャン準備するために非常に短い一時停止（マイクロ秒）が発生します。この一時停止は、マーキング開始時のヒープスナップショットの一貫性を確保するために重要です。
    • 並行スキャン: GCゴルーチンはオブジェクトグラフのトラバースを開始し、到達可能なオブジェクトをマークします。アプリケーションのゴルーチンはこのフェーズ中に実行され続けます。ライトバリアは、プログラムがGCのマーキング中にポインタを変更する競合状態から保護します。
    • ワールドの終了 (STW-2): 並行マーキングフェーズ中に変更されたスタックとグローバルをスキャンし、マーキングを完了するために、さらに短い一時停止（マイクロ秒）が発生します。
  4. スイープ (並行処理): マーキングが完了すると、スイープフェーズが開始されます。GCはヒープを反復処理し、マークされていないメモリブロックを識別して回収します。これもアプリケーションと並行して実行されます。回収されたメモリは、中央プール（mheap）に返され、その後、Pごとのキャッシュに渡されて、迅速な割り当てが行われます。

Goのメモリ割り当て：MallocsとSpans

Goのメモリ割り当て器（runtime/malloc.go）は、Goroutineのパフォーマンスと並行性に高度に最適化されています。ヒープをスパンと呼ばれる固定サイズのチャンクに分割して機能します。スパンは通常8KBアラインされた連続したメモリ領域です。

Goプログラムがメモリを割り当てる必要がある場合：

  1. サイズクラス (Size Classes): Goの割り当て器は、割り当てをサイズクラスのシリーズにグループ化します。小さなオブジェクト（最大32KB）の場合、約67のサイズクラスがあります。各サイズクラスは特定のブロックサイズ（例：8バイト、16バイト、24バイトなど）にマッピングされます。
  2. Pごとのキャッシュ (mcache): 各論理プロセッサ（P）には、各サイズクラスの空きメモリブロックのローカルキャッシュ（mcache）があります。この設計により、小さなオブジェクトを割り当てる際にロックの必要がなくなり、割り当てが非常に高速になります。特定のP上のGoroutineが必要なサイズのブロックを必要とする場合、まずmcacheから空きブロックを取得しようとします。
  3. スパン割り当て (mcentral): mcacheに空きブロックがない場合、中央プール（mcentral）から新しいスパンを要求します。mcentralにはスパンのリストがあり、空きオブジェクトを持つスパン（部分的に満たされたスパン）と完全に空のスパンがあります。mcacheがスパンを要求すると、mcentralから1つ取得し、それを要求されたサイズクラスのブロックに分割し、1つのブロックをGoroutineに返して残りをmcacheに保持します。mcentralへのアクセスはロックで保護されています。
  4. ヒープアリーナ (mheap): mcentralに適切なスパンがない場合、mheapから新しいメモリを要求します。mheapはヒープ全体を管理し、オペレーティングシステムから（mmapまたはsbrkを使用して）大きなメモリチャンクを取得し、それらをスパンに分割します。大きな割り当て（32KBより大きい）は、1つ以上の連続したスパンを割り当てることによって、直接mheapによって処理されます。

Pごとのキャッシュと中央のmheapを備えたこの階層的な割り当てシステムは、競合を大幅に減らし、特に高並行性のアプリケーションでの割り当てパフォーマンスを向上させます。

実践的な意味とパフォーマンスチューニング

Goのメモリモデルを理解することは、パフォーマンスの診断と最適化に役立ちます。

  1. ヒープ割り当ての最小化: GoのGCは優れていますが、オブジェクトの割り当てと解放には依然としてオーバーヘッドがあります。不要なヒープ割り当て（より多くの変数をスタックにエスケープさせることによって）を減らすことは、GCの負荷を軽減し、パフォーマンスを向上させる最も効果的な方法の1つです。go tool pprofやgo build -gcflags='-m'のようなツールは、ヒープ割り当てを特定する上で非常に役立ちます。
  2. GOGCの理解: GOGC環境変数は、GCトリガーのしきい値を制御します。GOGCの値を小さくすると、より頻繁だが短いGCサイクルになります（メモリ使用量を減らせますが、GCによるCPUオーバーヘッドが増加する可能性があります）。GOGCの値を大きくすると、より頻繁ではないが、潜在的に長いGCサイクルになります（メモリ使用量が増加する可能性がありますが、CPUオーバーヘッドが減少する可能性があります）。デフォルトのGOGC=100は多くの場合良い出発点ですが、特定のワークロード特性に合わせて調整する必要があるかもしれません。
  3. 大規模オブジェクトへの長期間のポインタの回避: 非常に大きなデータ構造（例：巨大なスライスやマップ）があり、それに単一のポインタを保持し続ける場合、そのポインタがなくなるまでGCはそのメモリを回収できません。構造体内のほとんどのデータが未使用になっても、構造体全体は有効なままです。これが問題になる場合は、データ構造の再設計を検討してください。
  4. 再利用可能なバッファ/オブジェクトプール: 頻繁にオブジェクトを割り当てたり解放したりする非常に高スループットのシステムでは、sync.Poolの使用やカスタムオブジェクトプールの実装は、新しいオブジェクトを割り当てるのではなくオブジェクトを再利用することで、GCの負荷を効果的に減らすことができます。
package main

import (
	"fmt"
	"runtime"
	"sync"
)

type MyObject struct {
	Data [1024]byte // 比較的大きなオブジェクト
}

var objectPool = sync.Pool{
	New: func() interface{} {
		// プールにオブジェクトがない場合に新しいオブジェクトが必要になったときに呼び出される関数です。
		return &MyObject{}
	},
}

func allocateDirectly() {
	_ = &MyObject{} // ヒープに割り当て
}

func allocateFromPool() {
	obj := objectPool.Get().(*MyObject) // プールからオブジェクトを取得
	// objで何かを行う
	objectPool.Put(obj) // オブジェクトをプールに戻す
}

func main() {
	// 割り当ての前後にメモリを観察してみましょう
	var m runtime.MemStats
	runtime.ReadMemStats(&m)
	fmt.Printf("Initial Alloc = %v Bytes\n", m.Alloc)	

	// 直接割り当てをシミュレート
	for i := 0; i < 10000; i++ {
		allocateDirectly()
	}
	runtime.GC() // 回収されたメモリを確認するためにGCを強制
	runtime.ReadMemStats(&m)
	fmt.Printf("After Direct Allocations & GC: Alloc = %v Bytes\n", m.Alloc)

	// プールからの割り当てをシミュレート
	// 統計を大まかにリセット（GCが以前の直接割り当ての一部をクリーンアップする可能性があります）
	runtime.GC() 
	runtime.ReadMemStats(&m)
	fmt.Printf("Before Pool Allocations: Alloc = %v Bytes\n", m.Alloc)
	for i := 0; i < 10000; i++ {
		allocateFromPool()
	}
	runtime.GC() // GCを強制
	runtime.ReadMemStats(&m)
	fmt.Printf("After Pool Allocations & GC: Alloc = %v Bytes\n", m.Alloc)

	// プールを使用した場合、オブジェクトが再利用されるため、`Alloc`メトリック（Goによって使用中の総割り当てメモリ）は、
	// 直接割り当てと比較して大幅に少なくなるか、安定したままになるのが観察されるでしょう。
}

この例を実行すると、sync.Poolを使用して同じ数の「割り当て」を行った後、Allocメトリック（Goによって使用中の総割り当てメモリ）が、直接割り当てを行った場合よりも大幅に低くなるか、安定したままになることがわかるでしょう。これは、プーリングが実際のヒープフットプリントとGCの圧力をどのように削減するかを示しています。

結論

Goのメモリ割り当てとガベージコレクションのメカニズムは、そのパフォーマンスと並行性の話の基盤です。効率的で並行性の高い三色マーク・アンド・スイープコレクタと高度に最適化された階層型メモリ割り当て器を活用することにより、Goは開発者が手動メモリ管理の複雑さを伴わずに、予測可能な低レイテンシパフォーマンスを持つアプリケーションを構築できるようにしています。Goはほとんどのメモリの懸念を自動的に処理しますが、その基盤となる原理 — スタック対ヒープ割り当て、エスケープ解析、GCサイクルのニュアンス — を理解することは、真に最適化され堅牢なGoプログラムを作成するために非常に価値があります。最終的に、Goのメモリ管理システムにより、開発者はメモリの些細なことよりもビジネスロジックにより多くの時間を費やすことができ、開発者の生産性と高いアプリケーション効率の両方を達成できます。

Share this article

HackerNews

More Posts from Leapcell

Popular Posts