4

JVM によって使用される合計メモリ (Runtime.totalMemory()) が割り当て可能なメモリ (Runtime.maxMemory()) の約半分であるにもかかわらず、この例外を取得する方法がわかりません。何か案が ？

Total Memory : 1708MB as returned by Runtime.getRuntime().totalMemory() 
Max. Memory  : 3545MB as returned by Runtime.getRuntime().maxMemory() 

JRE : Java HotSpot(TM) 64-Bit Server VM  :  1.6.0_29   (Linux)
4

1 に答える 1

1

pcalcao が述べたように、JVM はガベージ コレクションに多くの時間を費やしており、実際の作業を十分に行っていないため、救済しようとしています。

これは、実際にはメモリが不足していないが、十分に近いため、実際には前進していないというケースを回避するための一種の安全弁です。この点については詳しく説明しません。この回答にはさらに詳細がありますが、あなたのケースに当てはまる可能性のあるいくつかのことについて言及します。

これは、物事をキャッシュする場合に発生する可能性が高くなりSoftReferenceます。ヒープが最大サイズに向かって成長すると、これらの参照がクリアされ、(キーループが触れているかどうかに応じて) 繰り返し再生成される可能性があり、GC が常に発生するという悪い動作が発生します。ただし、いくつかのソフト参照をクリアできるため、続行するのに十分なメモリを常に回復します.JDKでさえ、Localeクラスでこの種のキャッシュを使用しているため、これに悩まされています.

-XX:-UseGCOverheadLimit を本当に使用したい場合は、この動作を無効にすることができます。それでも、それが示す問題は現実のものです。実際の作業に費やす時間はランタイムの 2% 未満です。

これらのメモリ値をどこに出力していますか? プログラムの構造によっては、大量のガベージが生成され、一部の内部ループでほとんどのヒープが使用されている可能性がありますが、診断出力を配置した場所では、ガベージが再利用されています。-verbose:gc を使用すると、実際の G​​C の動作をよりよく把握できます。

于 2012-12-29T01:45:01.627 に答える