4

フルgcの無限ループに入るプロダクションシステムがあり、メモリドロップはわずか2分で1MBのように8ギグを形成します。

ヒープダンプを取得した後、同じ文字列がヒープの99％を占める数百万のjava.lang.Stringオブジェクトを含むjava.lang.Object（[Ljava.lang.Object）の配列があることがわかります。

ただし、コードで修正できるように、どのクラスがこの配列を参照しているかはわかりません。

JDK 6でjmapツールを使用してヒープダ​​ンプを取得し、JProfiler、NetBeans、SAP Memory Analyzer、IBM Memory Analyzerを使用しましたが、これらのどれも、この膨大なオブジェクトの配列の原因を教えてくれませんか？...どのクラスがそれを参照しているかまたはそれを含んでいるかのように。

その情報を取得するために、異なる構成で別のダンプを取得する必要がありますか？...またはこれを引き起こしている犯人クラスを見つけるのに役立つ他の何か...それは大いに役立ちます。

4

3 に答える 3

3

過去に SAP Memory Analyzer を使用したことがありますが、これは「Greedy Memory Pigs」を見つけるのに非常に優れたツールです。

次のプレゼンテーションが役立つかもしれません:エンタープライズ規模での効果的な Java ヒープ メモリ分析。

于 2009-09-08T20:14:05.450 に答える
1

このような問題を見つけるために、以前にEclipse Memory Analyzerを使用したことがあります。通常、単純なものであれば、犯人を見つけるのはかなり簡単ですが、用語に慣れるまでには時間がかかります。実際のダンプが手元になければ、何がこの問題を引き起こしているのかわかりません。おそらく、この文字列に実際に何が含まれているかを確認する必要があります。それはどこから来ているのでしょうか?

于 2009-09-11T12:37:38.060 に答える
0

ソースとクラスを介してこの文字列を単純にgrepしようとしましたか?

于 2009-09-09T21:29:46.330 に答える