このため、Javaにはメモリリークがないという誤った結論が出されることがあり、メモリについてあまり考える必要はありません。 また、ホリバーは、多くの場合、過剰なメモリ消費を行います。
以下で説明するすべては、SunのJVM（HotSpot）バージョン5.0以降の実装に適用され、特定の詳細とアルゴリズムはバージョンによって異なる場合があります。
そのため、プロセスメモリはヒープ（ヒープ）メモリと非ヒープ（スタック）メモリに分かれており、5つの領域（メモリプール、メモリスペース）で構成されています。
•Eden Space（ヒープ）-この領域では、プログラムから作成されたすべてのオブジェクトにメモリが割り当てられます。 ほとんどのオブジェクトは長生きしません（イテレータ、メソッド内で使用される一時オブジェクトなど）。それらはガベージコレクション中に削除されます。これらは他のメモリ領域に移動されないメモリ領域です。 この領域がいっぱいになると（つまり、この領域に割り当てられたメモリの量が一定の割合を超えると）、GCはガベージのマイナーコレクションを実行します。 完全なガベージコレクションと比較すると、少し時間がかかり、このメモリ領域のみに影響します-廃止されたEden Spaceオブジェクトをクリーンアップし、生き残ったオブジェクトを次の領域に移動します。
•サバイバースペース（ヒープ）-前のオブジェクトのオブジェクトは、少なくとも1つのガベージコレクションを生き残った後、ここに移動します。 時々、このエリアからの長命のオブジェクトはTenured Spaceに移動します。
•Tenured（Old）Generation（heap）-長期間有効なオブジェクト（大きな高レベルオブジェクト、シングルトーン、リソースマネージャーなど）がここに蓄積されます。 この領域がいっぱいになると、作成されたすべてのJVMオブジェクトを処理する完全なメジャーコレクションが実行されます。
•永続生成（非ヒープ）-JVMが使用するメタ情報（使用されているクラス、メソッドなど）を保存します。 特に
•コードキャッシュ（非ヒープ）-この領域は、JITコンパイルが有効な場合にJVMによって使用され、コンパイルされたプラットフォーム固有のコードがキャッシュされます。
ここ-blogs.sun.com/vmrobot/entry/disposal_base collection_hotspotには、ガベージコレクターの動作に関する説明があります。 再入力する理由はありません。ここで詳細を読みたいと思うすべての人にアドバイスします。
記事は私のものではありません。 Zorkus