導入
関数型プログラミングにおいて、データ構造の「不変性（Immutability）」は核心となる概念です。しかし、実務の現場では「毎回データをコピーして新しいオブジェクトを作るのは、メモリ効率やGC（ガベージコレクション）の観点から不利ではないか？」という懸念がよく聞かれます。本稿では、この「ガーベジの発生」という課題が、現代のランタイムにおいてどのように扱われているのかを解説します。
基礎知識：世代別GCの仕組み
不変データ構造を採用すると、更新のたびに新しいインスタンスが生成されます。これを「短命なオブジェクト」と呼びます。多くの現代的なGC（特にGHCやJVMなど）は「世代別GC（Generational GC）」というアルゴリズムを採用しています。
このアルゴリズムの前提は「ほとんどのオブジェクトは生成されてすぐに不要になる」という経験則です。メモリを「若い世代（New generation）」と「古い世代（Old generation）」に分け、若い世代に対して頻繁にスキャンを行います。生存期間の短いオブジェクトは、この若い世代の領域で非常に軽量に回収されるため、アプリケーション全体への停止時間（Stop-the-world）への影響は驚くほど小さく抑えられています。
実装/解決策：効率的なデータ更新
不変データ構造で重要なのは、単に新しいオブジェクトを作るだけでなく、「構造共有（Structural Sharing）」を活用することです。変更が必要な箇所だけを新しく生成し、変更がない箇所は元のデータ構造の参照を再利用することで、メモリ消費とコピーコストを最小化します。
サンプルプログラム
ここでは、Haskellを例に、不変リストの先頭へ要素を追加する際の構造共有の様子を示します。新しいリストは古いリストを再利用するため、メモリ負荷は非常に低くなります。
// Haskellでの実装例
main :: IO ()
main = do
— 元となるリストを作成
let list1 = [2, 3, 4]
— list1の先頭に1を追加して新しいリストを作成
— 内部的にはlist1のメモリ領域を再利用するため、コピーは最小限です
let list2 = 1 : list1
— 結果を表示
print list2 — 出力: [1, 2, 3, 4]
{-
解説:
1 : list1 という操作は、新しいメモリ領域にリスト全体をコピーするわけではありません。
新しい「ノード（1）」を作成し、その次（next）のポインタを既存の「list1」に向けるだけです。
このため、メモリ確保のコストは極めて小さく、GCもこのノードを迅速に処理できます。
-}
応用・注意点：現場で役立つアドバイス
不変データ構造における「ガーベジの発生」を過度に恐れる必要はありませんが、以下の点には注意が必要です。
1. 過度な最適化の罠
「オブジェクト生成を減らそう」として、可変（Mutable）なデータ構造や複雑なキャッシュを導入すると、コードの可読性が下がるだけでなく、バグの温床になります。まずは不変データ構造で実装し、パフォーマンスプロファイラで問題が確認された場合にのみ、可変なデータ構造（例：STモナドやIORef）を検討してください。
2. 長寿命オブジェクトの混入
「短命なオブジェクト」はGCにとって低コストですが、もし不変データ構造のまま、巨大なリストを長い間保持し続けてしまうと、それが「古い世代」に昇格してしまいます。こうなると回収コストが上がります。意図的に参照を外す（Nullにするなど）ことで、古い世代への昇格を防ぐ設計も重要です。
結論として、不変データ構造による「ガーベジの発生」は、現代のランタイムにおいては「コスト」ではなく「設計上のトレードオフ」として適切に管理されています。恐れずに、宣言的で安全なコードを記述していきましょう。
コメント