閉じる

ガーベジコレクションって何者？メモリのお片づけをやさしくイメージしよう

広告

プログラムを書いていると、変数やオブジェクトはどんどん増えていきますが、不要になったメモリを誰が片づけてくれているのかを、あらためて意識することは少ないかもしれません。

この記事では、難しい数式やアルゴリズムの詳細に踏み込む前に、「ガーベジコレクション(GC)って、ざっくりどういう仕組みでメモリをお片づけしているのか」をイメージ中心で解説します。

CやC++などの手動メモリ解放との違い、パフォーマンスとの関係、初心者がつまずきやすいポイントもあわせて整理していきます。

目次 [ close ]
  1. ガーベジコレクション(GC)とは？
    1. ガーベジコレクションの基本イメージ
    2. 手動メモリ解放との違い
    3. どんな言語で使われているのか
  2. メモリ管理と「不要になったメモリ」
    1. メモリとは何か
    2. オブジェクトの寿命と「参照」の考え方
    3. 参照が切れたオブジェクトが「ゴミ」になる流れ
  3. ガーベジコレクションの仕組みをイメージで理解
    1. マーク＆スイープ(mark and sweep)方式の流れ
    2. 世代別GC(generational GC)の考え方
    3. ルート(root)オブジェクトと到達可能性の判定
    4. ストップ・ザ・ワールド(stop the world)とは何か
    5. コンパクション(compaction)でメモリを詰める理由
  4. ガーベジコレクションとパフォーマンス
    1. GCが遅く感じるのはどんなときか
    2. メモリリークはGCでも起きるのか
    3. GCを意識したコードの書き方のポイント
    4. よくある誤解と初心者が気をつけたいポイント
  5. まとめ

ガーベジコレクション(GC)とは？

ガーベジコレクションの基本イメージ

ガーベジコレクション(Garbage Collection, GC)とは、プログラムが使い終わったメモリ(オブジェクト)を自動的に検出して解放する仕組みです。

開発者がfree()やdeleteを呼ばなくても、ランタイムやVMが裏側でメモリを掃除してくれます。

このイメージで重要なのは、「どの変数やオブジェクトからもたどれなくなったメモリはゴミとみなされて自動的に回収される」という点です。

GCは常にメモリ空間を監視していて、不要になったオブジェクトを見つけると、適切なタイミングでまとめて片づけを行います。

手動メモリ解放との違い

CやC++などでは、開発者がmalloc()やnewでメモリを確保し、使い終わったらfree()やdeleteで明示的に解放します。

この方式は、細かい最適化ができる一方で、次のようなリスクを抱えています。

  • 解放し忘れるとメモリリークになる
  • すでに解放したメモリにアクセスしてしまうと不正メモリアクセスになる
  • どのタイミングで解放すべきかの判断が難しい

それに対してGCでは、「いつ解放するか」「どのメモリを解放するか」をランタイムに任せるため、解放忘れや二重解放といったバグを大幅に減らせます。

ただし、自動だからといって万能ではなく、GCも万能の魔法ではないという点が重要です。

GCにもコストがあり、そのコスト(パフォーマンス)をどう許容するかが、GC言語設計の重要なテーマになっています。

どんな言語で使われているのか

ガーベジコレクションは、近年の多くの高水準言語で採用されています。

代表的なものを挙げると、次のようになります。

  • Java (JVM)
  • C# / .NET
  • JavaScript
  • Python
  • Ruby
  • Go
  • Kotlin, Scala などのJVM言語
  • 一部のLisp系、Haskellなどの関数型言語

これらの言語では、「メモリ解放は原則としてプログラマの仕事ではなく、ランタイムの責任」という思想が採用されています。

一方で、C/C++やRustのように、開発者(あるいはコンパイラ)がメモリ管理を厳密にコントロールする言語も依然として重要な位置を占めています。

メモリ管理と「不要になったメモリ」

メモリとは何か

プログラムは、実行中にさまざまなデータをメモリ(RAM)上に配置して動いています。

変数、配列、オブジェクト、関数呼び出し時の引数やローカル変数など、すべてがどこかのアドレスに配置されています。

メモリ管理とは、このメモリ空間のどの領域を、どのオブジェクトに割り当てて、いつ返却するかを管理することです。

これをうまくやらないと、次のような問題が起こります。

  • 使っていないメモリが占有され続ける(メモリリーク)
  • ほかのオブジェクトの領域を上書きしてしまう(バッファオーバーフローなど)
  • OSがメモリ不足になり、アプリケーションやシステムが落ちる

GCは、このうち「使っていないメモリを自動的に見つけて解放する部分」を担う仕組みです。

オブジェクトの寿命と「参照」の考え方

GCを理解するうえで欠かせない概念が「オブジェクトの寿命」と「参照(reference)」です。

プログラム中で、あるオブジェクトが「まだ必要かどうか」は、そのオブジェクトにたどり着ける変数や他のオブジェクトのポインタ(参照)が存在するかどうかで決まります。

この矢印があるあいだは、そのオブジェクトは「まだ使われている」とみなされます。

逆に言えば、どの矢印からもたどれないオブジェクトは「もう使われない」とみなしてよいわけです。

参照が切れたオブジェクトが「ゴミ」になる流れ

オブジェクトがゴミになる典型的な流れを簡単に追ってみます。

  1. 変数userが新しいUserオブジェクトを指す
  2. しばらく処理に使われる
  3. 関数の終わりでuserというローカル変数自体がスコープから外れる
  4. 結果として、そのUserオブジェクトにたどり着ける参照がなくなる
  5. GCから見ると、そのオブジェクトは「到達不能(どこからも参照されない)」状態になる
  6. 次回のGC実行時に、そのオブジェクトは「ゴミ」と判断され回収される

ここでのポイントは、オブジェクト自体はまだメモリ上に存在していても、「たどり着く道(参照)」がなくなった瞬間に、GCにとっては回収候補になるということです。

GCは、プログラムから見て「二度とアクセスできないメモリ」を探し出している、とイメージすると分かりやすいです。

ガーベジコレクションの仕組みをイメージで理解

ここからは、GCが内部でどのように「到達不能なオブジェクト」を見つけているのかを、代表的な方式を通じてイメージしていきます。

マーク＆スイープ(mark and sweep)方式の流れ

もっとも基本的で有名なGCアルゴリズムがマーク＆スイープ(Mark and Sweep)です。

名前の通り、「マークする」「掃く」の2段階で動きます。

マーク＆スイープは、ざっくり次のように動きます。

  1. マーク(到達可能性の判定)
    ルート(root)と呼ばれる起点から、参照をたどって行けるオブジェクトをすべて「生きている」とマークします。
    1. グローバル変数やスタック上のローカル変数などからスタート
    2. そこからたどれるオブジェクトを深さ優先や幅優先でたどっていく
    3. たどれたオブジェクトには「マーク済フラグ」を付ける
  2. スイープ(不要メモリの回収)
    ヒープをなめていき、マークが付いていないオブジェクトを解放します。
    1. マーク済み → 生存オブジェクトとして残す
    2. マークなし → ガーベジとして解放

この方式は実装が比較的シンプルで、現在の多くのGCも、基本的な考え方はこの「到達可能性判定 + 回収」という枠組みの延長線上にあります。

世代別GC(generational GC)の考え方

マーク＆スイープをそのまま適用すると、ヒープ全体を毎回スキャンすることになり、大規模なアプリケーションでは非常に遅くなってしまいます。

そこで登場するのが世代別GC(Generational GC)です。

世代別GCは、「若いオブジェクトはすぐ死ぬ、長生きするオブジェクトはずっと生きる」という経験則(世代仮説)に基づいて、オブジェクトを年齢(世代)ごとに分けて管理します。

世代別GCのイメージは次の通りです。

  • Young世代
    • 新しく生成されたオブジェクトが置かれる
    • 短命なオブジェクトが多い
    • 頻繁に、しかし狭い範囲だけGCをかける(マイナーGC)
  • Old世代
    • Young世代で何度もGCをくぐり抜けて生き残った「長寿」オブジェクト
    • ここにいるオブジェクトは、しばらく生き続ける可能性が高い
    • 頻度は少ないが、範囲の広いGCをかける(フルGC/メジャーGC)

こうすることで、「すぐ死ぬ短命オブジェクトを集中的に掃除する」ことで、全体のスキャンコストを大幅に削減できます。

多くの実用言語(Java、.NETなど)のGC実装は、この世代別GCをベースに、さらに多くの最適化を重ねています。

ルート(root)オブジェクトと到達可能性の判定

GCが「どこから参照をたどり始めるか」の起点となるのがルートオブジェクト(root set)です。

ルートは通常、次のようなものを指します。

  • スタックフレーム上のローカル変数
  • CPUレジスタ中のポインタ
  • グローバル変数や静的変数
  • 一部のランタイムが管理する内部オブジェクト

GCは、このルートから再帰的に参照をたどっていき、到達可能なものを「生存」、到達不能なものを「ガーベジ」と判断します。

この「到達可能性(Reachability)」という考え方こそが、多くのGCの根幹にあるアイデアです。

ストップ・ザ・ワールド(stop the world)とは何か

GCがマークやスイープを行っているあいだに、プログラム本体がオブジェクトの参照関係を書き換えてしまうとどうなるでしょうか。

「生きているはずのオブジェクト」を誤ってゴミと判断してしまう可能性があります。

これを防ぐために、多くのGC実装では、GC実行中にアプリケーションの実行を一時停止します。

この一時停止をストップ・ザ・ワールド(Stop The World, STW)と呼びます。

STWの時間が長くなりすぎると、「アプリが一瞬固まった」「レスポンスが悪い」と感じられます。

そこで近年のGCは、並行(Concurrent)やインクリメンタル(Incremental)にGC処理を分割したり、STW時間をミリ秒単位に抑えたりする工夫をしています。

コンパクション(compaction)でメモリを詰める理由

マーク＆スイープ方式でオブジェクトを解放していくと、ヒープ内には「空き領域」と「生存オブジェクト」が混在した、いわゆるメモリの断片化(fragmentation)が起こります。

断片化が進むと、「空きメモリの合計量は十分あるのに、大きな連続領域が取れない」という問題が発生します。

これを解決するのがコンパクション(compaction, 圧縮)です。

コンパクションでは、生存しているオブジェクトを新しい場所にコピーして詰め直し、大きな連続した空き領域を確保します。

これにより、次に大きなオブジェクトを割り当てる際にも、断片化による制限を受けにくくなります。

ただし、オブジェクトのコピーにはコストがかかり、参照を書き換える必要もあるため、すべてのGCが常にコンパクションを行うわけではありません。

若い世代だけコピー方式を使い、古い世代はマーク＆スイープ中心にするなど、さまざまな折衷案が実装されています。

ガーベジコレクションとパフォーマンス

GCが遅く感じるのはどんなときか

「GC言語は遅い」と言われることがありますが、実際にはGCそのものが常に遅いわけではなく、特定の状況で遅さを感じやすい、というのがより正確です。

典型的には次のようなケースで問題になります。

  • 大量のオブジェクトを短時間に生成・破棄する
    • 例: 高頻度のログオブジェクト生成、大量の小さな文字列の連結など
  • ヒープサイズが非常に大きい
    • フルGC(Old世代のGC)が走ると、スキャンコストが高い
  • リアルタイム性が重要なアプリケーション
    • ゲーム、トレーディングシステムなど、数十ミリ秒の止まりも問題になる分野

このようなケースで現れるのが、ストップ・ザ・ワールド(STW)による一時停止です。

GCの停止時間が長く、発生頻度も高いと、ユーザーから見て「カクつく」「反応が悪い」と感じられます。

一方で、適切にチューニングされたGCや、GCフレンドリーなコードであれば、多くの業務システムやWebアプリケーションでは、GCを強く意識しなくても十分なパフォーマンスを得られることも少なくありません。

メモリリークはGCでも起きるのか

「GCがあるからメモリリークは起こらない」と思われがちですが、これは誤解です。

GCが防いでくれるのは「到達不能になったメモリの解放忘れ」だけであり、「論理的には不要だが、参照が残っているオブジェクト」については、GCは解放できません。

例えば次のようなケースを考えてみます。

  • グローバルなリストにオブジェクトを追加し続け、削除を忘れる
  • キャッシュ用のマップにずっと参照を残してしまう
  • イベントリスナーを登録したまま解除しない

どのケースも、「オブジェクトはまだどこかの参照から到達可能」であるため、GCから見ると「生存している」と判断されます。

このような「意図しない長寿オブジェクト」が増え続けると、結果としてメモリ使用量が増え続ける、つまりGC言語でもメモリリークは起こりうる、ということになります。

GCを意識したコードの書き方のポイント

GC自体はランタイムが面倒を見てくれますが、「GCが仕事しやすいコード」を書くことで、パフォーマンスを安定させることができます。

ここでは、ごく基本的なポイントに絞って紹介します。

  1. 不要になったオブジェクトへの参照は早めに外す
    1. 大きなリストやマップ、キャッシュなどでは、使い終わった要素を積極的に削除する
    2. イベントリスナーやコールバックは、不要になったら解除する
  2. 短命オブジェクトを大量に生成しすぎない
    1. ループの中で無駄な一時オブジェクトを作り続けない
    2. 再利用できるバッファやオブジェクトプールを検討する(ただし複雑にしすぎない)
  3. 大きなオブジェクトのライフサイクルを意識する
    1. 巨大な配列や画像データなどは、必要なスコープに閉じ込める
    2. グローバルや長寿オブジェクトに大きなデータをぶら下げない
  4. GCログやプロファイラを活用する
    1. Javaや.NETなどでは、GCログやメモリプロファイラで「どのオブジェクトがどこから参照され、どれくらい残り続けているか」を可視化できる
    2. 数値で現状を把握しながら、ボトルネックを特定する

これらはどれも、「GCが不要オブジェクトを正しく判定できるように、参照関係をきれいに保つ」という発想に基づいています。

よくある誤解と初心者が気をつけたいポイント

最後に、GCにまつわる典型的な誤解と、初心者が気をつけたいポイントをいくつか挙げます。

誤解1: GCがある言語ではメモリ管理を考えなくてよい

いいえ。

GCが肩代わりしてくれるのは、「参照が完全になくなったオブジェクトの解放」部分だけです。

どのオブジェクトをどこまで生かしておくか、という設計は依然としてプログラマの責任です。

特に、グローバルなコレクションやキャッシュを安易に使うと、GCでは回収できない形でのメモリリークを招きます。

誤解2: 明示的にnullを代入しまくれば速くなる

ローカル変数や一時変数に対して、むやみにnullを代入するのは、多くの場合意味がありません。

スコープを抜ければ自動的にルートから外れますし、かえってコードの可読性を下げることもあります。

「長生きするオブジェクトが保持している参照を整理する」ことに集中し、ローカルな一時変数には必要以上に介入しない方が、シンプルでバグも少ない設計になります。

誤解3: GCを無効にできれば、すべて速くなる

一部のランタイムではGCを抑制する設定もありますが、GCを完全に切れば速くなる、という単純な話ではありません。

GCを止めた瞬間から、メモリ解放の責任はすべてプログラマに戻ってくるため、メモリリークや不正メモリアクセスのリスクが一気に高まります。

多くの場合は、GCを切るのではなく、GCの挙動を理解し、それに合ったコードと設定を選ぶことが現実的なアプローチです。

まとめ

ガーベジコレクション(GC)は、「どの変数やオブジェクトからもたどれなくなったメモリ(オブジェクト)を、自動的に見つけて解放する仕組み」です。

マーク＆スイープや世代別GCといった方式を通じて、ルートオブジェクトから到達可能なものだけを生かし、それ以外をガーベジとして回収します。

この記事で押さえておきたいポイントを整理すると、次のようになります。

  • GCは「到達可能性」で生死を判断する
    • 参照が完全に切れたオブジェクトだけが回収対象になる
  • 世代別GCは、「若いオブジェクトほど早く死ぬ」という経験則を活かして効率化
    • Young世代とOld世代を分けて管理し、頻度とコストのバランスを取る
  • ストップ・ザ・ワールドとコンパクションは、GCの停止時間とメモリ断片化に関わる重要な要素
  • GC言語でもメモリリークは起こりうる
    • 参照が残っている限り、GCは解放できない
  • GCを意識したコードとは、「参照の寿命」と「オブジェクトの生存期間」をきれいに設計したコードである

GCは、一見すると「勝手に掃除してくれる便利機能」に見えますが、その裏側には、到達可能性・世代・コンパクション・STWといった多くの工夫が詰め込まれています。

仕組みの大枠をイメージしておくことで、パフォーマンス問題に直面したときにも、「GCのせいだ」で終わらせずに、どこから手を付けるべきかを冷静に考えられるようになります。

今後、より高度なGCチューニングやプロファイリングに進む際にも、この記事で紹介したイメージが、理解の土台として役立つはずです。

メモリ管理・実行モデル

クラウドSSLサイトシールは安心の証です。

URLをコピーしました！