23

私の知る限り、GCがそのことを行っているとき、VMは実行中のすべてのスレッドをブロックします-または少なくともヒープを圧縮しているとき。これは、CLR と JVM の最新の実装(2010 年 1 月現在の製品バージョン) に当てはまりますか? 私は初歩的な仕組みを理解しているので、GC の基本的なリンクを提供しないでください。

コンパクションが発生すると参照が移動期間中に無効になる可能性があるため、グローバル ロックが該当すると思います。ヒープ全体をロックする (つまり、すべてのスレッドを間接的にブロックする) のが最も簡単なようです。より堅牢なメカニズムを想像することはできますが、多くの場合、KISS が優勢です。

私が間違っていれば、ブロックを最小限に抑えるために使用される戦略の簡単な説明によって私の質問に答えることができます. 私の推測が正しければ、次の 2 つの質問について洞察を提供してください。

  1. これが実際に動作する場合、JBOSS や Glassfish などの重量級のエンタープライズ エンジンはどのようにして一貫して高い TPS レートを維持するのでしょうか? 私は JBOSS でいくつかのグーグル検索を行い、Web 処理に適したメモリ アロケータのような APACHE で何かを見つけることを期待していました。

  2. NUMA 風のアーキテクチャ (おそらく近い将来) に直面すると、プロセスがスレッドとメモリ割り当てによってバインドされた CPU でない限り、これは惨事のように思えます。

4

6 に答える 6

16

答えは、これは使用されるガベージ コレクション アルゴリズムに依存するということです。場合によっては、GC 中にすべてのスレッドが停止することは正しいです。それ以外の場合は、通常のスレッドの実行中にガベージ コレクションが進行するという点で間違っています。GC がそれをどのように達成するかを理解するには、ガベージ コレクターの理論と用語を詳細に理解し、特定のコレクターを理解する必要があります。単純な説明では到底受け入れられません。

そうそう、多くの現代のコレクターは圧縮段階自体を持っていないことを指摘する価値があります。むしろ、ライブオブジェクトを新しい「スペース」にコピーし、完了時に古い「スペース」をゼロにすることによって機能します。

私が間違っていれば、ブロックを最小限に抑えるために使用される戦略の簡単な説明によって私の質問に答えることができます.

ガベージ コレクターがどのように機能するかを本当に理解したい場合は、次のことをお勧めします。

...そして、本番環境のガベージ コレクタの内部に関する正確で詳細な公開記述を見つけるのは簡単ではないことに注意してください。（Hotspot GCの場合はソースコードを見てもいいのですが…）

編集： OPのコメントに応えて...

「思った通りのようだ――『世界を止める』部分を回避することはできない」

場合によります。Java 6 Concurrent Collectorの場合、ルート (スタックを含む) のマーキング中に 2 つの一時停止があり、その後、他のオブジェクトのマーキング/コピーが並行して進行します。他の種類の並行コレクターの場合、コレクターの実行中に読み取りバリアまたは書き込みバリアを使用して、コレクターとアプリケーション スレッドが互いに干渉する状況をトラップします。[Jones] のコピーは今ここにありませんが、"stop the world" 間隔を無視できるようにすることも可能であることを思い出します...より高価なポインター操作やすべてを収集しないという犠牲を払ってごみ。

于 2010-01-18T11:59:33.480 に答える
2

ガベージ コレクターがすべてのアプリケーション スレッドを一時停止する必要があることは間違いありません。この一時停止時間は、アプリケーションを停止せずに一部の作業を実行する並行コレクターを使用することにより、Sun JVM で短縮できますが、アプリケーション スレッドを一時停止する必要があります。

ここhttp://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#par_gcとここhttp://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#cmsを参照してくださいSun JVM が最新の JVM でガベージ コレクションを管理する方法の詳細については、

Web アプリケーションの場合、これは問題ではないと思います。ユーザー要求は 1 秒未満の短い時間内に完了する必要があるため、サービスに割り当てられた一時オブジェクトは、非常に効率的にクリーンアップされる若い世代 (適切なサイズである場合) を終了してはなりません。ユーザー セッションなどのライフサイクルが長いその他のデータは、より長く残り、主要な GC イベントに費やされる時間に影響を与える可能性があります。

TPS の高いアプリケーションでは、セッション アフィニティと負荷分散を使用して、アプリケーション サーバーの複数のインスタンスを同じハードウェアまたは別のハードウェアで実行するのが一般的な戦略です。これにより、JVM ごとの個々のヒープ サイズが小さく保たれ、主要なコレクションを実行する際の GC の一時停止時間が短縮されます。一般に、アプリケーションや JVM ではなく、データベースがボトルネックになります。

J2EE の Web 固有のメモリ アロケータの概念に最も近いのは、フレームワークとアプリケーション サーバーによって実行されるオブジェクト/インスタンスのプーリングです。たとえば、JBOSS には EJB プールとデータベース接続プールがあります。ただし、これらのオブジェクトは通常、ガベージ コレクションのオーバーヘッドではなく作成コストが高いため、プールされます。

于 2010-01-18T12:40:39.860 に答える
1

IBM は、マルチコア システムでの GC パフォーマンスの改善に向けて、「すべてが停止する」問題を軽減または排除する作業を含む、いくつかの調査を行ったと思います。

例: サーバー向けの並列、増分および同時 GC(pdf)

または、「同時ガベージ コレクション ibm」のようなものをグーグルで検索します

于 2010-01-18T13:02:26.250 に答える
1

私の知る限り、GCがそのことを行っているとき、VMは実行中のすべてのスレッドをブロックします-または少なくともヒープを圧縮しているとき。これは、CLR と JVM の最新の実装 (2010 年 1 月現在の製品バージョン) に当てはまりますか?

Sun の Hotspot JVM と Microsoft の CLR の両方に、コレクション サイクル全体ではなく、短いフェーズ (すべてのライブ データに到達可能なグローバル ルートの自己一貫性のあるスナップショットを取得するため) のみ世界を停止する同時 GC があります。圧縮の実装についてはよくわかりませんが、それは非常にまれです。

これが実際に動作する場合、JBOSS や Glassfish などの重量級のエンタープライズ エンジンはどのようにして一貫して高い TPS レートを維持しているのでしょうか?

これらのエンジンの遅延は、世界を停止するのにかかる時間よりも桁違いに長くなります。また、レイテンシーは、たとえば 95 パーセンタイルとして引用されます。つまり、レイテンシーは、95% の時間だけ、引用された時間範囲を下回ります。したがって、圧縮が引用された待ち時間に影響を与える可能性はほとんどありません。

于 2010-08-17T13:41:11.630 に答える
0

Java で使用できる GC アルゴリズムは多数ありますが、そのすべてが実行中のすべてのスレッドをブロックするわけではありません。たとえば、アプリと同時に実行される -XX:+UseConcMarkSweepGC を使用できます (Tenured 世代の収集用)。

于 2010-01-18T11:49:11.960 に答える
0

Java の現在の最先端のガベージ コレクションには、時折の "stop the world" 一時停止が依然として含まれています。Java 6u14 で導入された G1 GC は、ほとんどの作業を並行して実行しますが、メモリが非常に少なく、ヒープを圧縮する必要がある場合、その下のヒープを誰もいじらないようにする必要があります。これには、他に何も続行できないことが必要です。G1 GC の詳細については、Sun のプレゼンテーションを参照してください。

于 2010-01-18T12:48:47.310 に答える