問題タブ [eclipse-mat]

ヒープダンプがあり、Eclipse MATを使用していますが、これはvisualvmまたはその他のOQLクライアントで機能するはずです。

次のような操作を行うことで、クラスのすべてのインスタンスのフィールドを選択できます。

...ただし、これはメンバー変数とインスタンスを持つ型に制限されています。

インスタンスのないクラスの静的フィールドを選択するにはどうすればよいですか？

これは、この他の質問にいくらか関連しています。

OQL構文を使用してEclipse MATでオブジェクトをカウントするにはどうすればよいですか? これは機能しません:

(メモリにロードされた休止状態の pojo の数をカウントしたい)

そうするための非常に簡単な方法があるに違いありません...私を助けてくれてありがとう！

MapActivityを拡張するアクティビティのメモリリークを解決するためにEclipseMemoryAnalyzer を使い始めたばかりですが、その出力を正しく理解しているかどうかわかりません。リークを分析するために、アクティビティを開始して画面を数回回転させてから、ヒープダンプを取得して開きました。私が最初にしたことは、ヒストグラムビューを開いて 、自分のアクティビティ（ChangeLocationActivityと呼ばれる）を探すことでした。同じアクティビティのインスタンスが3つあるため、これは確かにメモリリークのように見えます。そこで、着信参照を持つオブジェクトのリストを取得し、3つのインスタンスすべての弱参照を除いた「GCルートへのパス」を取得しました。これが最初のインスタンスのパスです、これ2番目のインスタンス（カスタムMyLocationOverlayは、一部のMotorolaデバイスのバグをバイパスするために作成された非常に単純なクラスであり、drawMyLocation（）で例外をキャッチすることを除いて特別なことは何もありません）、最後にこれは3番目のインスタンスのクラスです。これは現在表示されているもののように見えます。

前に言ったように、これらの結果を正しく理解しているかどうかはわかりませんが（Eclipse Memory Analyzerは非常に強力ですが、非常に複雑です）、メモリリークの原因はGoogleマップライブラリに関連しているように見えます。私が正しいのか、それともこれらの結果を理解していないのか、誰か教えてもらえますか？

アプリの重大なメモリの問題を追跡する過程で、アプリからいくつかのヒープ ダンプを調べましたが、ほとんどの場合、知らない巨大なビットマップがあります。

9.4MB、または 9,830,400 バイト、または実際にはピクセルあたり 4 バイトの 1280x1920 の画像が必要です。

私はEclipse MATをチェックインしました。それは実際にはバイト[98​​30400]であり、android.graphics.Bitmap.

これをファイルにダンプして確認したいと思います。どこから来ているのか理解できません。すべてのドローアブルの中で最大の画像は 640x960 の png で、3MB もかかりません。

Eclipseを使用して「値をファイルにコピー」しようとしましたが、バッファをファイルに出力するだけだと思います.バイトストリームを読み取ってピクセルあたり4バイトとして表示できる画像ソフトウェアはわかりません画像。

何か案が？

私が試したことは次のとおりです。バイト配列をファイルにダンプし、/sdcard/img にプッシュし、次のようなアクティビティをロードします。

何も見えませんでした。

画像がどのようにエンコードされているか知っていますか？に格納されているとしbyte[] bufferます。buffer[0]赤buffer[1]ですか、緑ですか？

私はJavarmiアプリケーションのパフォーマンス調整に取り組んでおり、OQLを使用して以下のクエリを実行しています。

上記のクエリは、いくつかのレコードの後に​​このエラーが続くJVisualVMで正常にコンパイルされます：-

結果が多すぎます。クエリを絞り込んでください。

同じクエリをEclipse-MATで実行できません。

&& tpoint.csf!=nullから削除すると、 Eclipse-MATabove queryで正常にコンパイルされます。また、JVisualVMと比較して非常に短い時間で、すべてのレコードが表示されます。

&& operatorEclipse-MATで使用するための正しい構文を見つけることができません。

Eclipse-MATの適切なOQL参照を見つけるのに苦労しているので、適切な参照を高く評価します。

前もって感謝します...

発生時にアプリケーションによって作成された大きな（5GB）hprofダンプがありOutOfMemoryErrorます。（ XXの使用：HeapDumpOnOutOfMemoryError）。

残念ながら、このエラーが発生したときに収集されたログはありません。これを再作成するには数時間かかります。いくつかのツールがhprofからの例外スタックトレースまたはすべてのスレッドスタックなどを表示できるかどうかを期待していました。

現在MATを使用していますが、スレッド情報を取得する方法がわかりませんでした。どのツールを使用できますか？

（OOMが発生したときのhprofファイルにスレッド/呼び出しの場所に関する情報があるかどうかはわかりません）。

（通常の場合にスレッドダンプを取得する方法を知っています。ここでの問題は、すでに発生したイベントです。私が持っているのはhprofダンプだけです。）

ScheduledThreadPoolExecutorが300万の将来のタスクで終わるという問題があります。そのタスクがスケジュールされている場所に移動できるように、どのタイプのタスクを確認しようとしていますが、この画面から情報を取得する方法がわかりません（これらの将来のタスクを右クリックして、メニューでさまざまな選択肢を選択してみました） 。実際のランナブルへのリンクなど、GUIに何かが欠けているようです...

さらに掘り下げる方法について何かアイデアはありますか？

2 つの OQL ステートメントの結合に問題があります。OQL のサブ選択構文は少し風変わりなので、誰か助けてくれませんか?

1を選択

2 つの列を持つ結果セットを返します: スレッド名 | 保持ヒープ サイズ

2を選択

2 つの列を持つ結果セットも返します: スレッド名 | リクエストウリ

質問

これらを3列の単一選択に結合するにはどうすればよいですか?

したがって、結果は次のようになります。リクエストウリ | 保持ヒープ サイズ