ヒープがいっぱいの場合、JVMは。をスローし
OutOfMemoryError
ます。しかし、そのような例外がスローされる前に、(完全な)ガベージコレクションが常に行われることが保証されていますか?
これは、例外がスローされたときに、メモリが強力な参照オブジェクト(またはGCルートから到達可能)でのみいっぱいになることを意味します。
編集:SunJVMを想定します-HotSpotが議論中です。
ヒープがいっぱいの場合、JVMは。をスローし
OutOfMemoryError
ます。しかし、そのような例外がスローされる前に、(完全な)ガベージコレクションが常に行われることが保証されていますか?
これは、例外がスローされたときに、メモリが強力な参照オブジェクト(またはGCルートから到達可能)でのみいっぱいになることを意味します。
編集:SunJVMを想定します-HotSpotが議論中です。
Javaマシン仕様は、セクション6.3(私の強調)で次のように述べています。
OutOfMemoryError
:Java仮想マシンの実装で仮想メモリまたは物理メモリが不足しており、自動ストレージマネージャがオブジェクト作成要求を満たすのに十分なメモリを再利用できませんでした。
したがって、JVMは、OOMEをスローする前に、ガベージコレクションを通じてメモリを解放するためにできることを試行することを保証します。
ガベージコレクタは通常、OutOfMemoryErrorがスローされる前に実行されます。ただし、次の場合、GCなしでOOMEを取得する可能性があります
完全なガベージコレクションが実行されたことは保証されませんが、VMはガベージコレクションを通じて十分なメモリを使用できるようにしようとしました。OutOfMemoryErrorクラスのAPIドキュメントで次のことがわかります。
オブジェクトがメモリ不足であるためにJava仮想マシンがオブジェクトを割り当てることができず、ガベージコレクタがそれ以上メモリを使用できない場合にスローされます。
ガベージコレクターは、参照されていないオブジェクトインスタンスを実際に破棄しようとせずに、十分なメモリが利用できないと判断できる場合があることに注意してください。最も明白な例は、最大ヒープサイズよりも多くのメモリ(たとえば、大きなバイト配列)を一度に割り当てようとする場合です。この場合、ガベージコレクターをまったく実行せずにOutOfMemoryErrorがスローされる可能性があります。
OutOfMemoryError
前の最後の操作がガベージコレクションであるという保証はありません。ガベージコレクションは使用されるメモリの量を減らすので、おそらくそうではありません。
人々がすでに答えたもの以外に考慮すべき他の追加の要素があります。たとえば、使用しているガベージコレクションポリシーです。スループットのガベージコレクションを検討してください。収集に時間がかかりすぎて、十分なメモリが解放されていない場合、これによりメモリ不足の例外がスローされます(ただし、最近の変更によって状況が変わった可能性があります)。これらすべてを言っても、私が書いているアプリケーションの実行中にガベージコレクションが発生するとは思いません...