
		前の項目	目次		次へ

第 3 章

jconsole の使用

JConsole グラフィカルユーザーインタフェースは、Java Management Extensions (JMX) 仕様に準拠した監視ツールです。JConsole は Java 仮想マシン (Java VM) の広範なインストゥルメンテーションを使用して、Java プラットフォームで実行されるアプリケーションのパフォーマンスとリソース消費に関する情報を提供します。

Java Platform, Standard Edition (Java SE プラットフォーム) 6 では JConsole がアップデートされ、Windows および GNOME デスクトップの Look & Feel (ほかのプラットフォームの場合は標準的な Java のグラフィカル Look & Feel) を提供します。このドキュメントに掲載した画面キャプチャーは、Windows XP で動作するインタフェースのインスタンスから取得されました。

JConsole の起動

jconsole 実行可能ファイルは、JDK_HOME/bin にあります。ここで JDK_HOME は、JDK (Java Development Kit) がインストールされているディレクトリです。このディレクトリがシステムのパスにある場合は、コマンド (シェル) プロンプトで jconsole と入力するだけで、JConsole を起動できます。それ以外の場合は、実行可能ファイルへのフルパスを入力する必要があります。

コマンド構文

JConsole を使用すれば、ローカルアプリケーション (JConsole と同じシステム上で動作するアプリケーション) とリモートアプリケーション (ほかのシステム上で動作するアプリケーション) の両方を監視できます。

注 - JConsole を使用してローカルアプリケーションを監視するのは、開発やプロトタイプ作成には便利ですが、JConsole 自体がかなりのシステムリソースを消費するため、実稼動環境で使用することはお勧めしません。JConsole アプリケーションを監視対象のプラットフォームから切り離すために、リモート監視をお勧めします。

jconsole コマンドの構文についての詳細は、jconsole コマンドのマニュアルページ「Java 監視および管理コンソール」を参照してください。

ローカル監視の設定

コマンド行で次のコマンドを入力して JConsole を起動します。

% jconsole

JConsole が起動すると、JConsole と接続可能でローカルに動作するすべての Java アプリケーションが選択肢として表示されます。

特定のアプリケーションを監視する場合、そのアプリケーションのプロセス ID を知っていれば、JConsole を起動して、そのアプリケーションと接続させることもできます。この場合、アプリケーションは JConsole と同じユーザー ID で実行する必要があります。特定アプリケーションのローカル監視のために JConsole を起動するコマンド構文は次のとおりです。

% jconsole processID

上記のコマンドで、processID は、アプリケーションのプロセス ID (PID) です。アプリケーションの PID を調べるには、次の手順を実行します。

Unix または Linux システムの場合、ps コマンドを使用して、実行中の java インスタンスの PID を見つけます。
Windows システムの場合、タスクマネージャーを使用して、java または javaw の PID を見つけます。
jps コマンド行ユーティリティーを使用して PID を調べることもできます。Java 仮想マシンプロセスステータスツールのマニュアルページを参照してください。

たとえば、Notepad アプリケーションのプロセス ID が 2956 であると特定した場合は、次のコマンドで JConsole を起動します。

% jconsole 2956

JConsole とアプリケーションは同じユーザーが実行する必要があります。管理および監視システムは、オペレーティングシステムのファイルアクセス権を使用します。プロセス ID を指定しない場合、JConsole によってローカルの Java アプリケーションがすべて自動的に検出され、監視するアプリケーションを選択するためのダイアログボックスが表示されます (「JMX エージェントへの接続」を参照)。

詳細は、「ローカルの監視および管理」を参照してください。

リモート監視の設定

リモート監視のために JConsole を起動するには、次のコマンド構文を使用します。

% jconsole hostName:portNum

上記のコマンドで、hostName はアプリケーションを実行するシステムの名前、portNum は、Java VM を起動して JMX エージェントを有効にしたときに指定したポート番号です。詳細は、「リモートの監視および管理」を参照してください。

ホスト名/ポート番号の組み合わせを指定しない場合、JConsole には、ホスト名とポート番号が入力可能な接続ダイアログボックス (JMX エージェントへの接続) が表示されます。

セキュアなリモート監視の設定

Secure Sockets Layer (SSL) でセキュリティー保護された接続により監視を実行するよう、JConsole を起動することもできます。接続がセキュアな状態で JConsole を起動するコマンドについては、第2 章「JMX テクノロジを使用する監視と管理」の「SSL を有効にした JConsole によるリモート監視」で説明します。

JMX エージェントへの接続

JConsole を、接続する JMX エージェントを指定する引数で起動した場合、指定した Java VM の監視が自動的に始まります。「接続」 | 「新規接続」を選択し、必要な情報を入力することで、いつでも別のホストに接続できます。

JConsole を起動するときに引数を指定しない場合、最初に接続ダイアログボックスが表示されます。このダイアログボックスで、「ローカル」と「リモート」のどちらのプロセスに接続するかを選択します。

Dynamic Attach

Java SE プラットフォームの前回リリースでは、JConsole で監視するアプリケーションを起動する場合、次のコマンド行オプションを使用する必要がありました。

% -Dcom.sun.management.jmxremote

それに対して、Java SE 6 プラットフォーム付属バージョンの JConsole は、Attach API をサポートするアプリケーションであれば接続できます。つまり、Java SE 6 HotSpot VM で起動するアプリケーションは JConsole によって自動的に検出され、起動時に前記のコマンド行オプションを使用する必要はありません。

JConsole のローカルプロセスへの接続

接続する JMX エージェントを設定せずに JConsole を起動すると、次のダイアログウィンドウが表示されます。

図 3-1 ローカルプロセスへの接続の作成

ローカルプロセスオプションには、ローカルシステム上で JConsole と同じユーザー ID により動作する Java VM とそのプロセス ID、クラスや引数の情報が一覧表示されます。JConsole をアプリケーションに接続するには、監視するアプリケーションを選択して「接続」ボタンをクリックします。ローカルプロセスのリストには、次のタイプの Java VM で動作するアプリケーションが含まれます。

管理エージェントを有効にしたアプリケーション。 Java SE 6 プラットフォームまたは J2SE 5.0 プラットフォームで動作するアプリケーションのうち、-Dcom.sun.management.jmxremote オプションを使用して起動したもの、または -Dcom.sun.management.jmxremote.port オプションを指定して起動したものが含まれます。そのほか、Java SE 6 プラットフォームで動作するアプリケーションのうち、起動時は管理プロパティーを指定せずにあとで JConsole で接続し、実行時に管理エージェントを有効にするものも含まれます。
管理エージェントを無効にした接続可能なアプリケーション。 接続可能なアプリケーションは、実行時に管理エージェントのローディングをサポートします。接続可能なアプリケーションには、Attach API をサポートする Java SE 6 プラットフォーム上で起動するアプリケーションが含まれます。動的接続をサポートするアプリケーションでは、管理エージェントを起動する場合、コマンド行で com.sun.management.jmxremote または com.sun.management.jmxremote.port オプションを指定する必要はなく、アプリケーションを起動する前に、JConsole を管理エージェントに接続する必要はありません。このアプリケーションを選択すると、接続時に管理エージェントが有効になるという通知が画面に表示されます。図 3-1 の接続ダイアログの例では、NetBeans IDE と JConsole の両方が Java SE 6 プラットフォーム VM の内部で起動しています。両方とも標準テキストで表示され、JConsole が接続可能であることを示しています。図 3-1 では、JConsole が選択され、通知が表示されています。
管理エージェントを無効にした接続不能なアプリケーション。 -Dcom.sun.management.jmxremote または com.sun.management.jmxremote.port オプションを使用せずに、J2SE 1.4.2 プラットフォームまたは J2SE 5.0 プラットフォームで起動したアプリケーションが含まれます。これらのアプリケーションは、テーブルにグレー表示され、JConsole は接続できません。図 3-1 の接続ダイアログの例では、Anagrams アプリケーションは、管理プロパティーで JMX エージェントを有効にせずに J2SE 5.0 プラットフォーム VM で起動されたため、グレー表示され選択不可になっています。

図 3-2 管理エージェントを有効にせずに試行するアプリケーションへの接続

管理エージェントを有効にせずに試行するローカルプロセスへの接続。JConsole はこのアプリケーションに接続できない。

図 3-2 の接続ダイアログの例では、Anagrams アプリケーションがクリックされ選択されていますが、「接続」ボタンはグレー表示のままで、このプロセスでは管理エージェントが有効でないという通知が表示されています。JConsole は、起動時に正しい Java VM または正しいオプションを使用しなかったため、Anagrams に接続できません。

JConsole のリモートプロセスへの接続

接続ダイアログが開くと、リモートプロセスへの接続オプションも表示されます。

図 3-3 リモートプロセスへの接続の作成

リモート Java VM 上で実行されるプロセスを監視するには、次の情報を入力する必要があります。

ホスト名: Java VM が動作しているマシンの名前。
ポート番号: Java VM の起動時に指定した JMX エージェントのポート番号。
ユーザー名とパスワード: ユーザー名と使用するパスワード (パスワード認証の必要な JMX エージェントで Java VM を監視する場合のみ必要)。

JMX エージェントのポート番号の設定については、「アウトオブボックスの管理の有効化」を参照してください。ユーザー名とパスワードについては、「パスワードとアクセスファイルの使用」を参照してください。

JConsole を実行している Java VM を監視するには、ホスト localhost とポート 0 を指定して「接続」をクリックするだけです。

JMX サービス URL を使用する接続

リモートプロセスオプションを使用してほかの JMX エージェントに接続するには、そのエージェントの JMX サービス URL、ユーザー名、およびパスワードを指定します。JMX サービス URL の構文には、接続に使用するトランスポートプロトコルとサービスアクセスポイントを指定する必要があります。JMX サービス URL の全構文は、javax.management.remote.JMXServiceURL の API ドキュメントに記載されています。

図 3-4 JMX サービス URL による JMX エージェントへの接続

JMX エージェントが Java プラットフォームに含まれていないコネクタを使用する場合は、jconsole コマンドを実行するときに、次のようにコネクタクラスをクラスパスに追加する必要があります。

% jconsole -J-Djava.class.path=JAVA_HOME/lib/jconsole.jar:JAVA_HOME/lib/tools.jar:connector-path

上記のコマンドで、connector-path は、JDK には含まれていないが JConsole で使いたいコネクタクラスのある、ディレクトリまたは Java アーカイブ (Jar) ファイルです。

JConsole タブの表示

JConsole をアプリケーションに接続すると、JConsole には 6 個のタブが表示されます。

概要: Java VM と監視結果の値の概要を表示します。
メモリー: メモリーの使用情報を表示します。
スレッド: スレッドの使用情報を表示します。
クラス: クラスローディングの情報を表示します。
VM: Java VM の情報を表示します。
MBean: MBean の情報を表示します。

JConsole の右上隅にある緑の接続ステータスアイコンを使用すれば、稼動中の Java VM との切断または再接続がいつでもできます。「接続」を選択し、次にドロップダウンメニューから「新規接続」を選択すれば、稼動している任意の数の Java VM といつでも接続できます。

概要情報の表示

「概要」タブには、CPU 使用状況、メモリー使用量、スレッド数、Java VM にロードされたクラスについての、グラフィカルな監視情報がすべて 1 つの画面に表示されます。

図 3-5 「概要」タブ

「概要」タブを使用すれば、以前は複数のタブを切り替えることでしか利用できなかった情報の関連付けが簡単にできます。

図表データの保存

JConsole では、図表データをコンマ区切り値 (CSV) ファイルに保存できます。図表のデータを保存するには、目的の図表を右クリックして「別名で保存」を選択し、データの保存先のファイルを指定するだけです。どの図表のデータでも、JConsole のタブに表示されたものであれば、同様に保存できます。

CSV 形式は、スプレッドシートアプリケーションのデータ交換に一般的に使用されています。CSV ファイルは、スプレッドシートアプリケーションにインポートして、そのアプリケーションで図を作成する場合に使用できます。このデータは、2 つ以上の名前付き列 (カラム) として表示されます。最初の列はタイムスタンプを示します。ファイルをスプレッドシートアプリケーションにインポートしたあと、通常は最初の列を選択し、その書式を必要に応じて「日付」または「日付/時間」に変更する必要があります。

メモリー消費の監視

「メモリー」タブには、メモリー消費とメモリープールに関する情報が表示されます。

図 3-6 「メモリー」タブ

「メモリー」タブには、「GC の実行」ボタンが付いており、これをクリックすればいつでもガベージコレクションを実行できます。この図は、ヒープメモリーと非ヒープメモリー、および特定のメモリープールに関する Java VM のメモリー使用量の経時的推移を示しています。利用できるメモリープールは、使用している Java VM のバージョンによって異なります。HotSpot Java VM の場合、シリアルガベージコレクションのメモリープールは次のとおりです。

Eden 領域 (ヒープ): ほとんどのオブジェクトにメモリーが最初に割り当てられるプール。
Survivor 領域 (ヒープ): Eden 領域のガベージコレクションで残ったオブジェクトを含むプール。
Tenured 世代 (ヒープ): Survivor 領域である程度の期間存続したオブジェクトを含むプール。
Permanent 世代 (非ヒープ): クラスやメソッドオブジェクトなど、仮想マシン自体を反映したデータをすべて保持するプール。Java VM でクラスデータ共有を使用する場合、この世代は読み取り専用領域と読み取り/書き込み領域に分割されています。
コードキャッシュ (非ヒープ): HotSpot Java VM には、ネイティブコードのコンパイルとストレージに使用するメモリーを含むコードキャッシュも含まれます。

これらのメモリープールの消費を示す別の図表を表示させるには、「図」ドロップダウンメニューのオプションから選択します。右下隅の「ヒープ」または「非ヒープ」の棒グラフをクリックすると、図表の表示が切り替わります。最後に、メモリー使用量を追跡する時間の範囲指定は、「時間範囲」ドロップダウンメニューのオプションから選択します。

これらのメモリープールの詳細は、次の「ガベージコレクション」を参照してください。

「詳細」領域には、現在のメモリーに関するメトリックスがいくつか表示されます。

使用済み: 現在使用中のメモリー容量。使用中のメモリーには、すべてのオブジェクト (アクセス可能なものも不能なものも含む) によって使用されているメモリーが含まれます。
確定: Java VM で利用できることが保証されたメモリー容量。確定メモリーの容量は経時的に変わる可能性があります。Java 仮想マシンがメモリーをシステムに解放した場合、確定メモリーの容量は、起動時に割り当てられた最初の容量よりも少なくなる可能性があります。確定メモリーの容量は必ず使用中のメモリー容量以上になります。
最大: メモリー管理に使用できる最大メモリー容量。この値は変化する場合や定義されていない場合があります。Java VM で使用メモリー容量を確定メモリー容量より大きくしようとすると、使用量が最大以下の場合 (たとえば、システムの仮想メモリーが少ない場合) でも、メモリー割り当てに失敗することがあります。
GC 時間: ガベージコレクションに要した累積時間とその呼び出しの総数。複数行に及ぶ場合もあります。各行は Java VM で使用するガベージコレクタの 1 つのアルゴリズムを示します。

右下の棒グラフは、メモリープールによって、ヒープおよび非ヒープメモリーで使用されるメモリーを示しています。使用メモリーがメモリー使用量しきい値を超えると、棒の色が赤に変わります。メモリー使用量しきい値は、MemoryMXBean の属性で設定できます。

ヒープおよび非ヒープのメモリー

Java VM が管理するメモリーには、ヒープメモリーと非ヒープメモリーの 2 種類があり、いずれも Java VM の起動時に作成されます。

ヒープメモリーは実行データ領域で、Java VM はそこからすべてのクラスのインスタンスと配列にメモリーを割り当てます。ヒープのサイズは可変の場合と固定の場合があります。ガベージコレクタは、ヒープメモリーをオブジェクトに再利用する自動メモリー管理システムです。
非ヒープメモリーには、Java VM の内部処理や最適化に必要なメモリーと、すべてのスレッドで共有されるメソッド領域が含まれます。非ヒープメモリーには、実行定数プール、フィールドおよびメソッドデータ、メソッドおよびコンストラクタのコードなど、クラス単位の構造体が格納されます。メソッド領域は論理的にはヒープの一部ですが、実装方法によっては、Java VM がこの領域のガベージコレクトや圧縮を行わない場合もあります。ヒープメモリーと同様に、メソッド領域のサイズは固定の場合と可変の場合があります。メソッド領域のメモリーは連続している必要はありません。

メソッド領域のほかに、Java VM には、非ヒープメモリーにも属する内部処理または最適化のためのメモリーが必要になる場合もあります。たとえば、JIT (Just-In-Time) コンパイラには、パフォーマンス向上のために Java VM コードから変換されたネイティブマシンコードを格納するためのメモリーが必要です。

メモリープールとメモリーマネージャー

メモリープールとメモリーマネージャーは、Java VM のメモリーシステムの重要な部分です。

メモリープールとは、Java VM が管理するメモリー領域です。Java VM には少なくとも 1 つのメモリープールがあり、実行中にメモリープールを作成または削除できます。メモリープールは、ヒープメモリーと非ヒープメモリーのどちらかに属します。
メモリーマネージャーは、1 つ以上のメモリープールを管理します。ガベージコレクタは、メモリーマネージャーの一種で、アクセスできなくなったオブジェクトが使用していたメモリーの再利用を管理しています。Java VM が装備するメモリーマネージャーは 1 つの場合も複数の場合もあります。実行中にメモリーマネージャーを追加または削除できます。メモリープールは、複数のメモリーマネージャーによって管理できます。

ガベージコレクション

ガベージコレクション (GC) は、参照されていないオブジェクトが使用していたメモリーを解放する、Java VM の仕組みです。アクティブな参照をもつオブジェクトを「生きている」と考え、参照されていない (アクセスできない) オブジェクトを「死んでいる」と考えるのが一般的です。ガベージコレクションは、死んだオブジェクトによって使用されていたメモリーを解放するプロセスです。GC によって使用されるアルゴリズムとパラメータがパフォーマンスに劇的な効果をもたらす可能性があります。

Java HotSpot VM ガベージコレクタは、世代別 GC を使用します。世代別 GC は、ほとんどのプログラムには次のような傾向があるという所見に基づいています。

生成する多くのオブジェクトは短命である (イテレータやローカルの変数など)。
生成する一部のオブジェクトは非常に長い寿命をもつ (高度な持続性オブジェクトなど)。

そのため、世代別の GC は、メモリーをいくつかの世代に分け、それぞれにメモリープールを割り当てます。ある世代が割り当てられたメモリーを使用すると、VM はメモリープール上で部分的な GC (マイナーコレクションともいう) を実行して、死んだオブジェクトによって使用されたメモリーを再利用します。この部分的な GC は、通常、フル GC よりもはるかに高速です。

Java HotSpot VM は、若い世代 (「nursery」ともいう) と古い世代という 2 つの世代を定義します。若い世代は、1 つの「Eden 領域」と 2 つの「Survivor 領域」で構成されています。VM は最初にすべてのオブジェクトを Eden 領域に割り当て、ほとんどのオブジェクトはそこで死にます。マイナー GC を実行するとき、VM は残りのオブジェクトを Eden 領域から Survivor 領域の 1 つに移します。VM は、Survivor 領域で十分に長く生きるオブジェクトを古い世代の「Tenured」領域に移します。Tenured 世代がいっぱいになると、フル GC が実行されます。これは生きているオブジェクトをすべて含むため、通常はマイナー GC よりも時間がかかります。Permanent 世代は、クラスやメソッドオブジェクトなどの仮想マシン自体を反映したデータをすべて保持します。

各世代のデフォルトの配置は、図 3-7 のようになります。

図 3-7 ガベージコレクションのデータの世代

ガベージコレクタがボトルネックになる場合、世代のサイズをカスタマイズすることによって、パフォーマンスを向上させることができます。JConsole を使用して、ガベージコレクタのパラメータを試すことで、パフォーマンスメトリックの感度を調べることができます。詳細は、「5.0 HotSpot VM によるガベージコレクタの調整」に関するトピックを参照してください。

スレッドの使用の監視

「スレッド」タブには、スレッドの使用に関する情報が表示されます。

図 3-8 「スレッド」タブ

左下隅の「スレッド」リストには、アクティブなスレッドがすべて表示されます。「フィルタ」フィールドに文字列を入力すると、「スレッド」リストには、入力した文字列を含む名前のスレッドだけが表示されます。「スレッド」リスト内のスレッドの名前をクリックすると、スレッド名や状態、スタックトレースなど、そのスレッドに関する情報が右に表示されます。

この図は、ライブスレッドの数の経時的推移を示しています。次の 2 本のラインが表示されています。

赤: スレッドのピーク数
青: ライブスレッドの数。

Threading MXBean には、ほかにも「スレッド」タブにない便利な操作があります。

findMonitorDeadlockedThreads: オブジェクトモニターロックでデッドロックに陥ったスレッドを検出します。この操作は、デッドロックに陥ったスレッド ID の配列を返します。
getThreadInfo: スレッド情報を返します。これには、名前とスタックトレースのほか、スレッドが現在ブロックされている場合は該当するモニターロック、そのロックを保持しているスレッド、およびスレッド競合統計が含まれます。
getThreadCpuTime: 指定されたスレッドによる CPU の使用時間を返します。

これらの追加機能に「MBean」タブからアクセスするには、MBean ツリーで「Threading MXBean」を選択します。この MXBean には、監視されている Java VM のスレッド情報にアクセスするための属性と操作がすべて一覧表示されます。「MBean の監視と管理」を参照してください。

デッドロックに陥ったスレッドの検出

アプリケーションがデッドロックに陥ったのかどうかを確認する場合 (たとえば、アプリケーションがハングアップしたように見える場合)、「デッドロックを検出する」ボタンをクリックすれば、デッドロックに陥ったスレッドを検出できます。デッドロックに陥ったスレッドが検出されると、図 3-9 のように、「スレッド」タブの横の新しいタブに表示されます。

図 3-9 デッドロックに陥ったスレッド

「デッドロックを検出する」ボタンを使用すれば、オブジェクトモニターと java.util.concurrent 所有可能シンクロナイザに関するデッドロックサイクルを検出できます (java.lang.management.LockInfo の API 仕様のドキュメントを参照)。java.util.concurrent ロックの監視サポートは Java SE 6 に追加されました。JConsole を J2SE 5.0 VM に接続すると、「デッドロックを検出する」メカニズムによりオブジェクトモニターに関するデッドロックだけが検出されます。JConsole では、所有可能シンクロナイザに関するデッドロックは表示されません。

スレッドとデーモンスレッドの詳細は、java.lang.Thread の API ドキュメントを参照してください。

クラスローディングの監視

「クラス」タブには、クラスローディングの情報が表示されます。

図 3-10 「クラス」タブ

この図は、ロードされたクラス数の経時的推移を示しています。

赤いラインは、ロードされたクラスの総数 (そのあとアンロードされたクラスを含む) を表します。
青いラインは、現在ロードされているクラスの数を表します。

タブの下の「詳細」セクションには、Java VM の起動後にロードされたクラスの総数、および現在ロードされている数とアンロードされた数が表示されます。クラスローディングのトレースを冗長出力に設定するには、右上隅のチェックボックスにチェックマークを入れます。

VM 情報の表示

「VM の概要」タブには、Java VM に関する情報が表示されます。

図 3-11 「VM の概要」タブ

このタブには次のような情報が表示されます。

サマリー
- アップタイム: Java VM の合計起動時間。
- プロセス CPU 時間: Java VM が起動してから CPU を使用した合計時間。
- コンパイルの総時間: JIT コンパイルに要した累積時間。Java VM の実装方法によって、JIT コンパイルのタイミングが決まります。Hotspot VM は、適応型コンパイルを採用しています。適応型コンパイルでは、VM は標準のインタプリタを使用してアプリケーションを起動しますが、コードの実行中にコードを分析して、パフォーマンスのボトルネック、つまり「ホットスポット」を検出します。
スレッド
- ライブスレッド: ライブデーモンスレッドおよびデーモンでないライブスレッドの現在数。
- ピーク: Java VM 起動後のライブスレッドの最大数。
- デーモンスレッド: デーモンのライブスレッドの現在数。
- 開始したスレッドの総数: Java VM の起動後に起動されたスレッドの合計数 (デーモンおよびデーモン以外のスレッドと終了したスレッドを含む)。
クラス
- 現在ロードされているクラス: 現在メモリーにロードされているクラスの数。
- ロードされたクラスの総数: Java VM の起動後にメモリーにロードされたクラスの合計数 (そのあとアンロードされたものを含む)。
- アンロードされたクラスの総数: Java VM の起動後にメモリーからアンロードされたクラスの数。
メモリー
- 現在のヒープサイズ: 現在、ヒープ単位で占めている K バイト数。
- 確定メモリー: ヒープ用に割り当てられたメモリーの合計容量。
- 最大ヒープサイズ: ヒープ単位で占めている最大 K バイト数。
- ファイナライズを保留中のオブジェクト: ファイナライズを待機しているオブジェクト数。
- ガベージコレクタ: GC に関する情報 (ガベージコレクタ名、GC の実行回数、GC の実行に要した合計時間など)。
オペレーティングシステム
- 総物理メモリー: オペレーティングシステムが所有する RAM (ランダムアクセスメモリー) の容量。
- 空物理メモリー: オペレーティングシステムが使用可能な RAM の空き容量。
- 確定仮想メモリー: 実行プロセスに使用できることが保証された仮想メモリーの量。
その他の情報
- VM の引数: アプリケーションが Java VM に渡した入力引数 (main メソッドの引数は含まない)。
- クラスパス: システムクラスローダーがクラスファイルを検索するために使用するクラスパス。
- ライブラリパス: ライブラリをロードするときに検索するパスのリスト。
- ブートクラスパス: ブートストラップクラスローダーがクラスファイルを検索するために使用するブートクラスパス。

MBean の監視と管理

「MBean」タブには、プラットフォーム MBean サーバーに通常の方法で登録されているすべての MBean に関する情報が表示されます。「MBean」タブから、フルセットのプラットフォーム MXBean インストゥルメンテーション (ほかのタブには表示されないものも含む) にアクセスできます。そのほか、「MBean」タブを使用すれば、アプリケーションの MBean の監視と管理もできます。

図 3-12 「MBean」タブ

左のツリーは、現在稼動中のすべての MBean を示しています。ツリーで MBean を選択すると、その MBeanInfo と MBean 記述子の両方が右に表示され、その下のツリーには属性、操作、または通知が表示されます。

プラットフォーム MXBean とその各種操作および属性はすべて、JConsole の「MBean」タブからアクセスできます。

MBean ツリーの作成

デフォルトでは、MBean はそのオブジェクト名に対応するツリーに表示されます。オブジェクト名の作成時に指定したキープロパティーの順序は、JConsole によって MBean を MBean ツリーに追加するときに保存されます。JConsole が MBean ツリーの作成に使用する正確なキープロパティーリストは、ObjectName.getKeyPropertyListString() メソッドによって返されます。その場合、最初のキーは type で、j2eeType があればそれが 2 番目のキーとなります。

ただし、ObjectName キープロパティーの順序をデフォルトにしておくと、JConsole が MBean ツリーをレンダリングするときに予想外の動作につながる場合があります。たとえば、2 つのオブジェクト名が同じキーをもち、そのキーの順序が異なる場合、対応する MBean は、MBean ツリーにある同じノードでは作成されません。

たとえば、Triangle MBean オブジェクトを次の名前で作成するとしましょう。

com.sun.example:type=Triangle,side=isosceles,name=1
com.sun.example:type=Triangle,name=2,side=isosceles
com.sun.example:type=Triangle,side=isosceles,name=3

JMX テクノロジに関するかぎり、これらのオブジェクトはまったく同様に扱われます。オブジェクト名内のキーの順序は、JMX テクノロジにとって重要ではありません。しかし、JConsole をこれらの MBean に接続し、デフォルトでレンダリングされた MBean ツリーを使用すると、オブジェクト com.sun.example:type=Triangle,name=2,side=isosceles が Triangle ノードの下に 2 というノード名で作成されます。このノード 2 には isosceles というサブノードが追加されます。ほかの 2 つの二等辺三角形 (name=1 と name=3) は、図 3-13 のように、Triangle の下に isosceles という別名ノードでグループ化されます。

図 3-13 予想外にレンダリングされた MBean ツリーの例

この問題を回避するには、コマンド行で JConsole を起動するときにキープロパティーリストを正しい順序で入力することにより、MBean がツリーに表示される順序を指定します。これを実行するには、次のコマンドのように、システムプロパティー com.sun.tools.jconsole.mbeans.keyPropertyList を設定します。

% jconsole -J-Dcom.sun.tools.jconsole.mbeans.keyPropertyList=key[,key]*

キープロパティーリストのシステムプロパティーにより、キーのコンマ区切りリストは選択された順序で表示されます。この場合の key は、必ずオブジェクト名のキーを表す文字列または空の文字列とします。リストで指定されたキーが特定の MBean に適用されない場合、そのキーは破棄されます。キープロパティーリストで指定されたキーよりも多数のキーが MBean にある場合、ObjectName.getKeyPropertyListString() の戻り値で定義されたキーの順序が、keyPropertyList で定義されたキーの順序を補完します。したがって、空のキーリストを指定すると、JConsole のキーの表示は、MBean の ObjectName の表示と同じ順序になります。

上記の Triangle MBean の例に戻ると、JConsole を起動するときに keyPropertyList システムプロパティーを指定すれば、side が先、name が後というキープロパティーの順序に従って、すべての MBean がグループ化されます。そのために、JConsole を次のコマンドで起動します。

% jconsole -J-Dcom.sun.tools.jconsole.mbeans.keyPropertyList=side,name

このシステムプロパティーを指定して JConsole を起動すると、図 3-14 のような MBean ツリーが生成されます。

図 3-14 keyPropertyList を使用して生成された MBean ツリーの例

図 3-14 では、side キーが先、name キーが後になります。type キーが最後になるのは、キープロパティーリストに指定されていなかった場合に、MBean ツリーのアルゴリズムによって残りのキーには元のキーの順序が適用されたためです。結果として、type キーの順序は、keyPropertyList システムプロパティーで定義されたキーのあとになります。

「JMX ベストプラクティスガイドライン」で定義されたオブジェクトの命名規約に従えば、type キーは必ず先頭にくるはずです。この規約を守るため、JConsole は必ず次のシステムプロパティーを指定して起動します。

% jconsole -J-Dcom.sun.tools.jconsole.mbeans.keyPropertyList=type,side,name

上記のコマンドにより、JConsole は図 3-15 のような Triangle MBean の MBean ツリーを生成します。

図 3-15 JMX ベストプラクティスに従って生成された MBean ツリーの例

これで図 3-13 と図 3-14 の MBean ツリーよりもずっとわかりやすくなります。

MBean 属性

「Attributes」ノードを選択すると、MBean の属性がすべて表示されます。図 3-16 は、Threading プラットフォーム MXBean のすべての属性を示しています。

図 3-16 すべての MBean 属性の表示

図 3-17 のように、ツリーから個別の MBean 属性を選択すると、その属性値、MBeanAttributeInfo、関連する記述子が右側のペインに表示されます。

図 3-17 個別の MBean 属性の表示

属性値が太字で表示されている場合、これをダブルクリックすると、その属性の追加情報が表示されます。たとえば、java.lang.Memory MBean の属性 HeapMemoryUsage の値をクリックすると、図 3-18 のような図表が表示されます。

図 3-18 属性値の表示

属性の数値をダブルクリックすると、その数値の変化を示す図表が表示されます。たとえば、Garbage Collector MBean PS Marksweep の属性 CollectionTime をダブルクリックすると、ガベージコレクションに要した時間が表示されます。

JConsole では、書き込み可能な属性値の設定もできます。書き込み可能な属性値は青で表示されます。ここには Memory MBean の Verbose 属性が表示されます。

図 3-19 書き込み可能な属性値の設定

属性を設定するには、属性をクリックして編集します。たとえば、JConsole でガベージコレクタの冗長トレースを有効または無効にするには、「MBean」タブで「Memory MXBean」を選択し、Verbose 属性を true または false に設定します。同様に、クラスローディング MXBean にも Verbose 属性があり、これを設定すれば、クラスローディング冗長トレースを有効または無効に切り替えることができます。

MBean の操作

「Operations」ノードを選択すると、MBean の操作がすべて表示されます。MBean の操作はボタンで表示され、これをクリックして操作を呼び出すことができます。図 3-20 は、Threading プラットフォーム MXBean のすべての操作を示しています。

図 3-20 すべての MBean 操作の表示

ツリーから個別の MBean 操作を選択すると、図 3-21 のように、MBean 操作を呼び出すボタン、その操作の MBeanOperationInfo、その記述子が表示されます。

図 3-21 個別の MBean 操作の表示

MBean の通知

通知の受信に登録するには、左ツリーから「Notifications」ノードを選択し、右に表示される「登録」ボタンをクリックします。通知の受信数は角括弧の中に表示され、新しい通知を受信すると「Notifications」ノードそのものが太字で表示されます。Memory プラットフォーム MXBean の通知を図 3-22 に示します。

図 3-22 MBean 通知の表示

個別の MBean 通知を選択すると、図 3-23 のように、MBeanNotificationInfo が右側のペインに表示されます。

図 3-23 個別の MBean 通知の表示

HotSpot Diagnostic MXBean

JConsole の「MBean」タブでは、HotSpot VM にヒープダンプの実行を指示し、HotSpotDiagnostic MXBean で VM オプションを取得または設定することもできます。

図 3-24 HotSpot 診断 MBean の表示

ヒープダンプを手動で行うには、com.sun.management.HotSpotDiagnostic MXBean の dumpHeap 操作を呼び出します。また、setVMOption 操作を使用して HeapDumpOnOutOfMemoryError Java VM オプションを指定し、OutOfMemoryError を受け取ると必ず VM で自動的にヒープダンプが実行されるようにすることもできます。

カスタムタブの作成

既存の標準タブのほか、独自のカスタムタブを JConsole に追加して、独自の監視アクティビティーを行うこともできます。JConsole プラグイン API には、たとえば、独自のアプリケーションの MBean にアクセスするタブを追加するメカニズムがあります。JConsole プラグイン API は、独自のカスタムプラグインを作成するために拡張可能な abstract クラスである com.sun.tools.jconsole.JConsolePlugin を定義しています。

前述のように、独自のプラグインは、JConsolePlugin を拡張して JConsolePlugin getTabs および newSwingWorker メソッドを実装する必要があります。getTabs メソッドは、JConsole に追加するタブのリストと空リストのどちらかを返します。newSwingWorker メソッドは、そのプラグインの GUI を更新する SwingWorker を返します。

独自のプラグインは Java アーカイブ (JAR) ファイルで提供され、それには META-INF/services/com.sun.tools.jconsole.JConsolePlugin というファイルが入っている必要があります。この JConsolePlugin ファイルそのものには、新しい JConsole タブとして追加するプラグインの完全修飾クラス名のリストが含まれています。JConsole は、サービスプロバイダのロード機能を使用して、プラグインの検索とロードを実行します。JConsolePlugin では、プラグインごとのエントリを 1 つにして、複数のプラグインをもつこともできます。

新しいカスタムプラグインを JConsole にロードするには、JConsole を次のコマンドで起動します。

%  jconsole -pluginpath plugin-path

上記のコマンドで、plugin-path は、検索する JConsole プラグインへのパスを指定しています。これらのパスではディレクトリ名または JAR ファイルを指定し、プラットフォームの標準区切り文字を使用して複数のパスを指定することもできます。

Java SE 6 プラットフォームには JConsole プラグインのサンプルが付属します。JTop は、このアプリケーションで稼動するすべてのスレッドの CPU 使用状況を示す JDK デモアプリケーションです。このデモは CPU 消費が多いスレッドの識別に便利で、JConsole プラグインやスタンドアロンの GUI として使用できるように更新されています。JTop は、デモアプリケーションとして Java SE 6 プラットフォームにバンドルされています。JTop プラグインを使用して JConsole を起動するには、次のコマンドを実行します。

% JDK_HOME/bin/jconsole -pluginpath JDK_HOME/demo/management/JTop/JTop.jar

この JConsole のインスタンスに接続すると、JTop タブが追加され、稼動中の各種スレッドの CPU 使用状況が表示されます。

図 3-25 カスタムプラグインタブの表示

前の項目

連絡先