JENNIFERで“連続的なヒープメモリリーク”を探し出すコレクション追跡法は次の通りです。

• 先ず、［分析/統計 > 分析 > 性能ブラウザ］操作で画面へ移動し、対象インスタンスの任意の日数でヒープメモリの経過を確認します。
• 時間の経過でヒープメモリ使用量のグラフが増加しているかどうかを確認します。

• ［分析/統計 > 分析 > メモリ(コレクション)］操作で画面へ移動します。
  この画面で、コレクション（Vectorやハッシュテーブル等）オブジェクトのサイズ（コレクションの要素数）を確認できます。

• 先ず、画面で“最小モニタリングサイズ”と“自動スタックトレースサイズ”を設定します。
  最小モニタリングサイズは画面に表示するコレクションオブジェクトの最小サイズで、自動スタックトレースサイズはスタックトレースを自動で取得するコレクションのサイズです。
  例えば、最小モニタリングサイズが10000、自動スタックトレースサイズが50000なら、コレクションのサイズ（要素の数）が10,000個になると画面表示され、50,000個になると、その時点でのスタックトレースが自動で取得されます。

• コレクションはその要素の数が最小モニタリングサイズを超えるとリストアップされます。
  各々のコレクション毎の要素の数や変化量、そしてコレクションオブジェクトを使用したアプリケーション名等の情報を確認できます。

• 具体的にどの処理でコレクションに要素が追加されたかを確認するためには、＜スタック取得＞をクリックして、新しい要素が追加された時のスタックトレースを取得します。

• 自動リフレッシュ機能で画面が更新されます。また、リフレッシュボタンをクリックして更新することもできます。状態が“[待機中]”から“[確認]”に変わるまでリフレッシュします。

• “[確認]”状態に変わったら、“[確認]”をクリックします。

• クリックすると、次のように要素が追加されたスレッドのスタックトレースを確認できます。

• 単純に要素の数が多ければメモリを大量に使用することではありません。
  連続的な要素の数の増加がヒープメモリの増加と相関関係があるかを判断する必要があります。
  ＜デルタの初期化＞をクリックすると、“デルタコレクションサイズ”項目が0に変更されます（“コレクションサイズ”は要素の数で、初期化できません）。その後で要素の数の増加を確認します。

• このように、コレクションサイズとデルタコレクションサイズの変化がヒープメモリの増加と関連があると直感的に判断できたら、スタックトレースを周期的に取得してこの関連性を確認します。
  スタックトレースによって、どのアプリケーションで発生したかを確認できたら、開発者はアプリケーションのソースをレビューするフェーズに入ることができます。

このようなJENNIFERのメモリ（コレクション）の追跡が、連続的なヒープメモリリークの原因を調査する時に非常に効果的であることは、今まで多数のサイトで証明されています。
数百MBものメモリを占有可能な構造は、ハッシュテーブル、Vector、ハッシュマップのようなコレクションの可能性が極めて高いことが、JENNIFERのメモリリーク検出機能の基本的な考え方です。また、どのオブジェクトがメモリをどれだけ利用しているかよりも、何がそのオブジェクトを生成したかを把握する方がより重要です。

操作メニュー

• 自動リフレッシュ：　画面を自動リフレッシュする時間間隔を指定します。一時中止や手動でのリフレッシュも可能です。
• デルタの初期化：　デルタコレクション数を全て0に初期化し、次に要素が発生した時からカウントします。
• コレクション数：　最小モニタリングサイズと自動スタックトレースサイズが表示されます。クリックすると各々のサイズを変更できます。
• スタックトレースの削除：取得中の全てのスタックトレースを削除します。
• 全スタックの取得：　リストアップされている全てのコレクションに対し、スタックトレース取得のため、待機状態にします。
• ガベージコレクション：　GCを手動で行い、GCされたコレクションオブジェクトを整理します。

※メモリ（コレクション）追跡する場合は、追跡しない場合と比べると性能低下が発生する可能性があります。