メモリ・リークの発見

Javaパフォーマンス・チューニングのポイントの1つは、実行時間やリソースの大半を消費しているメソッドを見つけ出すことです。前回の連載で紹介したツールHPjmeterは、こうした分析作業に最適な機能を備えています。

図1：HPjmeterによるメソッド呼び出し回数の表示

図1は、HPjmeterを利用し、Javaプログラム中のメソッドを呼び出し回数が多い順に一覧表示した画面です。この例では、「bel」メソッドの実行回数が他のメソッドに比べて非常に多いことが示されています。

また、HPjmeterに備わるもうひとつの計測項目である「Exclusive CPU Method Time（CPU占有時間）」を使用すれば、Javaプログラムの各メソッドの実行時間を知ることができます（図2）。

図2：HPjmeterによるメソッド実行時間の表示

Javaプログラムの開発においてもっとも注意すべきことのひとつとして、JVMのヒープ・メモリ不足があります。Javaプログラムの実行中にJVMのヒープ・メモリが不足すると、OutOfMemoryエラーが発生し、プログラムの実行を継続できなくなったりJVMが異常終了したりします。

本連載の第2回「ガベージ・コレクション」で説明したとおり、Javaオブジェクトが必要とするメモリ領域は、JVMのヒープ・メモリから自動的に割り当てられます。また、不要になった（どこからも参照されなくなった）Javaオブジェクトはガベージ・コレクションによって収集され、そのメモリ領域は自動的に解放されます。よって、メモリ領域の確保や解放をプログラマが意識する必要がありません。そのため、Javaでは、CやC++のようなにメモリ・リークが多発することはなくなりました。

たとえばC++の場合、以下のようなコードによって、メモリ・リークが発生します。

ここでは、変数ptrにC++オブジェクトのポインタを割り当て、使用後にnullをセットしています。しかし、正しくは「delete ptr」と記述し、C++オブジェクトのメモリ領域を解放しなくてはなりません。こうしたdeleteし忘れが、C++におけるメモリ・リークのおもな発生原因です。Javaでは、このdeleteに相当する作業をJVMのガベージ・コレクタが実行してくるため、こうしたタイプのメモリ・リークは起こらなくなりました。

メモリ・リテンションとは

しかし、Javaにおいても、メモリ・リークが完全になくなったわけではありません。たとえば、JavaオブジェクトAのオブジェクト変数fooが、JavaオブジェクトBを参照しているケースを考えます。この場合、たとえBがプログラムの処理上は不要になったとしても、fooからBへの参照が存在するかぎり、Bはガベージ・コレクションの対象とはなりません。このように、プログラマが予想しないところでオブジェクトの参照が残ってしまうことを、「メモリ・リテンション」と呼びます。とくに、コレクションや配列を参照元とするメモリ・リテンションが多発すると、解放されないJavaオブジェクトが継続的に増加し、メモリ・リーク状態に陥ります。

内容に関するご意見・ご質問・お問い合わせ