重複の可能性:
Java ゲームでガベージ コレクションの遅延を回避するにはどうすればよいですか? （ベストプラクティス）
Java の GC 一時停止はキラーです。多くの場合、アプリケーションにメモリ リークはありません。ある時点で、1G のメモリ割り当てごとに約 1 秒間一時停止することがあります。
Java GC に役立つ適切な Java コーディング プラクティスとは?
一例として、null オブジェクトはガベージ コレクションの対象になるため、object = null のようにオブジェクトを明示的に null に設定することをお勧めします。
一般に、GC を支援するには、不当なメモリ使用を避ける必要があります。簡単なアドバイスは次のとおりです。
1) 必要のない場合は、新しいオブジェクトを作成しないでください。たとえば、 のような構造は使用しないでくださいString test = new String("blabla");。可能であれば、古いオブジェクトを再利用します (主に不変オブジェクトに属します)。
2) クラス内でフィールドを宣言しないでください。フィールドはメソッド内でのみ使用されます。つまり、それらをローカル変数にします。
3) プリミティブ型の下でオブジェクト ラッパーを使用しないようにします。つまり、実際に値を保存する必要がない場合は、int代わりに を使用します。また、たとえば、可能な場合は、メモリ節約のために、 を使用せず、プリミティブ型の単純な Javaを使用します (ではなく)。IntegerbooleanBooleannullArrayListarraysInteger[]int[]
GC の一時停止を最小限に抑えるためにできる最善の方法は、ヒープのサイズを適切に設定することです。
プログラムが 1Gb を超えるライブ オブジェクトを使用しないことがわかっている場合は、 を渡しても意味がありません-Xms4096m。JVMはガベージを完全にクリアする必要があるまでガベージを残すため、実際にはGCの一時停止が増加します。
同様に、存続期間の長いオブジェクトがほとんどないことがわかっている場合は、通常、Tenured 世代と比較して Young 世代のサイズを大きくすることでメリットが得られます (Sun JVM の場合)。
コーディングに関して実際にできる唯一のことは、大きなオブジェクトをオフヒープに移動することです。しかし、それはほとんどのアプリケーションにとって役に立たないでしょう。
割り当てられ、すぐに解放されないオブジェクトは、Tenured ヒープ領域に移動されます。Tenured メモリは、収集するのに最もコストがかかります。存続期間の長いオブジェクトを大量に処理しないようにすると、GC の一時停止に役立ちます。