FinalizerReferenceを解放したい

###肥大化するメモリの問題を解決したい
あるサーバにアクセスし、周期更新を行うAndroidアプリケーションを開発しデバッグを行っております。最近になり、このアプリケーションがOutOfMemoryで落ちていることが判明し、メモリ領域の解放に努めております。

###発生している問題
Android Studio でデバッグを行っているのですが、Memory Dumpを実行した際に以下のスクリーンショットのような状況でした。

図のように、FinalizerReferenceがその大部分を専有していることが見て取れると思います。
アプリケーションでは定期的にGCを実行し、メモリ不足の対策を行っておりますが、FinalizerReferenceだけは開放されずに残ってしまいます。

このFinalizerReferenceに専有された領域を開放するための手法はございますでしょうか。
ご回答の程よろしくお願いいたします。

行動規範の内容に同意します

回答1件

質問意図を外しているような気もしますが、もし「いや、それはわかってるけど、そういうことが知りたいのではない」ということでしたら大変申し訳ありませんがスルーをお願いします。

FinalizerReferenceはAndroidのランタイムが「なんらかの理由でメモリー領域へ回収可能になるまであと一歩のオブジェクトを覚えておくためのハンドル」ではないかと思います。

汎用OS上のJVMでは到達不能（だれからも参照されなくなった）オブジェクトかつfinalizeメソッドがoverrideされているクラスのインスタンスの場合、ガベージコレクターは即座にそれを開放せず次回のFull GCの際にfinalizeメソッドを呼び出してから解放します。この到達不能であることが分かってからfinalizeメソッドを呼び出すまでにそのオブジェクトを覚えておくためのチェーンとしてFinalizerReferenceの派生クラスであるFinalizerインスタンスが用いられます(A)。

そこから類推し、Androidにおいてfinalizeメソッドをオーバーライドしたクラス(仮にMemotyFootprintクラスとします(※B))のインスタンスを大量に生成してみると、FinalizerのインスタンスではなくFinalizerReferneceが生成されそこから大量に生成したインスタンスがぶらさがっているのが観察できました。つまり汎用OS上での(A)と同じ目的にもこのクラスが用いられていることが伺えます。

少なくとも(A)の仕組みから考えると、これはAndroidのランタイムがメモリーの管理に用いる機構であり、「アプリケーションから開放を指示できるようなものではない」と思います。またRuntime#gcを呼び出してもそれは「GCをしてほしい」というヒントをJVMに与えるだけであって「Full GCを開始せよ」という指示ではないため実際にどのようにGCが動くかはVMの動きに支配される部分が大きいと思います。

さて、ご質問を拝見しますとFinalizerReferenceのインスタンスは6000個あまりあり、そこに繋がれているインスタンスの平均サイズを計算すると平均20KB程度であることがわかります。FinalizerReference自体は1個あたり36byteの小さなものでretained sizeを左右するのはここから繋がっているオブジェクト(GCでの回収待ちのオブジェクト?)にあると思います。

こうした問題の調査にはヒープ上どのような種類のものがどれだけあるかの基礎情報を解析しそこからプログラム上でどこに問題があるかを推定していくようなアプローチを取るのではないでしょうか？

Android Studioであればご質問にある画面のHeap Dumpと書かれている左側のボタン(緑色の矢印のボタン)でhprofダンプを出力し、それをMAT(Memory Analyzer Tool)などで解析するのだと思います。

試しに(※B)で実験したMemoryFootprintクラスに20KBほどの内部バッファーを持たせて数秒おきに4000個ずつ生成するような単純なアプリでhprofダンプを採取しMATで解析したところ以下のようなレポート(MemoryFootprintのインスタンスが80MBほどある)が得られました。Android StudioのAndroid Profiler上では単純に「FinalizerReferenceのretained sizeがでかい」としか言ってくれませんが、MATを使うとより実際的なレポートが得られるようです。