最終的には、実行しているプラットフォームに関係なく、使用できる最大ヒープは常に有限です。Windows 32 ビットでは、これは約 2 GB です (特にヒープではなく、プロセスごとのメモリの合計量)。たまたま Java がデフォルト値を小さくすることがあります (おそらく、プログラマーが、この問題に遭遇し、その実行内容を正確に調べる必要なしに、メモリ割り当てが暴走するプログラムを作成できないようにするためです)。
したがって、必要なメモリの量を決定するか、使用しているメモリの量を減らすために取ることができるいくつかのアプローチがあります。Java や C# などのガベージ コレクション言語でよくある間違いの 1 つは、使用しなくなったオブジェクトへの参照を保持したり、代わりに再利用できる場合に多くのオブジェクトを割り当てたりすることです。オブジェクトがそれらへの参照を持っている限り、ガベージ コレクターはオブジェクトを削除しないため、ヒープ スペースを使用し続けます。
この場合、Java メモリ プロファイラーを使用して、プログラム内のどのメソッドが多数のオブジェクトを割り当てているかを判断し、それらが参照されなくなったことを確認する方法があるかどうか、または最初からそれらを割り当てないようにする方法があるかどうかを判断できます。私が過去に使用したオプションの 1 つは、"JMP" http://www.khelekore.org/jmp/です。
何らかの理由でこれらのオブジェクトを割り当てていると判断し、参照を保持する必要がある場合 (何を行っているかによって異なります)、プログラムの起動時に最大ヒープ サイズを増やすだけで済みます。ただし、メモリ プロファイリングを実行し、オブジェクトがどのように割り当てられるかを理解すると、必要なメモリ量をよりよく理解できるはずです。
一般に、プログラムが有限量のメモリ (おそらく入力サイズに依存) で実行されることを保証できない場合、常にこの問題に遭遇します。これらすべてを使い果たした後でのみ、オブジェクトをディスクなどにキャッシュすることを検討する必要があります。この時点で、何かのために「Xgb のメモリが必要です」と言う非常に正当な理由が必要であり、改善してもそれを回避することはできません。アルゴリズムまたはメモリ割り当てパターン。通常、これは大規模なデータセット (データベースや科学分析プログラムなど) で動作するアルゴリズムの場合にのみ当てはまり、キャッシュやメモリ マップド IO などの手法が役立ちます。
-Xmx
ヒープの最大サイズを設定するコマンドライン オプションを使用して Java を実行します。
http://docs.oracle.com/javase/7/docs/technotes/tools/windows/java.html#nonstandard