【仕組み解説】ガベージコレクションはどうやって不要なメモリを回収しているのか — GCの仕組みを図解

プログラムが動くとき、データを置くために「メモリ」っていう作業スペースを使うんだけど、使い終わったデータをそのままにしておくとスペースがどんどん埋まっちゃうよね。ガベージコレクション（GC）は、その「もう使わないデータ」を自動で見つけて片付けてくれる仕組みだよ。

あるよ。CやC++みたいな言語では、プログラマが自分で malloc() でメモリを確保して、使い終わったら free() で返す、っていう手動管理をするんだ。でも人間がやると「解放し忘れてメモリが足りなくなる（メモリリーク）」とか「もう解放したメモリを使っちゃう（ダングリングポインタ）」みたいなバグが起きやすいんだよね。

かなり楽になるよ。JavaやPython、JavaScriptなんかはGCが標準搭載されてて、プログラマがメモリの解放を意識しなくていいんだ。ただし、GCにもいくつかの方式があって、それぞれ得意・不得意があるんだよ。

代表的なのは「マーク&スイープ」方式だよ。まず、プログラムの「ルート」と呼ばれる起点（グローバル変数やスタック上の変数）からたどれるオブジェクトに「使用中」の印（マーク）を付けていくんだ。次に、マークが付いていないオブジェクトは「もう誰からも参照されてない＝ゴミ」と判断して回収（スイープ）する。到達できるかどうかで生死を判定するシンプルな仕組みだよ。

「参照カウント」方式もあるよ。各オブジェクトが「自分を参照している数」を持っていて、参照が増えるとカウントを＋1、減ると−1する。カウントが0になった瞬間にすぐ回収できるから、タイミングが予測しやすいんだ。Pythonはこの方式をベースにしてるよ。

弱点があるんだよ。「循環参照」って言って、オブジェクトAがBを参照して、BがAを参照してる状態だと、どちらもカウントが0にならないから回収できないんだ。だからPythonでは参照カウントに加えて、循環参照を検出する補助的なGCも併用してるよ。

世代別GCだね。これは「若いオブジェクトほど早く不要になる」っていう経験則に基づいた方式だよ。メモリ上のオブジェクトを「Young世代」「Old世代」に分けて、Young世代は頻繁にGCするけど、Old世代はたまにしかGCしないんだ。毎回全部チェックするより圧倒的に効率がいいんだよ。JavaのJVMが採用してることで有名だね。

いい質問だね。従来のGCには「Stop-the-World」っていう問題があって、GCが動いてる間はプログラムの実行が一時停止するんだ。数ミリ秒程度ならいいけど、データが大量にあると数百ミリ秒止まることもあって、リアルタイム性が求められるゲームや金融システムだと致命的になりうるよ。

GoのGCはプログラムの実行と並行してマーク処理を行う「コンカレントGC」を採用していて、Stop-the-World の時間を数百マイクロ秒以下に抑えてるよ。JavaのZGCやShenandoah GCも同様のアプローチだね。JavaScriptのV8エンジンも世代別＋インクリメンタル（少しずつ処理）方式で、ユーザーが体感する停止を減らしてるんだ。

Rustだね。Rustは「所有権システム」という仕組みで、コンパイル時にメモリの寿命を決定するんだ。各データには必ず1つの「所有者」がいて、所有者がスコープを抜けると自動的に解放される。GCのランタイムコストがゼロなのに、メモリリークもダングリングポインタも起きない。GCとは全く違うアプローチでメモリ安全を実現した画期的な設計だよ。

用途次第だね。Webアプリやビジネスロジックなら、開発効率を重視してGC付きの言語（Java, Go, Python）が向いてる。リアルタイム処理や組み込みシステムならRustやC++が強い。最近のトレンドとしては、GCの停止時間をいかに短くするかが各言語の競争ポイントになっていて、GoやJavaは世代を重ねるごとに大幅に改善してきてるよ。GCは50年以上の歴史がある技術だけど、今も進化し続けてるんだ。