私の Java jar は、大規模なプログラムが使用する多くの 1 つにすぎません。自分のコードがメモリ リークの原因なのか、それとも自分のコード以外に問題があるのかを判断しようとしています。私は jvisualvm を使用しており、すべてのクラスを特定しましたが、疑わしいものはありません。サンプラーを見ると、byte[]、char[]、および int[] がサイズと作成されたインスタンスの点で最大のユーザーのように見えます。問題は、彼らが誰のものであるかを判断できないことです。プログラムにさまざまな byte[] があることは知っていますが、32,000 ほどのインスタンスがあるため、それらを 1 つずつ見てソースを特定するのは困難です。特定の jar ファイルまたは領域に由来するアイテムのみを表示できるように、データをフィルター処理する方法はありますか? ありがとう。
質問する
1794 次
1 に答える
2
byte[]あなたがたくさんのまたはインスタンスを作成していることをあなたが知らない限りString、私はお金をかけbyte[]たりchar[]、問題の原因になったりしません。私が掘り下げたほとんどすべてのヒープには、Javaの内部の多くのビットで使用されているため、これらがたくさんあります。それらが問題にならないというわけではありませんが、ヒープ内で最大のものでなくても、作成していることがわかっている異常な量のオブジェクトに最初に集中する方が有益です。
VisualVMはその場でメモリ使用量を監視し、GCサイクルを監視するのに最適ですが、私は個人的にMATがVisualVMよりも分析作業に適していることを発見しました。
MATを使用すると、ドリルダウンして、保持されているオブジェクトへの着信および発信参照を確認することもできます。これにより、予想よりも多くのメモリを保持しているオブジェクトをより正確に把握でき、JARのオブジェクトの1つが原因であるかどうかを確認するのに役立ちます。
MATに含まれているヘルプドキュメントは非常に優れており、始めるのに役立つ一読の価値があります。
うさぎの穴をさらに詳しく知りたい場合は、MATとVisualVMの両方でヒープをクエリするために使用できるOQLを読んでください。
MATはここで見つけることができます：http ：//www.eclipse.org/mat/
私はいくつかの背景の読書を掘り出しました（そのうちのいくつかは少し古いですが、それでも問題に取り組む方法のより良い絵を描くことに関連しています）
リークは簡単に見つけることができますが、メモリ使用量の分析は少し難しいです。
メモリリークは簡単に見つけることができ
ます。SAPメモリアナライザを使用してメモリリークを見つける
ヒープを見るときは、GCについて少し理解する価値があるので、これらをフリックする価値があります。ガベージコレクションの問題を診断する
GCチューニング
于 2012-12-13T10:09:58.930 に答える