Java ガベージコレクションアルゴリズムの紹介

51CTO 編集者注: 「Java ガベージコレクションメカニズムの簡単な分析」では、Java ガベージコレクションメカニズムには一般に 10 個近くのアルゴリズムが含まれていることを紹介しました。この記事では、「Java ガベージコレクションアルゴリズムの概要」を紹介します。

導入

Java ヒープは、クラスのインスタンス (オブジェクト) にスペースが割り当てられる実行時データ領域です。 Java 仮想マシン (JVM) ヒープには、実行中のアプリケーションによって作成されたすべてのオブジェクトが格納されます。これらのオブジェクトは、new、newarray、anewarray、multianewarray などの命令によって作成されますが、明示的に解放するためのプログラムコードは必要ありません。一般的に、ヒープはガベージコレクションによって管理されます。JVM 仕様では、特別なガベージコレクションテクノロジやガベージコレクションはまったく必要ありませんが、メモリが限られているため、JVM が実装されると、ガベージコレクションによって管理されるヒープが存在します。ガベージコレクションは、プログラムによって参照されなくなったオブジェクトを自動的に解放し、特定のガベージコレクションアルゴリズムに従って自動リソース回復機能を実装する動的なストレージ管理テクノロジです。

ガベージコレクションの重要性

C++ では、オブジェクトによって占有されたメモリはプログラムが終了するまで占有され、明示的に解放されるまで他のオブジェクトに割り当てることはできません。Java では、オブジェクトに最初に割り当てられたメモリを指すオブジェクト参照がない場合、そのメモリはガベージになります。 JVM のシステムレベルのスレッドはメモリブロックを自動的に解放します。ガベージコレクションとは、プログラムで不要になったオブジェクトが「ジャンク情報」となり、破棄されることを意味します。オブジェクトが参照されなくなると、メモリは占有していたスペースを再利用し、そのスペースを後続の新しいオブジェクトが使用できるようにします。実際、ガベージコレクションでは、未使用のオブジェクトを解放するだけでなく、メモリレコードの断片化も解消できます。オブジェクトの作成によって占有されるメモリ領域と、破棄されたオブジェクトを解放するガベージコレクターによって、メモリが断片化されます。フラグメントは、オブジェクトに割り当てられたメモリブロック間の空きメモリの穴です。デフラグにより、占有されているヒープメモリがヒープの一方の端に移動され、JVM はデフラグされたメモリを新しいオブジェクトに割り当てます。

ガベージコレクションはメモリ領域を自動的に解放し、プログラミングの負担を軽減します。これにより、Java 仮想マシンにいくつかの利点がもたらされます。まず、プログラミングの効率を向上させることができます。ガベージコレクションがない場合、不明瞭なメモリの問題を解決するのに長い時間がかかることがあります。 Java でプログラミングする場合、ガベージコレクションメカニズムによって時間を大幅に短縮できます。第二に、プログラムの整合性を保護します。ガベージコレクションは、Java 言語のセキュリティ戦略の重要な部分です。

ガベージコレクションの潜在的な欠点は、そのオーバーヘッドがプログラムのパフォーマンスに影響することです。 Java 仮想マシンは、実行中のプログラム内の有用なオブジェクトを追跡し、最終的には未使用のオブジェクトを解放する必要があります。このプロセスにはプロセッサ時間がかかります。第二に、ガベージコレクションアルゴリズムは不完全です。以前使用されていたガベージコレクションアルゴリズムの中には、破棄されたすべてのメモリを 100% 収集することを保証できないものもあります。もちろん、ガベージコレクションアルゴリズムの継続的な改善と、ソフトウェアおよびハードウェアの動作効率の継続的な改善により、これらの問題は簡単に解決できます。

ガベージコレクションアルゴリズムの分析

Java 言語仕様では、JVM がどのガベージコレクションアルゴリズムを使用するかは明示的には規定されていませんが、ガベージコレクションアルゴリズムは一般に、(1) 未使用の情報オブジェクトを検出すること、(2) 未使用のオブジェクトによって占有されているメモリ領域を再利用して、プログラムでその領域を再び使用できるようにするという 2 つの基本的な処理を実行する必要があります。

ほとんどのガベージコレクションアルゴリズムはルートセットの概念を使用します。いわゆるルートセットは、実行中の Java プログラムがアクセスできる参照変数 (ローカル変数、パラメーター、クラス変数を含む) のコレクションです。プログラムは参照変数を使用してオブジェクトのプロパティにアクセスし、オブジェクトのメソッドを呼び出すことができます。ガベージコレクションでは、まずルートから到達可能なオブジェクトと到達不可能なオブジェクトを判別する必要があります。ルートセットから到達可能なオブジェクトはアクティブオブジェクトであり、ルートセットから間接的に到達可能なオブジェクトを含め、ガベージとしてリサイクルすることはできません。どのパスからも到達できないルートセット内のオブジェクトは、ガベージコレクションの条件を満たしており、リサイクルする必要があります。以下に、よく使用されるアルゴリズムをいくつか紹介します。

参照カウントコレクター

参照カウントアルゴリズムは、ルートセットを使用しない唯一のガベージコレクションアルゴリズムです。このアルゴリズムは、参照カウンターを使用して、ライブオブジェクトと使用されなくなったオブジェクトを区別します。一般的に言えば、ヒープ内の各オブジェクトは参照カウンターに対応します。オブジェクトが作成され、変数に割り当てられるたびに、参照カウンターは 1 に設定されます。オブジェクトが任意の変数に割り当てられると、オブジェクトがスコープ外になる（オブジェクトが破棄され、使用されなくなる）たびに参照カウンタが 1 増加し、参照カウンタが 1 減少します。参照カウンタが 0 に達すると、オブジェクトはガベージコレクションの条件を満たします。

参照カウンターに基づくガベージコレクターは実行速度が速く、プログラムの実行を長時間中断することがないため、リアルタイムで実行する必要があるプログラムに適しています。しかし、参照カウンターは、オブジェクトが新しい変数に割り当てられるたびにカウンターが 1 ずつ増加し、既存のオブジェクトがスコープ外になるたびにカウンターが 1 ずつ減少するため、プログラム実行のオーバーヘッドを増加させます。

トレースアルゴリズム（トレースコレクター）

トレースアルゴリズムは参照カウント方式の問題を解決するために提案されており、ルートセットの概念を使用します。トレースアルゴリズムに基づくガベージコレクターは、ルートセットからスキャンを開始し、到達可能なオブジェクトと到達不可能なオブジェクトを識別し、到達可能なオブジェクトごとに 1 つ以上のビットを設定するなど、何らかの方法で到達可能なオブジェクトをマークします。スキャンおよび認識プロセスでは、トレースアルゴリズムに基づくガベージコレクションは、マークアンドスイープガベージコレクターとも呼ばれます。

圧縮コレクター

ヒープの断片化の問題を解決するために、トレースベースのガベージコレクションは、Compacting アルゴリズムの考え方を取り入れています。クリア処理中、アルゴリズムはすべてのオブジェクトをヒープの一方の端に移動し、ヒープのもう一方の端は隣接する空きメモリ領域になります。コレクターは、移動するすべてのオブジェクトへのすべての参照を更新し、これらの参照が新しい場所にある元のオブジェクトを識別できるようにします。コンパクト化アルゴリズムに基づくコレクターの実装では、通常、ハンドルとハンドルテーブルが追加されます。

コピーアルゴリズム（コピーコレクター）

このアルゴリズムは、ハンドルのオーバーヘッドを克服し、ヒープ断片化のガベージコレクションを解決するために提案されました。最初にヒープをオブジェクトプレーンと複数の空きプレーンに分割します。プログラムはオブジェクトプレーンからオブジェクト用のスペースを割り当てます。オブジェクトプレーンがいっぱいになると、対処アルゴリズムに基づくガベージコレクションがルートセットからアクティブオブジェクトをスキャンし、各アクティブオブジェクトを空きプレーンにコピーします (アクティブオブジェクトが占有するメモリ間に空きの穴がないようにするため)。このようにして、空きプレーンがオブジェクトプレーンになり、元のオブジェクトプレーンが空きプレーンになり、プログラムは新しいオブジェクトプレーンにメモリを割り当てます。

対処アルゴリズムに基づく典型的なガベージコレクションは、ヒープ領域をオブジェクトプレーンと空き領域プレーンに分割するストップアンドコピーアルゴリズムです。オブジェクトプレーンと空き領域プレーン間の切り替え処理中は、プログラムの実行が中断されます。

世代コレクター

ストップアンドコピーガベージコレクターの欠点の 1 つは、コレクターがすべてのライブオブジェクトをコピーする必要があることです。これにより、プログラムの待機時間が長くなり、対処アルゴリズムが非効率的になる理由になります。プログラミングには、ほとんどのオブジェクトは短い時間しか存在しないが、少数のオブジェクトは長い時間存在するというルールがあります。したがって、生成アルゴリズムはヒープを 2 つ以上のサブヒープ (各サブヒープはオブジェクトの世代) に分割します。ほとんどのオブジェクトの寿命は短いため、プログラムが未使用のオブジェクトを破棄すると、ガベージコレクターは最も新しいサブヒープからそれらを収集します。世代別ガベージコレクターが実行されると、前回の実行で残ったオブジェクトは次の世代のサブヒープに移動されます。古い世代のサブヒープは頻繁にリサイクルされないため、時間が節約されます。

アダプティブコレクター

特定の状況では、一部のガベージコレクションアルゴリズムが他のアルゴリズムよりも優れています。適応アルゴリズムに基づくガベージコレクターは、現在のヒープ使用状況を監視し、適切なアルゴリズムを持つガベージコレクターを選択します。 #p#

Java ガベージコレクションの展望

ガベージコレクターの動作を確認するためのコマンドラインパラメータ

System.gc() を使用すると、JVM が使用するガベージコレクションアルゴリズムに関係なく、Java ガベージコレクションを要求できます。コマンドラインには、Java が使用するヒープメモリを表示できるパラメータ -verbosegc があります。その形式は次のとおりです。

 java -verbosegc クラスファイル

例を見てみましょう:

クラス TestGC 
 
 { 
 
パブリック静的void main(String[] args) 
 
 { 
 
新しい TestGC(); 
 
システム.gc(); 
 
 System.runFinalization(); 
 
 } 
 
 }

この例では、新しいオブジェクトが作成され、使用されていないため、すぐにアクセス可能になります。プログラムがコンパイルされた後、コマンド java -verbosegc TestGC が実行され、結果は次のようになります。

 [フルGC 168K- > 97K(1984K)、0.0253873秒]

マシン環境は Windows 2000 + JDK1.3.1 です。矢印の前後のデータ 168K と 97K は、それぞれガベージコレクション GC の前後で生き残ったすべてのオブジェクトが使用したメモリ容量を表しており、168K-97K=71K のオブジェクト容量が回収されたことを示しています。括弧内のデータ 1984K はヒープメモリの総容量です。コレクションに要した時間は 0.0253873 秒です (この時間は実行ごとに異なります)。

ガベージコレクターの動作に関する最終メソッドの観点

JVM ガベージコレクターがオブジェクトを収集する前に、プログラムが適切なメソッドを呼び出してリソースを解放する必要があります。ただし、リソースが明示的に解放されていない場合、Java はオブジェクトを終了してリソースを解放するデフォルトのメカニズムを提供します。このメソッドは finalize() です。そのプロトタイプは次のとおりです。

保護された void finalize() は Throwable をスローします

finalize() メソッドが返されると、オブジェクトは消え、ガベージコレクションが開始されます。プロトタイプの throws Throwable は、任意のタイプの例外をスローできることを示します。

finalize() を使用する理由は、通常の Java アプローチとは異なるアプローチを取り、メモリを割り当てることで C スタイルで処理する必要がある場合があるためです。これは主に「組み込みメソッド」を通じて実行できます。組み込みメソッドは、Java から非 Java メソッドを呼び出す方法です。現在ネイティブメソッドをサポートしている言語は C と C++ だけです。しかし、他の言語で書かれたサブルーチンを呼び出すことができるので、実質的に何でも呼び出すことができます。 Java 以外のコード内では、C の malloc() ファミリの関数を呼び出してストレージ領域を割り当てることができる場合があります。また、free() が呼び出されない限り、ストレージスペースは解放されず、メモリの「リーク」が発生します。もちろん、free() は C および C++ 関数なので、finalize() 内の組み込みメソッドから呼び出す必要があります。つまり、finalize() をあまり使用することはできません。これは、一般的なクリーンアップ作業を実行するのに理想的な場所ではありません。

通常のクリーンアップ作業では、オブジェクトをクリーンアップするには、そのオブジェクトのユーザーがクリーンアップが必要な場所でクリーンアップメソッドを呼び出す必要があります。これは、C++ の「デストラクタ」の概念とわずかに矛盾します。 C++ では、すべてのオブジェクトが破棄 (クリーンアップ) されます。言い換えれば、すべてのオブジェクトは「破棄」される必要があります。 C++ オブジェクトがスタック上などのローカルオブジェクトとして作成される場合 (Java では不可能)、クリーンアップまたは破棄の作業は、オブジェクトが作成された「閉じ中括弧」によって表されるスコープの終了時に実行されます。オブジェクトが new を使用して作成された場合 (Java と同様)、プログラマーが C++ delete コマンド (Java にはこのコマンドはありません) を呼び出すと、対応するデストラクタが呼び出されます。プログラマが忘れると、デストラクタは呼び出されず、オブジェクトの他の部分がクリーンアップされないメモリ「ホール」ができてしまいます。

対照的に、Java ではローカルオブジェクトの作成は許可されていないため、いずれにしても new を使用する必要があります。しかし、Java では、ガベージコレクターがストレージ領域を自動的に解放するため、オブジェクトを解放するための「削除」コマンドはありません。したがって、より単純化した観点に立つと、Java にデストラクタがないのは、まさにガベージコレクションメカニズムが存在するためであると言えます。ただし、詳しく学習するにつれて、ガベージコレクターの存在によってデストラクタの必要性やデストラクタが表すメカニズムの必要性が完全になくなるわけではないことがわかります (finalize() を直接呼び出すことは絶対に避けるべきなので、使用しないようにしてください)。ストレージスペースを解放する以外の何らかのクリーンアップを実行する場合は、Java でメソッドを呼び出す必要があります。これは C++ デストラクタと同等ですが、それほど便利ではありません。

次の例は、ガベージコレクションのプロセスを示し、前のステートメントを要約したものです。

クラスチェア{ 
 
静的ブール値gcrun = false ; 
 
静的ブール値f = false ; 
 
静的int作成= 0 ; 
 
静的 int最終化= 0 ; 
 
整数 i;
椅子（） { 
 
 i = ++ 作成されました; 
 
 if(作成== 47) 
 
 System.out.println("47が作成されました"); 
 
 } 
 
保護されたvoid finalize() { 
 
 if(!gcrun) { 
 
 gcrun = true ; 
 
 System.out.println("" + created + " 個の椅子が作成された後、終了処理を開始します"); 
 
 } 
 
もし( i == 47) { 
 
 System.out.println("チェア #47 を終了しています。" +"チェアの作成を停止するフラグを設定しています。"); 
 
真の場合
 
 } 
 
確定しました++; 
 
 if (確定済み> = 作成済み) 
 
 System.out.println("すべて " + 完了 + " 完了"); 
 
 } 
 
 } 
 
パブリッククラスGarbage { 
 
パブリック静的voidメイン(String[] args) { 
 
 if( args.length == 0) { 
 
 System.err.println("使用法: n" + "java のガベージ beforen または:n" + "java のガベージ after"); 
 
戻る; 
 
 } 
 
 while(!Chair.f) { 
 
新しい椅子(); 
 
 new String("スペースを取るため"); 
 
 } 
 
 System.out.println("すべての椅子が作成された後:n" + "作成された合計= " + Chair.created + 
 
 "、合計確定= " + Chair.finalized); 
 
 if(args[0].equals("before")) { 
 
 System.out.println("gc():"); 
 
システム.gc(); 
 
 System.out.println("runFinalization():"); 
 
 System.runFinalization(); 
 
 }
 System.out.println("さようなら!"); 
 
 if (args[0].equals("after")) 
 
 System.runFinalizersOnExit(true); 
 
 } 
 
 }

上記のプログラムは多くの Chair オブジェクトを作成し、ガベージコレクターの実行が開始された後のある時点で、プログラムは Chair の作成を停止します。ガベージコレクターはいつでも実行される可能性があるため、いつ開始されるかを正確に知ることはできません。したがって、プログラムは gcrun と呼ばれるフラグを使用して、ガベージコレクターの実行が開始されたかどうかを示します。 2 番目のフラグ f を使用して、Chair は main() にオブジェクトの作成を停止するように指示します。これらのフラグは両方とも、ガベージコレクション中に呼び出される finalize() 内で設定されます。他の 2 つの静的変数 (created と finalized) は、作成されたオブジェクトの数と、ガベージコレクターが完了済みのオブジェクトの数を追跡するために使用されます。 ***、各 Chair には独自の (非静的) int i があるため、特定の番号を追跡できます。椅子 47 の仕上げ作業が完了すると、フラグが true に設定され、椅子オブジェクトの作成プロセスが最終的に終了します。 #p#

ガベージコレクションに関するコメント

上記の説明から、ガベージコレクションには次の特性があることがわかります。

(1) ガベージコレクションの予期しない発生: 異なるガベージコレクションアルゴリズムの実装と異なるコレクションメカニズムの使用により、システム内にアイドル状態の CPU リソースがあるときに定期的に発生する場合や、元のガベージコレクションと同様にメモリ消費が限界に達したときに発生する場合があります。これは、ガベージコレクターの選択と特定の設定に関係しています。

（２）ガベージコレクションの精度：これには主に２つの側面が含まれます：（ａ）ガベージコレクターは生きているオブジェクトを正確にマークすることができます。（ｂ）ガベージコレクターはオブジェクト間の参照関係を正確に見つけることができます。前者は、放棄されたすべてのオブジェクトを完全にリサイクルするための前提条件であり、そうでない場合はメモリリークが発生する可能性があります。後者は、マージやコピーなどのアルゴリズムを実装するための必要条件です。到達不能なオブジェクトはすべて確実に回収され、すべてのオブジェクトを再割り当てできるため、オブジェクトの複製とオブジェクトメモリの縮小が可能になり、メモリの断片化が効果的に防止されます。

(3) ガベージコレクターにはさまざまな種類があり、それぞれ独自のアルゴリズムとパフォーマンスを備えています。ガベージコレクションの開始時にアプリケーションの実行を停止するものもあれば、アプリケーションのスレッドを実行できるようにするもの、複数のスレッドが同時にガベージコレクションを実行できるようにするものもあります。

（4）ガベージコレクションの実装は、特定のJVMとJVMのメモリモデルに密接に関連しています。異なる JVM では異なるガベージコレクションメソッドが使用される場合があり、JVM のメモリモデルによって、JVM が使用できるガベージコレクションの種類が決まります。現在、HotSpot シリーズ JVM のメモリシステムは、高度なオブジェクト指向フレームワークを使用して設計されており、このシリーズの JVM では最先端のガベージコレクションを使用できます。

（５）技術の発展に伴い、現代のガベージコレクション技術は多くのオプションのガベージコレクターを提供しており、各コレクターを構成する際に異なるパラメータを設定できるため、さまざまなアプリケーション環境に応じて最適なアプリケーションパフォーマンスを得ることができます。

上記の特性を考慮して、使用時には以下の点に注意する必要があります。

（1）ガベージコレクションがいつ発生するかを推測しないでください。これは不明です。たとえば、メソッド内の一時オブジェクトは、メソッド呼び出しが完了すると役に立たないオブジェクトになり、この時点でそのメモリを解放できます。

(2) Java はガベージコレクションを処理するクラスをいくつか提供しており、System.gc() を呼び出してガベージコレクションを強制する方法も提供していますが、これも不確実な方法です。 Java では、このメソッドが呼び出されるたびにガベージコレクションが開始されることは保証されません。そのような要求を JVM に送信するだけです。ガベージコレクションが実際に実行されるかどうかはまだ不明です。

（３）自分に合ったゴミ収集業者を選びましょう。一般的に、システムに特別で厳しいパフォーマンス要件がない場合は、JVM のデフォルトオプションを使用できます。それ以外の場合は、リアルタイム要件が高いシステムに適した増分コレクターなどのターゲットを絞ったガベージコレクターの使用を検討できます。システムの構成が高度で、アイドルリソースが多くなっています。並列マーク/スイープコレクターの使用を検討できます。

（4）重要かつ把握しにくい問題はメモリリークです。良いプログラミング習慣と厳格なプログラミング姿勢は常に最も重要です。小さなミスで大きな記憶の穴をあけないようにしてください。

（５）未使用のオブジェクトへの参照をできるだけ早く解放する。一時変数を使用する場合、ほとんどのプログラマーは、アクティブスコープを終了した後に参照変数を自動的に null に設定し、ガベージコレクターがオブジェクトを収集するように指示します。参照先のオブジェクトがリッスンされているかどうかにも注意する必要があります。リッスンされている場合は、リスナーを削除してから null 値を割り当てる必要があります。

結論

一般的に、Java 開発者は JVM でのヒープメモリの割り当てとガベージコレクションを無視できますが、Java のこの機能を完全に理解することで、リソースをより効率的に使用できるようになります。同時に、finalize() メソッドは Java のデフォルトのメカニズムであることに注意してください。場合によっては、オブジェクトリソースの明確な解放を保証するために、独自の finalize メソッドを記述することもできます。

電話クラブ——51CTO モバイル開発オフライン技術サロン

イベント日: 12月19日このセッションのテーマ: 高度なAndroidアプリケーション開発技術場所: 北京市海淀区北四環路西66号第三極ビルBブロック18階、イノベーションワークス講演者: 王明麗 (イノベーションワークス) ファン・フアイユ (NetEase) 登録するにはここをクリックしてください

【編集者のおすすめ】