3

私はアプリケーションに、基本的に、新しいバイト配列 (1K 未満) を作成し、数秒 (通常は 1 分未満ですが、一部のデータは最大 1 時間保存されます) 後にデータをディスクに書き込み、データはゴミになります。1 秒あたり約 400 パケットが作成されました。GC について特に心配する必要はないという記事をいくつか読みましたが、特にメモリ部分をすばやく作成して解放しました (Java 6 で)。GC の実行時間が長すぎると、アプリケーションで問題が発生します。いくつかの GC パラメータ (より大きな XMX と ParallelGC) を設定しました。これにより、完全な GC 時間は減少しますが、まだ十分ではありません。私は2つの考えを持っています.GCパラメータに焦点を合わせていますか、それともバイト配列メモリプールメカニズムを作成していますか? どちらの方がよいですか？

4

3 に答える 3

4

GC を実行する頻度はオブジェクトのサイズに依存しますが、コスト (クリーンアップ時間) はオブジェクトの数に大きく依存します。古い空間に行き着き、最終的に破棄されるまで、長寿命の配列が空間間でコピーされているのではないかと思います。古い世代のクリーニングは比較的高価です。

ByteBuffer を使用してデータを保存することをお勧めします。これらは byte[] に似ていますが、可変サイズであり、NIO でダイレクト バイト バッファーを使用できる場合は、わずかに効率的です。バッファを事前に割り当てると、バッファを事前に割り当てるのがより効率的になります。（ただし、仮想メモリを浪費する可能性があります）

ところで: ダイレクト バイト バッファは、"C" 空間のメモリを使用するため、ヒープ領域をほとんど使用しません。

于 2011-01-17T12:46:40.163 に答える
0
  1. プロファイラーを使用してコードスニペットを識別します
  2. WeakReferencesを試してください。
  3. VMにGCアルゴリズムを提案する
-Xgc: parallel
  1. 大きなヒープを設定し、共有メモリ
-XX:+UseISM -XX:+AggressiveHeap
  1. ガベージコレクションについては、以下に設定します。

-XX:SurvivorRatio 8

  1. これは http://download.oracle.com/docs/cd/E12840_01/wls/docs103/perform/JVMTuning.html#wp1130305に役立つ場合があります
于 2011-01-17T13:07:08.723 に答える
0

GC が十分に機能していない理由を分析することをお勧めします。を使用jmapしてヒープをダンプし、jhatEclipseメモリ アナライザーを使用して、そこに存在するオブジェクトを確認できます。不要になった参照を保持していることに気付く場合があります。

GC は非常に巧妙であり、独自のメモリ管理コードで GC の裏をかこうとすると、事態が悪化する可能性があります。パラメータを調整してみてください。新しい G1 ガベージ コレクタも試すことができるかもしれません。

また、GC は短命で不変のオブジェクトを好むことを覚えておいてください。

于 2011-01-17T12:59:26.303 に答える