不十分なヒープ領域に関連する例外がスローされたときに、Java Xmx メモリ制限を増やしました。ただし、現在、メモリに関連している可能性がある非常に長い実行時間が発生していますが、例外がスローされたことはありません (まだ)。
長い実行時間の原因が何であるか疑問に思っています。JVM はヒープをディスクにスワップしますか?
HotSpot 1.6.0 update 34 を使用しています。
不十分なヒープ領域に関連する例外がスローされたときに、Java Xmx メモリ制限を増やしました。ただし、現在、メモリに関連している可能性がある非常に長い実行時間が発生していますが、例外がスローされたことはありません (まだ)。
長い実行時間の原因が何であるか疑問に思っています。JVM はヒープをディスクにスワップしますか?
HotSpot 1.6.0 update 34 を使用しています。
JVM はディスクにスワップしません。オペレーティング システムがそうする場合があります。これは、プロセスの OS 統計をチェックすることで検出できます。
JVM がメモリ不足になると、ガベージ コレクションが頻繁にトリガーされます。実行ごとに解放されるメモリが少なくなり、GC の速度がさらに向上します。最終的には、GC に多くの時間が費やされます。
JVM は、0 バイトが解放されて throw されるまで待機しませんOutOfMemoryError
。解放されたバイト数に対して GC に時間がかかりすぎると、実際にはあきらめます。
ヒープが大きくなると考えられる結果の 1 つは、GC 時間の増加です。JVM はより大きなスペースを分析する必要があるため、特にストップ・ザ・ワールド GC の場合は時間がかかります。
質問を少し具体化できますか?
どのヒープサイズを使用していますか? どのくらいの期間が表示されますか? アプリケーション内のオブジェクトの使用パターンは? たとえば、寿命の長いオブジェクトがいくつかある場合や、寿命の短いオブジェクトが多数ある場合などです。