チューニングに使えるJava性能監視ツール
JavaVMを監視するツール群
今回は、Java EEアプリケーションをチューニングする際に便利なツールを紹介します。JavaVMの状態を監視／レポートするツールは、フリー・ソフトウエアや製品を含め、いくつか提供されています。米Oracle（米Sun Microsystems）のJava環境にも、標準で便利なツール群が付いています。本記事では、標準ツールであるjconsoleとjstatの2つを紹介します。
表1: 主なJavaVM監視／レポーティング・ツール
| 製品名 | 特徴 |
|---|---|
| 侍 | タブ表示できるGUIのログ追跡ツール。ログ・ファイルから、VMのヒープ状況の解析やスレッド解析を行える。 |
| Eclipse Memory Analyzer | IDE環境のEclipseで利用可能な、グラフィカル・メモリー解析プラグイン。単体テストから仮想サーバー上でのヒープ監視まで利用できる。ヒープ利用状況の円グラフ表示や、ガベージ・コレクション対象クラスの追跡など、多種多様なレポート機能を備える。 |
| JProbe | Java性能測定ツール。メソッドの実行時間、呼び出し回数をグラフィカルに表示、警告する。メモリー利用状況をグラフィカルに表示し、メモリー・リークの調査や、コード・カバレッジ*1調査も行う。 |
- [*1] コード・カバレッジ: アプリケーション内にあるメソッドの実行率のこと。コードは存在するが実行されていないクラスやメソッドを追跡するために利用する。
これらのほか、Oracle WebLogic Application Serverや、IBM WebSphereなどの統合アプリケーション・サーバー製品には、管理ツールの1つとして性能監視ツールが整備されています。
JavaVMをグラフィカルに監視するjconsole
JavaVMのメモリー使用状況などを参照／監視できるツールとして、Sun Java 5以降では、標準でいくつかの便利なツールが用意されています。その1つに、JavaVMの利用状況を監視した結果をリアルタイムで図示するjconsoleがあります。使い方は非常に簡単で、コマンド・プロンプトからコマンドを入力するだけで起動します。
C:\>jconsole [監視するJavaVMのプロセス番号]
起動時にプロセス番号を省略した場合は、現在起動しているJavaプロセスの一覧から選択できます。JavaVMのプロセス番号を調べるツールも用意されています。こちらは、コマンド・プロンプトで、以下のように入力すると起動します。
C:\>jps
例えば、Windows環境でEclipseを起動した状態で、EclipseからTomcat 6.0を起動させたケースを想定します。この状態でjpsを実行した結果は、以下のようになります。
C:\>jps 6284 Bootstrap 7512 6564 Jps
この状態にて、jconsoleでTomcat 6.0（=Bootstrap）プロセスを指定します。
C:\>jconsole 6284
プロセス番号を正しく指定すると、jconsoleが監視した結果のグラフが、図1のように表示されます。
|
|
| 図1: jconsoleの概要画面（クリックで拡大） |
図中のグラフの意味は、以下の通りです。
【左上】: ヒープメモリの使用状況
|
【右上】: 現在有効なスレッド数 |
【左下】: 現在までに読み込まれたクラスの数
|
【右下】: JavaVMのCPU使用状況 |
ヒープ・メモリーの推移は、図1の左上にあるヒープ・メモリーの使用状況のように、ノコギリ状の波形が全体的にゆるやかに右肩上がりになり、一定時間後に大幅に下がるのが通常です。これは、ガベージ・コレクション（GC）と呼ばれる、JavaVMのメモリー開放機能が自動的に実行されたことによります。もしヒープ・メモリーを開放せずに蓄積したままであれば、長期的に利用されているオブジェクトが存在し続けることになります。それが想定外のことであれば、メモリー・リークを疑います。
ただし、監視（モニタリング）しながらアプリケーションを開発／実装することは、非常に稀です。開発時には何度もアプリケーション・サーバーを再起動することになるため、再起動するたびに毎回監視プロセスを変更しなければなりません。さらに、実装段階ではコードに不具合が含まれるため、運用段階とはメモリーの使用状況やクラスの数が明らかに異なるでしょう。
可能であれば、アプリケーションが完成してから単体テストの段階で何度も動かしてみて監視します。しかし、高い負荷を持つ機能でもない限り、プロセスの測定や監視をしても、あまり効果がありません。監視する対象の例には、プロトタイプ作成後の動作テストやライブラリ導入後の動作テストが挙げられます。
明らかに複数の機能や画面で共有するオブジェクトを利用する場合や、外部リソースを取得する処理、何らかの業務処理で非同期通信をする場合など、ほかの機能に比べて特殊な操作を行うもの、特に外部システムとのI/Oが発生するものは、監視の必要があります。オブジェクトが保持されるタイミングや開放されるタイミングが、共通機能や外部機能に依存するからです。何度も動かして監視する必要があります。
