（「JVM」と言うときは、実際には「ホットスポット」を意味し、最新のJava 1.6アップデートを実行していることに注意してください。）
状況の例：
私のJVMは、-Xmxを1GBに設定して実行しています。現在、ヒープには500mbが割り当てられており、そのうち450mbが使用されています。プログラムは、ヒープにさらに200mbをロードする必要があります。現在、ヒープには300mb相当の「収集可能な」ゴミがあります（すべてが最も古い世代であると想定します）。
通常の操作では、JVMはヒープを700 mb程度に拡張し、それに近づくとガベージコレクションを実行します。
そのような状況で私が望むのは、JVMが最初にgcを実行し、次に新しいものを割り当てることです。これにより、ヒープサイズは500mbのままになり、使用されるヒープは350mbになります。
それを行うJVMパラメータコンボはありますか？
ヒープの拡張と縮小を指定-XX:MinHeapFreeRatioして制御してみてください。-XX:MaxHeapFreeRatio
-XX:MinHeapFreeRatio-世代内の空き領域の割合がこの値を下回ると、世代はこの割合を満たすように拡張されます。デフォルトは40です。-XX:MaxHeapFreeRatio-世代内の空き領域の割合がこの値を超えると、世代はこの値を満たすように縮小します。デフォルトは70です。を指定して、並行GCを試すこともできます-XX:+UseConcMarkSweepGC。アプリケーションによっては、追加のCPUサイクルを犠牲にして、ヒープサイズを低く保つことができます。
それ以外の場合、JVMは、最適なときに使用可能として指定したメモリを使用します。封じ込めを維持するように少量を指定する-Xmx768mと、正常に実行される可能性がありますが、高負荷のシナリオでメモリが不足するリスクが高まります。全体的に少ないメモリを使用する唯一の方法は、実際には少ないメモリを使用するコードを書くことです:)
Java 15 の更新により、さらに 2 つのコレクターが追加されました。関連するオプションの一部は次のZGCとおりです。
-XX:+UseZGCZGC を有効にする-XX:+ZProactive両方とも-XX:+ZUncommitデフォルトで有効になっています。ZGC は、ガベージ オブジェクトを解放し、解放されたメモリを OS に解放しようと積極的に試みます。残りのオプションは、それがどれほど積極的に行われるかを微調整します。-XX:ZCollectionInterval=secondsGC の実行頻度。ガベージができるだけ早くクリーンアップされるようにするには、数秒に設定します。(デフォルトでは 0 です。つまり、GC が実行される保証はありません。)-XX:ZUncommitDelay=secondsヒープ メモリがコミット解除されるまでに使用されていなければならない時間 (秒単位) を設定します。デフォルトでは、このオプションは 300 (5 分) に設定されています。低い値を設定すると、メモリをより迅速に取り戻すことができます-XX:SoftMaxHeapSizeアプリケーションがこの制限よりも多くのメモリを使用するたびに、GC がより頻繁に起動します。（これはおそらくOPが探している答えです。）-XX:SoftRefLRUPolicyMSPerMBこのオプションがどのくらいの頻度で関連するかはわかりませんが、キャッシュされたオブジェクトがメモリに保持される期間を制御します。元の回答HotSpot には 4 つ (実際には 5 つ) の異なるガベージ コレクターがあり、オプションはそれぞれ異なります。
-XX:MinHeapFreeRatioとがあり-XX:MaxHeapFreeRatio、動作を多かれ少なかれ直接制御できます。ただし、シリアルコレクターの経験はあまりありません。-XX:+UseParallelOldGC) には-XX:MaxGCPauseMillis=<millis>とがあり-XX:GCTimeRatio=<N>ます。通常、最大休止時間を短く設定すると、コレクターはヒープを小さくします。ただし、一時停止時間がすでに小さい場合、ヒープは小さくなりません。OTOH、最大一時停止時間の設定が低すぎると、アプリケーションはすべての時間を収集に費やす可能性があります。より低い gc 時間比率を設定すると、一般にヒープも小さくなります。より小さなヒープと引き換えに、より多くの CPU 時間をコレクションに割り当てても構わないと思っていることを gc に伝えています。ただし、これはヒントであり、効果がない場合もあります。私の意見では、ヒープのサイズを最小化する目的で、並列コレクターはほとんど調整不可能です。このコレクターは、しばらく実行してアプリケーションの動作が一定に保たれると、より適切に機能します (それ自体が調整されます)。-XX:+UseConcMarkSweepGC) は通常、一時停止時間を短くするという主な目標を達成するために、より大きなヒープを必要とするため、ここでは説明しません。-XX:+UseG1GC) は、古いコレクターほど脳死状態ではありません。それ自体でより小さいヒープ サイズを選択することがわかりました。私はそれらを研究し始めたばかりですが、多くのチューニングオプションがあります。-XX:InitiatingHeapOccupancyPercent、-XX:G1HeapWastePercent、-XX:G1ReservePercentおよび-XX:G1MaxNewSizePercent興味があるかもしれません。通常どおり、追加の200MBのオブジェクトを割り当てる前にメソッドを呼び出すことができSystem.gc()ますが、これは、JVMが従うことができる、または従うことができないというヒントにすぎず、いずれの場合も、これがいつ行われるかはわかりません。それはベストエフォートのリクエストです。
ちなみに、ガベージコレクションは重い操作であるため、特に必要がない場合は、強制しないでください。
知っておくべきこと：設定-Xmx1Gすると、1GBがヒープの最大スペースであることをJVMに伝えます。これを指定しているので、1GBがまだ大丈夫です（私たちはメモリ管理言語のコンテキストにいます）。ヒープをそれほど増やしたくない場合は、最大値を減らして、新しいオブジェクトを割り当てる前に強制的にGCを実行するようにします。そうでない場合は、なぜ1GBを使用するように指示するのでしょうか。
ここで覗いてみるのをお勧めします：