-Xmx を使用して、Java VM の Java ヒープ領域に可能な最大メモリを設定できます。-Xmx1g.
優先順位が java OutOfMemoryError ヒープ領域が発生しないことである場合、なぜ -Xmx をある値よりも低く設定したいのでしょうか? 最大値が低いほど、VM はより効率的にメモリを管理しますか?
私は常に OutOfMemoryError に遭遇し、-Xmx を非常に高く設定しました。問題は、最終的には物理メモリも使い果たしてしまうことです。そのため、高い Xmx だけでは十分ではありません。私の現在の解決策は、メモリを大量に消費するアプリケーションをシャットダウンすることです。これは、開発とテストが遅くなるため非常に不便です。
-Xms パラメーターと -Xmx パラメーターは、それぞれ最小ヒープ サイズと最大ヒープ サイズを定義します。
世代がいっぱいになると GC が発生するため、スループットは使用可能なメモリの量に反比例します。
デフォルトでは、JVM は各 GC でヒープを拡大または縮小して、各コレクションで生きているオブジェクトに対する空き領域の割合を特定の範囲内に維持しようとします。この範囲は、パラメーター -XX:MinHeapFreeRatio=minimum および -XX:MaxHeapFreeRatio=maximum によってパーセンテージとして設定されます。および -Xms と -Xmx によって制限される合計サイズ。
Glassfish のチューニング用に Oracle サイトで利用できる Java ヒープ サイズのガイドラインがいくつかありますが、どの JVM にも当てはまります。
http://docs.oracle.com/cd/E18930_01/html/821-2431/abeic.html#abeij
IBM のトラブルシューティング ガイドでは、最小ヒープ使用量を約 40%、最大ヒープ使用量を約 70% とするアプリケーション固有のヒープ使用量を目標とすることを推奨しています。
最大値が低いほど、VM はより効率的にメモリを管理しますか?
おそらく、ヒープ サイズのオブジェクトを過剰に割り当てないことで、より正確に正しいメモリ ジェネレーションに「記入」されます。これは、ヒープ サイズが大きいほど GC が実行されにくくなるためです。つまり、より多くのオブジェクトが若い世代に長く留まり、より高速なガベージ コレクションが提供されます。メモリ使用量を 2 倍にする代償。
追加のオーバーヘッドは見られませんが、アプリケーションがメモリ不足の原因であり、最大メモリ割り当てが高いことが原因であり、メモリに大きなオブジェクトが格納されているか、メモリリークが発生している可能性が最も高いです。ヒープ管理よりも差し迫った問題であるアプリケーション。
http://docs.oracle.com/javame/config/cdc/cdc-opt-impl/ojmeec/1.1/custom/html/tuning.htm
memoru が大きい場合は、GC を実行する必要が少なくなり、GC がそれだけの余裕を持ってリラックスできるため、ゴミが多くなる可能性があると思います。ただし、GC はより多くのメモリで動作する必要があるため、GC が遅くなる可能性があります。
JVM ヒープ サイズによって、VM がガベージ コレクションに費やす頻度と時間が決まります。ガベージ コレクションの許容レートはアプリケーション固有であり、ガベージ コレクションの実際の時間と頻度を分析した後に調整する必要があります。大きなヒープ サイズを設定すると、フル ガベージ コレクションは遅くなりますが、発生頻度は低くなります。メモリのニーズに応じてヒープ サイズを設定すると、フル ガベージ コレクションの方が高速ですが、より頻繁に発生します。