0

JVM を起動すると、少なくとも {{xms}} メモリが予約されますよね? つまり、このメモリは JVM プロセス専用です (malloc されます)。JVM がヒープを増やす必要がある場合、より多くのメモリを予約 (malloc) します。しかし、いくらですか？おそらく、特定のステップ（プール？）のサイズがあります。

この「ステップ サイズ」はどのように設定できますか?

そして、{{xmx}} に到達して OOM がスローされるまで、すべてが発生しますよね?

JVM はいつ GC を開始しますか? xmx に関してではなく、予約されたヒープ サイズ (このプールのトップ) に関しては?

もしそうなら、多くの無駄な GC を防ぐために、xms を xmx の近くに設定する方がずっと良いです。小さな GC ではなく 1 つの巨大な GC を使用します。GC ごとに JVM がフリーズするというバグがあるため、1 つ使用した方がよいのではないでしょうか?

4

2 に答える 2

5

JVM がヒープを増やす必要がある場合、より多くのメモリを予約 (malloc) します。しかし、いくらですか？

あなたは本当に気にするべきではありません。それはうまくいきます。equal Xmxandを使用Xmsして、JVM が起動時にすべてのメモリを割り当てるようにするための多くのアドバイス。これは合理的です。さらに読んでください。

この「ステップ サイズ」はどのように設定できますか?

できません。完全に実装であり、おそらく OS に依存します。

JVM はいつ GC を開始しますか? xmx に関してではなく、予約されたヒープ サイズ (このプールのトップ) に関しては?

GC は、あなたが思っているよりも少し複雑です。若い世代がいっぱいになると、マイナー GC が実行されます。メジャー GC は、古い世代でこれ以上スペースが残っていないと呼ばれます。

そして、{{xmx}} に到達して OOM がスローされるまで、すべてが発生しますよね?

いいえ、にXmx達すると、JVM は安定し、何も問題は発生しません。OutOfMemoryErrorGC の直後に、JVM が新しいオブジェクト用の十分なスペースを見つけられない場合にスローされます (これは大幅な簡略化です)。

もしそうなら、多くの無駄な GC を防ぐために、xms を xmx の近くに設定する方がずっと良いです。

ここでも、GC の仕組みを学ぶ必要があります。Xmxequal toを使用するXmsと、アプリケーションの実行時に不要な割り当てが回避されるため、適切な選択です (すべてが起動時に行われ、それ以上のオーバーヘッドはありません)。GCはそれとは何の関係もありません。

多くの小さなものではなく、バグごとに GC が JVM をフリーズさせるので、1 つ持っている方が良いですよね?

いいえ。マイナー GC は通常、数十ミリ秒かかり、リアルタイム システムで作業していない限り、ほとんど見えません。主要な (stop-the-world) GC には数秒かかる場合があり、エンド ユーザーにとっては確実に目立ちます。正しくチューニングされた JVM では、主要な GC はほとんど発生しません。

于 2012-07-26T20:05:08.383 に答える
0

あなたはスイッチの意味について正しいです。

私がスイッチを覚えている方法は

xm * s * = "* s *tartingmemory"のように"s"で終わります。

xm * x * = "ma * x *imummemory "のように"x"で終わる

開始メモリから最大メモリに移動する方法を決定するのは、特定のJVM次第です。2つが互いに自明に接近していないと仮定すると、割り当ては、私が知っているすべてのJVMで段階的に行われます。

JVMのステップのサイズを制御するオプションを知りません。確かに標準的なオプションはありません。

JVMが異なれば、GC戦略も異なります。一部のJVMでは、コマンドラインスイッチによって制御される複数のGC戦略の1つを使用できます。

于 2012-07-26T20:03:57.637 に答える