java - Java - ガベージ コレクション

Question

メソッド呼び出しSystem.gc()が、ガベージ コレクター アルゴリズムがその時点で実行されることを保証しないのはなぜですか? 呼び出されるたびに、未使用のオブジェクトのすべてのメモリを確実に再利用できないのはなぜですか?

Answer 1

1. オブジェクトの破棄を強制することはコーディングが悪いことを示しているため、Java は開発者がオブジェクトの破棄に夢中になるのを避けたいと考えているのかもしれません。
2. Java でオブジェクトの破棄を強制できる場合、Java を不適切に使用すると、アプリケーションのパフォーマンスに悪影響を及ぼす可能性があります。
3. この制限により、メモリ管理よりもビジネス ロジックにより多くの焦点を当てることができます (強制されます)。
4. JVM は、メモリ管理が必要な時期とその方法を決定するのに最適な人物です。
5. JVM を信頼して、私たちよりも優れた方法で物事を処理させることができます (すべきです)。
6. それでも、オブジェクトの破棄を強制しますか? はいの場合、なぜですか?

Answer 2

プログラムがJVM内でスムーズに実行されるようにするために、JVM自体がガベージコレクションを管理します。ガベージコレクションは非常に洗練されています。システムにGCの実行を依頼するとき、どのアルゴリズムを期待していますか？「フルGC」？複数のヒープもあります。気になるゴミはどれですか？あなたは知りません、そしてこの方法は示しません。

呼び出しSystem.gc()が常に完全なGCをトリガーしたと仮定します。誤ったプログラムは、JVMのパフォーマンスを簡単に停止させる可能性があります。防御的に、JVMはそのような呼び出しに応答する頻度を制限したいと思うでしょう。

非組み込みシステム（サーバーやデスクトップコンピューターなど）のJVMで実行している場合は、メモリ管理の監視とコード化以外の側面について心配する必要はありません。

Answer 3

ガベージ コレクターのパフォーマンスを評価するために使用されるメトリックがいくつかあります。その一部を次に示します。

• スループット: ガベージ コレクションに費やされなかった合計時間の割合。長期間にわたって考慮されます。
• ガベージ コレクションのオーバーヘッド— スループットの逆数、つまり、ガベージ コレクションに費やされた合計時間の割合。
• 一時停止時間- ガベージ コレクションの実行中にアプリケーションの実行が停止される時間の長さ。
• 収集の頻度 :アプリケーションの実行に対する収集の頻度。
• フットプリント— ヒープ サイズなどのサイズの尺度。
• 迅速性 :オブジェクトがガベージになってからメモリが使用可能になるまでの時間。

JVM がSystem.gc()良いペットのようにリッスンし、呼び出しごとにアクションを実行することを保証するSystem.gc()場合、プログラム内で何度も呼び出された場合のアプリケーションのパフォーマンスを想像してみてください.!!??

1. スループットが低下します
2. ガベージ コレクションのオーバーヘッドが増加します。
3. アプリケーションは、メモリの再収集でビジー状態になるため、何度も一時停止します。
4. フットプリントが大きい場合、ガベージ コレクターは、ガベージ コレクションの対象となるオブジェクトがあるかどうかに関係なく、メモリを回復するためにすべてのメモリ領域をスキャンする必要があります。

System.gcしたがって、これらの点を調べた後、JVMがアプリケーションの選択ではなく、独自のアルゴリズムに応答する十分な理由が得られると思います。また、ガベージ コレクションはすべての未使用のオブジェクトのメモリを確実に再利用しますが、その呼び出しは、ユーザーの選択ではなく、JVM 独自のアルゴリズムに完全に依存しています。

出典: Java HotSpot™ 仮想マシンのメモリー管理 - Sun Microsystems

Answer 4

呼び出されるたびに、未使用のオブジェクトのメモリをすべて再利用することはできません。

あなたのこの仮定は誤りです。ほとんどの場合、ガベージ コレクターは未使用のオブジェクトをいつでもすべて回収できます。ただし、標準の Java ライブラリがそれを保証するメソッドを提供した場合、ほとんどの場合役に立たず、損害を与える可能性さえあるサービスを提供するために、GC サブシステムに完全に不当な負担がかかることになります。