Go言語を扱う上で、スライスは最も頻繁に利用されるデータ構造の一つです。
一見すると他の言語における可変長配列のように思えますが、その実態は「配列の特定の範囲を指し示す窓」のような構造をしています。
この内部構造を正しく理解していないと、予期せぬメモリ消費や意図しないデータの書き換えといったバグを引き起こす原因になりかねません。
本記事では、Go言語のスライスが内部でどのように配列を管理し、メモリ上でどのように振る舞っているのかを詳しく解説します。
配列とスライスの決定的な違い
Go言語のスライスを理解するためには、まずその基盤となる「配列」の特性を把握する必要があります。
Goにおける配列は、宣言時にその長さが固定され、後から変更することができません。
また、配列は「値型」であり、変数に代入したり関数に渡したりする際には、要素の全コピーが発生します。
一方でスライスは、内部に配列への参照を持つ「参照型」のような振る舞いをする構造体です。
スライスそのものは非常に軽量なデータ構造であり、関数への受け渡しでも大きなオーバーヘッドは発生しません。
配列の挙動を確認する
まずは配列がどのようにコピーされるか、以下のコードで確認してみましょう。
package main
import "fmt"
func main() {
// 長さ3の整数型配列を定義
arr1 := [3]int{10, 20, 30}
// arr1をarr2に代入(値のコピーが発生)
arr2 := arr1
arr2[0] = 100
fmt.Println("arr1:", arr1)
fmt.Println("arr2:", arr2)
}arr1: [10 20 30]
arr2: [100 20 30]この結果からわかる通り、arr2を変更しても元のarr1には影響を与えません。
これは配列がメモリ上の独立した領域としてコピーされているためです。
スライスの内部構造：スライスヘッダー
スライスの実態は、「スライスヘッダー」と呼ばれる3つのフィールドを持つ構造体です。
ランタイムパッケージの定義に基づくと、スライスは以下の要素で構成されています。
- Data (ポインタ): 背後にある配列(バッキング配列)の特定の要素へのメモリアドレス。
- Len (長さ): スライスが現在保持している要素の数。
- Cap (容量): スライスの開始位置から、バッキング配列の末尾までの要素数。
この構造により、スライスは配列の一部を効率的に切り出し、共有することを可能にしています。
スライスのメモリイメージ
スライスを作成すると、Goのランタイムはメモリ上に「バッキング配列」を確保し、スライスヘッダーを生成します。
s := make([]int, 3, 5) というコードを実行した場合、長さ3、容量5のスライスが作成されます。
このとき、メモリ上には5要素分の配列が確保されますが、スライスからアクセスできるのは最初の3要素のみとなります。
バッキング配列と共有の仕組み
スライスが強力である最大の理由は、複数の中間スライスが同一のバッキング配列を共有できる点にあります。
以下のプログラムで、スライスの切り出しがどのようにメモリを共有するかを見てみましょう。
package main
import "fmt"
func main() {
// 元のスライス
original := []int{1, 2, 3, 4, 5}
// 部分スライスを作成
sub := original[1:4]
fmt.Printf("original: %v, addr: %p\n", original, &original[1])
fmt.Printf("sub : %v, addr: %p\n", sub, &sub[0])
// subの要素を書き換える
sub[0] = 99
fmt.Println("書き換え後 original:", original)
}original: [1 2 3 4 5], addr: 0xc000016158
sub : [2 3 4], addr: 0xc000016158
書き換え後 original: [1 99 3 4 5]sub[0]のアドレスとoriginal[1]のアドレスが一致していることに注目してください。
スライスを切り出した際、新しいバッキング配列は作成されず、既存の配列の一部を指す新しいヘッダーが作られただけなのです。
そのため、subの内容を変更すると、その変更は直ちにoriginalにも反映されます。
append関数と容量の拡張
スライスの「可変長」という性質を支えているのが append 関数です。
append は、現在のスライスの容量 cap に余裕がある場合、バッキング配列の次の空き領域に値を書き込み、長さを更新した新しいスライスヘッダーを返します。
しかし、容量が不足している場合には、より大きな新しい配列をメモリ上に確保し、既存の要素をすべてコピーするという処理が行われます。
再割り当てによる挙動の変化
容量が足りなくなった時の挙動を確認してみましょう。
package main
import "fmt"
func main() {
s := make([]int, 2, 2)
fmt.Printf("初期状態: len=%d cap=%d ptr=%p\n", len(s), cap(s), s)
s = append(s, 3)
fmt.Printf("追加後 : len=%d cap=%d ptr=%p\n", len(s), cap(s), s)
}初期状態: len=2 cap=2 ptr=0xc0000120a0
追加後 : len=3 cap=4 ptr=0xc0000140a0ポインタのアドレスが 0xc0000120a0 から 0xc0000140a0 へと変化しているのが分かります。
これは append によって新しいバッキング配列が確保された証拠です。
このとき、新しい容量は一般的に元の2倍（Goのバージョンやサイズによりアルゴリズムは異なります）になります。
パフォーマンスを最適化するためのベストプラクティス
スライスの内部構造を理解すると、どのようにコードを書けば効率的かが分かります。
まず、あらかじめ必要な要素数が分かっている場合は、makeで容量を指定することが重要です。
ループ内で append を繰り返すと、頻繁に配列の再割り当てとメモリコピーが発生し、パフォーマンスが著しく低下します。
makeによる事前割り当ての例
// 悪い例：ループのたびに再割り当てが発生する可能性がある
var s []int
for i := 0; i < 1000; i++ {
s = append(s, i)
}
// 良い例：最初に容量を確保するため、再割り当てが発生しない
s := make([]int, 0, 1000)
for i := 0; i < 1000; i++ {
s = append(s, i)
}このように容量 cap を明示することで、メモリ割り当ての回数を最小限に抑えることができます。
メモリリークに注意：巨大な配列の部分参照
スライスを使用する際の落とし穴の一つに、メモリリークのような現象があります。
巨大なバッキング配列を持つスライスから、ほんの数要素だけを切り出した小さなスライスを作成した場合を考えます。
この小さなスライスがメモリ上に残っている限り、背後にある巨大なバッキング配列全体がガベージコレクション(GC)の対象から外れてしまいます。
もし巨大なデータの一部しか必要ないのであれば、copy 関数を使って新しい小さなスライスに値をコピーすることをお勧めします。
copy関数を利用したメモリ節約
func getSmallSegment() []int {
// 巨大なデータを読み込む
largeData := make([]int, 1000000)
// 必要なのは最初の3つだけ
// result := largeData[:3] // これだと100万要素がメモリに残る
result := make([]int, 3)
copy(result, largeData[:3]) // 値だけをコピー
return result // largeDataはGCによって解放される
}このように、copy を利用してバッキング配列の参照を切り離すことは、長期運用されるアプリケーションのメモリ管理において非常に重要です。
まとめ
Go言語のスライスは、単なる可変長配列ではなく、バッキング配列への参照を持つ高度に抽象化された構造体です。
スライスヘッダーに含まれる「ポインタ」「長さ」「容量」という3つの要素を意識することで、データの共有や拡張の仕組みが明確になります。
特に append による再割り当てのコストや、部分的な切り出しによるメモリの保持には注意が必要です。
これらの特性を正しく理解し、make による事前割り当てや copy による独立したスライスの作成を使い分けることで、より堅牢で効率的なGoプログラムを記述できるようになります。
スライスの背後にある仕組みを意識し、メモリを最適に活用した開発を目指しましょう。