コーヒーブレイク#210。知っておくべきJavaのすべてのタイプのガベージコレクタ

出典: Hackernoon この投稿を通じて、Java 開発で使用される各タイプのガベージ コレクターの長所と短所を学びます。 ガベージ コレクター (GC) に関する質問は、ほぼすべてのインタビューで聞かれます。そこで私は、短くてシンプルという私のお気に入りの原則を使用して、それらに関する必要な情報をすべて収集することにしました。まず、CG の目的と複数の種類のガベージ コレクターが必要な理由から始めましょう。C のような言語では、オブジェクト情報をメモリに保存し、そのメモリを解放するために多くの定型コードを記述する必要があります。もちろん、このようなプログラムではメモリ リークがよく発生します。Java は、ガベージ コレクターを使用してメモリ リークの問題を解決します。また、開発者は、どのガベージ コレクターを使用するのが最適かを知っておく必要があります。プログラムがどこでどのように実行されるかによって大きく異なります。弱いハードウェアまたは多数のオブジェクトで実行される可能性があります。あるいは、プログラムが非常に高速である必要があります。これらの条件に基づいて、望ましいパフォーマンスを達成するようにガベージ コレクターを調整する必要があります。それでは、始めましょう。

JVM がメモリをどのように扱うか

Java 仮想マシン (JVM) は、メモリを 2 つの領域に分割します。アプリケーション データを格納するヒープ領域と、プログラム コードやその他のデータを格納する非ヒープ領域です。ヒープ領域に注目してみましょう。ここで、プログラムは新しいオブジェクトを作成します。すべてのガベージ コレクターは、多くのプログラムが一時オブジェクトを使用するという事実に基づいています。つまり、これらのオブジェクトは作成された後、その機能を果たし、不要になったということです。そのようなオブジェクトの大部分。しかし、オブジェクトによっては、はるかに長く存続し、場合によってはプログラムの全期間にわたって存続する場合もあります。ここで、オブジェクトを若い世代と古い世代に分けるという考えが生まれます。そして私たちは若い世代の様子を頻繁にチェックする必要があります。実際、ガベージコレクションのプロセスは、若い世代のみに影響を与える小規模な清掃と、両方の世代に影響を与える可能性のある完全な清掃に分けられます。ガベージ コレクターはプログラムであることに注意してください。また、動作するには時間とコンピューターのリソースが必要です。これはアプリケーションにも影響します。それはどのように影響しますか? たとえば、ガベージ コレクションを実行するために、JVM はアプリケーションを一時停止します。これは、Stop-The-World (STW) 一時停止と呼ばれます。この間、すべてのアプリケーション スレッドは一時停止されます。しかし、内部のアプリケーションはこれをまったく認識しません。アプリケーションの場合、時間は均等に流れます。なぜこれほど悪いのでしょうか? 想像してみてください。あなたは、ある種の交換アプリケーションや飛行機の自動操縦用のアプリケーションを作成しているとします。アプリケーションが 1 秒間スリープ状態になり、問題の性質が劇的に変化する可能性があります。つまり、一時停止はすべてのガベージ コレクターにとって重要なパラメーターです。ガベージ コレクターの次の基本的なプロパティは、プログラムの合計実行時間に対するガベージの収集に費やされた合計時間です。これは何を意味し、なぜそれほど重要なのでしょうか? 1 つの大きな「Stop-The-World」フェーズの代わりに、多数の小さな一時停止を含むアルゴリズムを選択できます。小さな休憩は望ましいですが、無料のものはありません。この場合、プログラムの合計実行時間を増やすことで支払います。そして、このことも考慮に入れなければなりません。次のパラメータはハードウェア リソースの量です。各コレクターには、オブジェクト情報を保存するためのメモリと、クリーンアップを実行するためのプロセッサが必要です。最後のパラメータは速度です。ガベージ コレクションの効率とは、プログラムによって使用されなくなったメモリをガベージ コレクター (GC) がどれだけ迅速かつ効率的に再利用するかを指します。これらすべてのパラメーターはアルゴリズムに影響を与え、リソースの消費を最小限に抑えながらできるだけ早くメモリを解放できます。利用できるガベージ コレクターを見てみましょう。面接では最初の 5 つを知っておく必要があります。他の 2 つははるかに難しいです。

シリアル GC

シリアル GC は Java 仮想マシンのガベージ コレクターであり、Java の初期から使用されてきました。これは、ヒープが小さく、それほど強力ではないマシンで実行されるプログラムに役立ちます。このガベージ コレクターは、ヒープを Eden と Survivor を含む領域に分割します。Eden リージョンは、ほとんどのオブジェクトのメモリが最初に割り当てられるプールです。Survivor は、エデン リージョンのガベージ コレクションで生き残ったオブジェクトを含むプールです。ヒープがいっぱいになると、オブジェクトは Eden 領域と Survivor 領域の間で移動されます。JVM は、Survivor 領域へのオブジェクトの移動を常に監視し、そのような移動の数に適切なしきい値を選択した後、オブジェクトは Tenured 領域に移動されます。Tenured 領域に十分なスペースがない場合は、フル ガベージ コレクションが引き継ぎ、両方の世代のオブジェクトを処理します。 このガベージ コレクターの主な利点は、リソース要件が低いため、収集を実行するには低電力プロセッサで十分であることです。シリアル GC の主な欠点は、特に大量のデータの場合、ガベージ コレクション中に長時間停止することです。

パラレルCG

並列ガベージ コレクター (Parallel CG) は、シーケンシャル コンストラクターに似ています。これには、一部のタスクの並列処理と、パフォーマンス設定を自動的に調整する機能が含まれます。Parallel GC は、Serial GC のアイデアに基づいた Java 仮想マシンのガベージ コレクターですが、並列処理とインテリジェンスが追加されています。コンピューターに複数のプロセッサ コアがある場合、古いバージョンの JVM は自動的に並列 GC を選択します。ここでのヒープは、シリアル GC と同じ領域 (Eden、Survivor 0、Survivor 1、および Old Gen (Tenured)) に分割されます。ただし、複数のスレッドが並行してガベージ コレクションに参加するため、コレクターは必要なパフォーマンス パラメーターに合わせて調整できます。各コレクター スレッドには、クリアする必要があるメモリ領域があります。並列 GC には、必要なガベージ コレクション効率を達成することを目的とした設定もあります。コレクターは、以前のガベージ コレクションの統計を使用して、今後のコレクションのパフォーマンス設定を調整します。並列 GC では、パフォーマンス パラメーターが自動調整され、ビルドの一時停止時間が短縮されますが、メモリの断片化という小さな欠点が 1 つあります。これはほとんどのアプリケーションに適していますが、より複雑なプログラムの場合は、より高度なガベージ コレクター実装を選択することをお勧めします。 長所: 多くの場合、シリアル GC よりも高速です。スピードが良い。短所: より多くのリソースを消費し、一時停止が非常に長くなる可能性がありますが、Stop-The-World の最大一時停止期間を調整できます。

同時マークスイープ

コンカレント マーク スイープ (CMS) ガベージ コレクターは、いくつかのガベージ コレクション タスクをアプリケーション スレッドと同時に実行することで、最大一時停止時間を短縮することを目的としています。このガベージ コレクターは、メモリ内の大量のデータを管理するのに適しています。同時マーク スイープ (CMS) は、Java 仮想マシン (JVM) における並列 GC の代替手段です。これは、複数のプロセッサ コアへのアクセスが必要で、Stop-The-World の一時停止の影響を受けやすいアプリケーションを対象としています。CMS はメイン プログラムと並行してガベージ コレクション ステップを実行するため、停止することなく実行できます。シリアル コレクターおよびパラレル コレクターと同じメモリ構成を使用しますが、古い世代のパージを実行する前に Tenured 領域がいっぱいになるのを待ちません。代わりに、バックグラウンドで実行され、Tenured 領域をコンパクトに保とうとします。同時マーク スイープは、アプリケーションのメイン スレッドを一時的に停止し、ルートからアクセス可能なすべてのオブジェクトをマークする初期マーキング フェーズから始まります。その後、アプリケーションのメイン スレッドが再開され、CMS は、マークされたルート オブジェクトからのリンクによってアクセスできるすべてのアクティブ オブジェクトの検索を開始します。すべての生きているオブジェクトをマークした後、コレクターはいくつかの並列スレッドで死んだオブジェクトのメモリをクリアします。CMS の利点の 1 つは、多くのアプリケーションにとって重要なダウンタイムの最小化に重点が置かれていることです。ただし、CPU リソースと全体的な帯域幅の点で犠牲が必要になります。さらに、CMS は古い世代のオブジェクトを圧縮しないため、断片化が発生します。パラレル モードの障害の可能性による長時間の一時停止は、不快な驚きとなる可能性があります (ただし、頻繁に発生するわけではありません)。十分なメモリがある場合、CMS はそのような一時停止を回避できます。 長所: 速い。ストップ・ザ・ワールドの短い一時停止があります。短所: より多くのメモリを消費します。メモリが不十分な場合、一時停止が長くなる可能性があります。アプリケーションが大量のオブジェクトを作成する場合はあまり良くありません。

ガベージファースト

Garbage-First (G1) は、特にマルチプロセッサ サーバー上で実行され、大規模なデータ セットを管理するサーバー アプリケーションにとって、CMS の代替手段と考えられています。G1 ガベージ コレクターは、巨大な領域 (巨大なオブジェクトを収容するために通常の領域を結合することによって作成される) を除き、メモリを複数の同じサイズの領域に変換します。リージョンは連続して編成される必要はなく、世代の所属を変更できます。若い世代に対して小規模なパージが定期的に実行され、オブジェクトが Survivor リージョンに移動されるか、オブジェクトが古い世代にアップグレードされて Tenured に転送されます。洗浄は、必要な時間を超えないようにする必要がある領域でのみ実行されます。回収員自らがゴミの量が多い地域を予測して清掃対象地域を選択します。フル スイープでは、マーキング ループを使用して、メイン アプリケーションと並行して実行されるライブ オブジェクトのリストを作成します。マーキング サイクルの後、G1 は混合パージの実行に切り替わります。これにより、パージされる若い世代の領域のセットに古い世代の領域が追加されます。G1 ガベージ コレクターは、一時停止サイズの予測において CMS コレクターよりも正確であると考えられており、特にヒープ サイズが大きい場合に、アプリケーションの長いダウンタイムを防ぐために、時間の経過とともにガベージ コレクションを適切に分散します。また、CMS コレクターのようにメモリを断片化することもありません。ただし、G1 コレクターはメイン プログラムと並行して実行するためにより多くの CPU リソースを必要とするため、アプリケーションのスループットが低下します。 長所: CMS よりも効果的です。休止時間が短くなります。短所: CPU リソースをより多く消費します。また、非常に大きなオブジェクト (500 KB 以上) が多数ある場合、そのようなオブジェクトは 1 つの領域 (1 ～ 32 MB) に配置されるため、より多くのメモリを消費します。

イプシロン GC

Epsilon GC は、ガベージ コレクションが必要ない状況向けに設計されています。ガベージ コレクションは実行されませんが、TLAB (スレッド ローカル割り当てバッファ) を使用して新しいオブジェクト、つまりヒープから個々のスレッドによって要求される小さなメモリ バッファを割り当てます。バッファに収まらない巨大なオブジェクトは、それ自身専用のメモリ ブロックを要求します。Epsilon GC のリソースがなくなると、OutOfMemoryError が生成され、プロセスが終了します。Epsilon GC の利点には、起動時に必要なすべてのオブジェクトを作成するアプリケーションや、割り当てられたメモリをすべて使用しない短期間のアプリケーションを実行するアプリケーションのリソース要件が低くなり、メモリ割り当てが高速化されることが含まれます。Epsilon GC は、他のガベージ コレクターがアプリケーションに追加するリソース要件の分析にも役立ちます。 長所: 非常に速い。短所: オブジェクトをクリアしません :) 次の 2 つのコレクターは、その種のコレクターの中で最も高度なものですが、最も複雑でもあります。したがって、それらについて簡単に検討します。

ZGC

ZGC は、大量のデータを処理する場合でも、ミリ秒未満の遅延を維持できます。ZGC は、Oracle が Java 用に開発したガベージ コレクターで、大規模なヒープ (最大 16 TB) を処理するときに高スループットと低遅延を実現するように設計されています。ZGC は仮想メモリの原理に基づいており、ガベージ コレクション中にさまざまな色のマーキングを使用してオブジェクトの状態を追跡します。 長所: 一時停止は、大規模なヒープであっても 1 ミリ秒未満であるため、短いクエリ処理時間を必要とするアプリケーションには非常に役立ちます。非常に大きなヒープでも良好なスループットで動作します。ZGC はガベージ コレクション中にヒープ メモリを圧縮する可能性があります。短所: CPU 使用率が高く、パフォーマンス要件が重要であるため、アプリケーションの起動時間が遅くなる可能性があります。

シェナンドーGC

Shenandoah GC も、ヒープ サイズに関係なく一時停止が短いガベージ コレクターです。このガベージ コレクターは Red Hat によって開発されました。アプリケーションがガベージ コレクションに費やす時間を最小限に抑えるように設計されています。ZGC と同様に、これは並列コレクターです。つまり、アプリケーションの実行中に実行され、一時停止が最小限に抑えられます。Shenandoah GC は、ガベージ コレクション中に「転送ポインター」を使用してオブジェクトを移動します。パフォーマンスを向上させるための「ロードバリア除去」と呼ばれる技術もあります。 長所: Shenandoah GC は、大規模なヒープであっても、短い一時停止時間を実現できます (多くの場合 10 ミリ秒未満)。良好なスループット。短所: プロセッサの負荷が高く、高負荷下での作業が困難です。

結論

ガベージ コレクターは、プログラミングの中で最も難しいタスクの 1 つです。この方向に向けて新たな開発が常に行われています。プログラマーが GC を微調整することはまれですが、ガベージ コレクション ツールがどのように機能するかについて少なくともある程度の知識は必要です。