導入：なぜ「渡し方」が重要なのか
Goで開発をしていると、関数に引数を渡す際に「値で渡すべきか、ポインタで渡すべきか」迷う場面があるでしょう。この選択は、単なるコーディング規約の問題ではなく、プログラムの実行速度とメモリ管理（GC負荷）に直結します。不適切な選択は、不要なメモリコピーによるオーバーヘッドや、本来スタックに置けるデータがヒープへ流出する「エスケープ」を引き起こし、パフォーマンスを低下させます。本記事では、このトレードオフを最適化するための判断基準を解説します。
基礎知識：メモリ管理とエスケープ解析
Goには「スタック」と「ヒープ」という2つのメモリ領域があります。通常、関数内で宣言されたローカル変数は高速なスタック領域に確保されます。しかし、関数の外から参照される可能性がある場合、コンパイラはそれを「ヒープ」に移動させます。これを「エスケープ」と呼びます。ヒープに置かれたデータは、Goのガベージコレクタ（GC）による監視対象となり、クリーンアップの負荷を生じさせます。ポインタ渡しは、このエスケープを誘発しやすいという特性があります。
実装/解決策：使い分けの指針
以下の基準で判断するのが現場のベストプラクティスです。
1. 小さな構造体（数ワード程度）：値渡しが有利です。コピーのコストよりも、ポインタを追跡するメモリ参照のコストの方が高くつくことが多いためです。
2. 大きな構造体：ポインタ渡しを推奨します。コピーのコストを回避できるメリットが大きいためです。
3. 状態の共有：関数内でデータを変更したい場合は、必然的にポインタ渡しを選択します。
4. 読み取り専用：大きな構造体であっても、単なる読み取りであればポインタを検討しますが、エスケープによるGC負荷と、コピーによるCPU負荷を天秤にかける必要があります。
サンプルプログラム
以下のコードでは、値渡しとポインタ渡しの挙動を示しています。
package main
import “fmt”
// Data構造体：比較的サイズが大きいと仮定
type Data struct {
Values [100]int
}
// 値渡し：コピーが発生するが、スタックに収まる可能性が高い
func processByValue(d Data) int {
// 読み取り専用であれば、コピーコストのみが発生
return d.Values[0]
}
// ポインタ渡し：コピーは発生しないが、ヒープにエスケープする可能性がある
func processByPointer(d Data) int {
// 巨大な構造体を渡す場合、コピーを避けるために有効
return d.Values[0]
}
func main() {
d := Data{}
// 値渡しを実行
val := processByValue(d)
fmt.Println(“値渡し結果:”, val)
// ポインタ渡しを実行
ptr := processByPointer(&d)
fmt.Println(“ポインタ渡し結果:”, ptr)
}
応用・注意点：現場で役立つヒント
現場で最も注意すべきは「過度な最適化」です。ポインタ渡しを多用すると、コンパイラはすべての変数をヒープに置こうとするため、結果としてGCの頻度が高まり、かえって遅くなることがあります。
Tips：
コンパイラがどちらを選んでいるか確認するには、ビルド時に以下のコマンドを実行してください。
go build -gcflags=”-m”
このフラグを付けると、どの変数がどこにエスケープしたかがコンソールに表示されます。「does not escape」と表示されるものはスタックに配置されているため、効率的なコードであると判断できます。まずはこのコマンドで現在の実装を可視化することから始めてみてください。
コメント