面接官にガベージコレクションについて説明した方法

[[356806]]

この記事はWeChatの公開アカウント「Learn Java in Hometown」から転載したもので、著者はLearning Java in Hometownです。この記事を転載する場合は、地元Java学習公開アカウントまでご連絡ください。

ガベージコレクションのメカニズムとは何ですか?なぜガベージコレクションのメカニズムを学ぶ必要があるのでしょうか?今日は、これら 2 つの質問を一緒に見ていきます。

私たちの日常的な開発プロセスでは、オブジェクトのリサイクルとリリースにあまり注意を払っていません。 JVM はガベージ コレクションを完了し、作業負荷を大幅に軽減するのに役立ちます。ガベージコレクションは私たちにとって遠い存在のようです。実は、ガベージコレクションの仕組みは、初級から中級、上級の開発まで習得しなければならないものなのです。オブジェクトのリサイクルのタスクを JVM に完全に引き渡すと自由になるように見えますが、実際には不確実性が増します。物事はいつも完璧というわけではありません。今日のさまざまな複雑なビジネス シナリオでは、不適切なガベージ コレクション アルゴリズムと戦略が、システム パフォーマンスのボトルネックの主な原因となることがよくあります。

ガベージコレクションは一般化できません。ビジネスシナリオに応じて異なる対策を講じる必要があります。ビジネス シナリオでメモリに対する要件が高い場合は、オブジェクトのリサイクル効率を向上させる必要があります。 CPU 使用率が高い場合は、ガベージ コレクションの頻度を減らす必要があります。

JVM のメモリには複数の領域があることは誰もが知っています。ガベージ コレクションは主にヒープとメソッド領域のメモリを調べます。プログラム カウンター、仮想マシン スタック、ローカル メソッド スタックなどの他の領域のメモリは決定論的であるため、ヒープ内のオブジェクトの回復とメソッド領域内の放棄された定数の回復に重点を置く必要があります。

JVM はオブジェクトがリサイクル可能かどうかをどのように判断するのでしょうか?

ガベージ コレクションに初めて触れたとき、オブジェクトは参照されていない場合にリサイクルできると聞いたことがあるはずです。ただし、オブジェクトが参照されているかどうかを判断する主な方法は、参照カウント アルゴリズムと到達可能性分析アルゴリズムの 2 つです。

**参照カウント アルゴリズム: **いわゆる参照カウント アルゴリズムは、オブジェクトの参照カウンターを使用して、オブジェクトが参照されているかどうかを判断するものです。オブジェクトが参照されると、カウンターは 1 増加し、参照無効化カウンターは 1 減少します。カウンター値が 0 の場合、オブジェクトは参照されておらず、JVM によってリサイクルできることを意味します。参照カウント アルゴリズムは実装が簡単ですが、循環参照の問題が発生する可能性があることに注意してください。

**到達可能性分析アルゴリズム: **到達可能性分析アルゴリズムの基礎は、すべてのオブジェクトのルート オブジェクトである GC ルートです。 JVM がロードされると、通常のオブジェクトを参照するためにいくつかのオブジェクトが作成されます。これらのオブジェクトは、これらの通常のオブジェクトの開始点として機能します。ガベージ コレクション中、JVM は GC ルートから下方向に検索します。オブジェクトに GC ルートに接続する参照チェーンがない場合、そのオブジェクトはリサイクル可能であることが証明されます。

ガベージ コレクション スレッドはオブジェクトをどのようにリサイクルしますか?

JVM は主に、自動性と予測不可能性という 2 つの特性に従ってオブジェクトを再利用します。

**自動化: **JVM は、割り当てられた各メモリを追跡するためのシステム レベルのスレッドを作成します。 JVM がアイドル状態のとき、割り当てられた各メモリ領域を自動的にチェックし、各メモリを自動的にリサイクルします。

**予測不可能性: **予測不可能性は主に、オブジェクトが参照されていない場合にすぐにリサイクルされるかどうかを指します。答えは不明です。すぐにリサイクルされる場合もありますが、長期間メモリ内に残る場合もあります。

GCアルゴリズム

JVM は、リサイクル メカニズムを実装するためのさまざまなリサイクル アルゴリズムを提供します。一般的に言えば、市販されている一般的なガベージコレクターのリサイクルアルゴリズムは、主に次の 4 つのカテゴリに分類されます。

マークスイープ

利点: オブジェクトを移動する必要がなく、シンプルで効率的

OK: マークアンドスイープのプロセスは非効率であり、メモリの断片化を引き起こす可能性があります。

コピーアルゴリズム

利点: シンプルで効率的、メモリの断片化がない

デメリット: メモリ使用量が少なく、コピーの問題が頻繁に発生する可能性があります。

マークコンパクト

利点: オブジェクトを移動する必要がない、高効率、メモリの断片化がない

デメリット: ローカルオブジェクトを移動する必要がある

世代別コレクションアルゴリズム

利点: パーティションのリサイクル

デメリット: 長寿命物体のリサイクル効果はあまり良くありません。

4 つのガベージ コレクターのリサイクル アルゴリズムを理解した後、これらのアルゴリズムに基づいて実装されたコレクターを確認し、一般的なコレクターをいくつか簡単に紹介します。

GC パフォーマンスを測定するための標準は何ですか?

ガベージ コレクターにはさまざまな種類があり、コレクターごとに適切なシナリオが異なります。適切なガベージ コレクターを選択する方法は、主に、ガベージ コレクターの 3 つの指標 (スループット、停止時間、ガベージ コレクションの頻度) によって決まります。

**スループット:** は、システム アプリケーションが費やした時間とシステム全体の実行時間の比率を指します。 GC スループット = GC 時間 / システムの合計実行時間。 GC スループットは通常 95% 以上です。

**スタッター時間:**スタッター時間とは、ガベージ コレクターが動作しているときにアプリケーションが一時停止される時間です。一般的に、シリアル コレクターはストール時間が長くなりますが、コンカレント コレクターはコレクターとアプリケーションが交互に実行されるためストール時間が短くなりますが、効率はシリアルほど良くなく、システム スループットが低下します。

**ガベージ コレクションの頻度: **ガベージ コレクションの頻度の時間と遅延時間は相互に影響します。メモリを増やすことでガベージコレクションの頻度を減らすことができますが、メモリが増えると蓄積されるオブジェクトが増え、ガベージコレクションが発生したときの遅延時間が増加します。したがって、ガベージコレクションの正常な頻度を確保するには、メモリの増加の度合いを把握する必要があります。

GC ログを表示および分析するにはどうすればよいですか?

冒頭にナンセンスなことが沢山あるので、読むのに飽きた兄弟も多いと思います。次に、GC ログを収集し、GC ログを分析する方法を見てみましょう。 GC ログを設定するには JVM パラメータが必要です。次のパラメータに注意する必要があります。

 -XX:+PrintGC # GCログを出力する
-XX:+PrintGCDetails # 詳細なGCログを出力します
-XX:+PrintGCTimeStamps #GCタイムスタンプを出力します（ベースタイムの形式で）
 -XX:+PrintGCDateStamps #GCタイムスタンプを出力します（日付形式、例：2020-12-08T23:59:59.234+0800）
 -XX:+PrintHeapAtGC #GC の前後のヒープ情報を出力します
-Xloggc:../logs/gc.log #ログファイルの出力パス

必要に応じてパラメータを設定することができ、印刷されたログは次のようになります。

メモ帳を使用して、非常に短い GC ログを表示できます。長い GC ログを分析したい場合、メモ帳で開くのは少し難しいでしょう。それを分析するにはツールを使用する必要があります。通常、GCViewer を使用してログ ファイルを開き、GC パフォーマンスをグラフィカルに表示できます。このツールを使用すると、スループット、ストール時間、GC 頻度を確認し、GC のパフォーマンスを直感的に確認できます。

GCeasy も優れた GC ログ分析ツールです。オンライン分析を行うには、ログ ファイルを圧縮して公式 Web サイトにアップロードするだけです。以下は、ローカル GC ログを分析した結果です。

GC チューニング

GC ログを分析することで、パフォーマンスに影響を与える問題を見つけることができます。次に、ターゲットを絞ったチューニングを実行する必要があります。ここでは、主にマイナー GC とフル GCd の頻度を減らすためのいくつかの一般的なチューニング戦略を簡単に紹介します。

マイナーGCの頻度を減らす

まず、マイナーGCは主にエデンエリアのオブジェクトの回収を目的としています。新しい世代のスペースは一般的に小さいため、Eden 領域はすぐにいっぱいになり、マイナー GC の頻度が高くなります。私たちの解決策は通常、新しい世代のスペースを増やしてマイナー GC の頻度を減らすことです。先ほど GC パフォーマンス指標の測定について説明しましたが、メモリを増やすとリサイクル中の待ち時間が長くなることを述べました。マイナー GC によってアプリケーションがフリーズする可能性もありますが、その時間は非常に短いです。したがって、Eden エリアの拡張によってマイナー GC の時間が長くなるかどうかは、マイナー GC で何が起こるかを詳しく調べる必要があります。

各マイナー GC は主に、新しい世代のスキャン (A) と、生き残ったオブジェクトのコピー (B) という 2 つの処理を実行します。オブジェクトのコピーにかかる時間は、オブジェクトのスキャンにかかる時間よりもはるかに長くなります。例を見てみましょう。オブジェクトがエデン領域に 500 ミリ秒間存続し、マイナー GC の頻度が 300 ミリ秒ごとに 1 回の場合、通常の状況では、マイナー GC で使用される時間は A+B 時間になります。今回は、GC ログ分析を通じて Eden を拡張し、マイナー GC の前に 600 ミリ秒にします。この時点で、オブジェクトはエデン領域でリサイクルされているため、オブジェクトをコピーする必要がなく、生き残ったオブジェクトをコピーする時間を節約できます。このマイナー GC では、新しい世代をスキャンする時間のみが増加します。

要約: 単一のマイナー GC の時間は、Eden 領域のサイズではなく、GC 後に存続するオブジェクトの数によって決まります。ヒープメモリ内に比較的長い生存時間を持つオブジェクトが多数ある場合、若い世代のスペースを増やすと、単一のマイナー GC の時間が増加します。ヒープ メモリ内に短命のオブジェクトが多数存在する場合、拡張後、単一のマイナー GC の時間は大幅に増加せず、マイナー GC の頻度は減少します。

フルGCの頻度を減らす

Full GC のトリガーは通常、ヒープ メモリ領域が不十分であるか、古い世代のオブジェクトが多すぎることが原因で発生します。フル GC によりコンテキストの切り替えが発生します。コンテキスト切り替えについては、前回の記事ですでに紹介しました。コンテキストの切り替えによってシステムのパフォーマンスが低下することは誰もが知っています。以下の方法により、Full GC の頻度を減らすことができます。

大きなオブジェクトの作成を減らす: 場合によっては、プログラミングの習慣により、トラブルを回避するために、Web 上に表示するために一度に大きなオブジェクトがデータベースから照会されることがあります。この大きなオブジェクトは、古い世代に直接作成されます。新しい世代に作成された場合でも、新しい世代のスペースは一般的に非常に小さいため、マイナー GC 後に古い世代に入ります。このような大きなオブジェクトが大量に蓄積されると、Full GC がトリガーされます。したがって、良い習慣を身につけ、不要なフィールドのクエリを減らすことが依然として必要です。

メモリ領域を増やす: ヒープ メモリが不足している場合は、ヒープ メモリ領域を直接増やし、初期化メモリ領域を最大ヒープ メモリ領域に設定します。これにより、Full GC の頻度を大幅に削減できます。

適切なGCコレクター：上記ではさまざまなコレクターを紹介しました。当社のビジネス シナリオによれば、適切なコレクターを選択すると、多くの場合、良い結果が得られます。

要約する

ゴミのリサイクルは継続的な実践を必要とする複雑な科学です。この記事を読んだ後、ガベージ コレクションについてある程度理解しているはずです。すぐに行動を起こして、まずは社内の開発環境で実践してみましょう。