問題タブ [eclipse-mat]

私のアプリは正常に動作しています (つまり、クラッシュはありません)。テスト中、メモリの使用状況を調査しました。Android Studio (AI-141.2006197) DDMS を使用して Dump HPROF ファイルを出力し、それを Eclipse Memory Analyzer で開きます。このツールは、リークの疑いを説明します:

dominator_tree からの詳細情報:

この 1 日で、アプリのオープニング アクティビティとフラグメントを必要最小限に取り除き、すべてのオープニングとビットマップへの参照を削除し、メニュー、サービス、すべてを削除しました。残っているのは、1 つのフラグメントを含む 1 つのアクティビティだけです。フラグメントには ListView があり、各リスト項目には単純な TextView があります。ビットマップは使用されません。必要に応じて、後でこの質問を編集してコードを表示できます。

この簡素化されたアプリを電話とタブレットでテストしています。アプリをインストールして起動し、最初のフラグメントによって表示されるリストを確認してから終了します。DDMS を介して GC を実行し、ヒープ ダンプを実行して Eclipse メモリ アナライザーで調べます。電話とタブレットの両方で、「潜在的な」メモリリークが見られます。

cynogenmod ROM を使用する私のテスト用電話には、「アセットのパージを許可する」というパフォーマンス設定オプションがあります ( http://pocketnow.com/2012/12/10/5-nexus-4-speed-tips#toc-を参照)。 5）。この機能を有効にすると、潜在的なメモリ リークがなくなります。これは、結局のところ、アプリに問題はないと思いますが、理解できないシステムの動作です。

いくつかの質問：

1. これはアプリのメモリ リークである可能性がありますか?
2. テスト アプリがビットマップまたはドローアブルを使用していない場合、ビットマップ用のメモリが割り当てられるのはなぜですか? 何を確認できますか？
3. Eclipse メモリ アナライザーによって報告された潜在的なメモリ リークのうち、無視できるものを解釈することに関して何かアドバイスはありますか?

前もって感謝します。私は組み込みリアルタイム C のバックグラウンドを持っているので、メモリ リークが発生すると非常に神経質になります。

MAT ツールの初心者として、問題の分析に使用しています。しかし、クラス インスタンスの下にあるこれらのスレッドにとって、それが何を意味するのかはわかりません。写真が示すように（リーク容疑者タブの下）。

それらのスレッドがリソース (クラス インスタンス) を待っているということですか?

Eclipse MAT を使用してメモリ リークを分析しようとしています。問題が本質的にリンクされたリストであるオブジェクトによって引き起こされることはすでに知っています。たとえば、次のようなものです。

問題は、それが非常に深い (約 40,000 要素) ことであり、標準LinkedListではないため、MAT のサポートはここでは利用できません。

最初の要素があるので、リストの一番下に到達しようとしていますが、単純に右クリックnextして を選択するよりも良いものを見つけることができませんでしGo Toた.40,000要素では時間がかかります. リンクされたスタックの一番下に簡単に到達するために何らかのスクリプトを使用する方法はありますか?

最近報告された速度低下のため、ヒープ ダンプを分析しています。そこには 1.5GB のバイト配列がいくつかあり、それらがどこから来たのかを追跡することはできません。Eclipse の MAT は、そのような巨大なチャンクを保持しているクラスを表示しません。「<system class loader>」とだけ書かれています。たぶん、私は正しい場所を探していません。

これら 2 つの巨大なバイト配列が保持されている原因は何ですか? アプリは Websphere Application Server で実行されます。アプリを実行している環境に関するJVM情報を次に示します。ありがとう

• コンパイル: JVM 1.6
• 環境 Java バージョン : JRE 1.7.0 Linux amd64-64 build 20130421_145945 (pxa6470sr4fp1ifix-20130423_02(SR4 FP1+IV38579+IV38399+IV40208) )
• 仮想マシンのバージョン: VM ビルド R26_Java726_SR4_FP1_2_20130421_2353_B145945
  Just-In-Time(JIT) コンパイラ スイッチ、Ahead-Of-Time (AOT) コンパイラ スイッチ、コンパイラ バージョン: r11.b03_20130131_32403ifx4
• ガベージ コレクターのバージョン: GC - R26_Java726_SR4_FP1_2_20130421_2353_B145945_CMPRSS
• Java ヒープ情報
  • -Xmx (最大 Java ヒープ サイズ) : 4096m
  • -Xms (初期 Java ヒープ サイズ) : 1024m
  • -Xscmx (Java クラス データ共有キャッシュ サイズ) : 90M
  • -Xscmaxaot (AOT データに使用できるキャッシュ内の最大バイト数) : 4M

編集：

これらの 2 バイト配列インスタンスは、私のコードでは直接定義されていません。ただし、給与計算のバルク ファイルを読み書きするために、util クラス内でこれらのメソッドを常に使用しています。一時ファイルと入力ストリームの絶え間ない作成がそれと関係があるのだろうか.

}

更新: bytearray のサイズを Google で調べたところ、問題の原因は私のコードではなく、共有キャッシュに使用していた JGroups であることが判明したため、問題は解消されました。問題の JGroups の問題は次のとおりです。

https://issues.jboss.org/browse/JGRP-1117