2

私は、ブラウザーにデプロイされる Java スウィング アプレットを作成してきました (これは、アプレットとしてはごく普通のことです)。Java 2D を使用します。

とにかく、デスクトップ アプリとして実行する開発目的のテスト ハーネスがあります。

まったく同じテスト データに基づくと、テスト ハーネス バージョンのヒープの合計サイズは 18 メガです。これは、Java 2D キャンバス上に約 7000 個のオブジェクトを、おそらく 30,000 の座標ペアとその他の小片で描画することに基づいているため、18 メガのヒープは大きいですが、ほぼ理解できます。アプリの合計サイズは 40 メガです。

今では、IBM Websphere を介して、アプレットとまったく同じコードを実行しています。

プラグインのメモリのデルタは約 160Meg に上昇します。どういうわけか、同じ Java コードが 10 倍のメモリを使用しています。

私の古いCBM64プログラマーは、最初の数字に特に感銘を受けていません.1桁の肥大化したIMOですが、2番目の数字は驚くべきものです. 私は VisualVM を探していますが、Object、char[]、String などをメモリ ホグとして配置するのに役立ちます。私のクラスはどれも近づきません。

興味深いことに、Float と Double はまったく同じ量のメモリ (それぞれ 16 バイト) を占有しているようです。

私の現時点での主な推測は、SOAP を使用したデータ取得がメモリ使用量の急増を引き起こし、理由は不明ですが、GC の代わりに SOAP XML が保持されているということです。

ここで何が起こっているかについて手がかりを持っている人は他にいますか？

4

2 に答える 2

1

それを見つけた-またはその少し。

Axis 1.3を使用してSOAP呼び出しを行う場合、つまり最初にデータをフェッチする場合、次の呼び出しまでSOAPXMLの割り当てが解除されません。

残念ながら、この場合、最初のデータ入力呼び出ししかなかったため、Axisは約150MegのXMLにぶら下がっていました。十分に簡単な回避策として、2回目の「空の」呼び出しを行ってクリアします。GCを実行すると、すべて問題ありません。

于 2012-10-05T10:41:36.997 に答える
0

JVM は常に、必要以上に大きなメモリ プール、または実際に常に使用される可能性が高いメモリ プールを割り当てます。JVM のメモリ使用量を外部から測定すると、誤解を招く可能性があります。

JVM がこれを行う理由はいくつかあります。

  • オブジェクトを割り当て/移動するスペースが多いほど、ガベージコレクターをより効率的に実行できます
  • GC がいくらかのスペースをクリアしたとしても、プログラムが再び必要とする可能性が高いという前提でスペースを確保しておくことは理にかなっています。
  • GC はガベージを遅延収集することで不要な作業を回避します。GC が強制的に収集を実行しない限り、古いオブジェクトがかなりの時間ヒープ上に存在する可能性があります。これらのオブジェクトが害を及ぼすことはありません。スペースは、必要に応じて後で再利用できます。

おそらく、この行動の結果を見ているだけでしょう。実際に問題が発生していない限り (OutOfMemoryError - メモリ リークが発生している可能性があります)、心配する必要はありません。

ps Float オブジェクトと Double オブジェクトの両方がそれぞれ 16 バイトを使用する理由は、a) オブジェクト ヘッダーがあり、b) キャッシュ ライン/メモリ アドレッシング アラインメントを確保するためにパディングされる可能性が最も高いためです。配列に多数の浮動小数点数/倍精度浮動小数点数をパックすると、それぞれ 4 バイトと 8 バイトを使用することがわかります。

于 2012-10-05T08:55:23.200 に答える