Javaヒープダンプで、コードのどこ/どのスレッドがダンプを引き起こしたかを正確に知るにはどうすればよいですか?
3 に答える
メモリ ダンプを読み取る場合:
「Eclipseメモリアナライザー」を試すことをお勧めしますここから
もう1つのオプション(無料)は、JVisualVM($JAVA_HOME/binで入手可能)でこれを開くことです.jhatもクールですが、すでに推奨されていました:)
ここで、メモリ ヒープ ダンプの原因となったスレッドについて質問していますが、メモリ ダンプの処理方法については質問していません。メモリ ダンプをどのように取得したかによって異なります。ダンプを取得するには、さまざまな方法があります。
あなたのプロセスでは、OutOfMemory エラーが発生したらメモリ ダンプを生成するように JVM に指示できます。この場合、JVM 自体になると思います。
JMX サーバーが JVMサンプルと共に実行されている場合、MBean からヒープ ダンプの作成をトリガーできます。
アプリケーションの外部でシステム コール (Linux の場合) を使用することもできます
kill -3 _YOUR_JAVA_PROCESS_ID_
。これにより、ヒープダンプが生成されます。
しかし、なぜそのような情報が必要なのか、私にはほとんど想像できません。コメントの後半で「正確なコード行」について言及していますが、これらの方法は通常、JVMの外部にあります...ヒープダンプ自体を生成したコード行が必要ですか、それとも実際の問題を特定しようとしていますか?
お役に立てれば
Javaでは、どこかでオブジェクトを作成し、それを多くの場所で使用し、GCを使用してそれを収集します。リークの原因となる単一の行はありません。
MAP などのツールで確認する必要があるのは、オブジェクト数とそれらが使用するヒープです。それぞれのターゲット クラスを選択し、それらがガベージ コレクションされない理由を確認します。(誰かが必要以上に参照を保持しています-静的フィールドと言ってください)
このページからの説明がより役立つ場合があります - http://scn.sap.com/people/krum.tsvetkov/blog/2007/07/02/finding-memory-leaks-with-sap-memory-analyzer MATホームページより)
Java Heap Analysis Tool (jhat)または jconsole (JAVA_HOME\bin にあります)を使用してみてください。